MySQL import / export at the Command Line

Like many (most?) developers when I work with a database I tend to manage them using another programme – usually either phpMyAdmin or Navicat. However there are times when you have to get basic again and dig down to the Command Line (usually because of an access issue like a firewall setting you can’t change or because you need to import a file too big for phpMyAdmin). The trouble is if you only use these commands once in a blue moon you soon forget them.

Dump (export your database)

  1. Login to the shell or Command Prompt, navigate to where you would like your file saved.

  2. mysqldump --user=your_username --password=your_password your_database > your_dump_file.sql

your_username is a mysql user with the correct rights to the database you want to dump.
your_password is the password for your_username.
your_database is the name of your database.
your_dump_file.sql is the name of the file that will be created in the export.


  1. Create the database that you want to import into, but leave it empty or if you are using an existing database remove the tables (make sure you have a backup first).
  2. Login to the shell or Command Prompt

  3. mysql --user=your_username --password=your_password your_database < your_file_to_import.sql

A Theory of Project Costs

Lately I’ve been giving a lot of though to the way costs for projects are estimated. It always seems a very hit and miss affair. One designer I used to work with used to work out the costs as accurately as he could and then double whatever number he came up with – this worked as well as anything – and fairly accurately reflected the time / cost of what he was doing.

I think a lot of the problem is to do with the way projects scale – a £10,000 project is not necessarily 10 x more complex than a £1000 project, but more importantly it is far easier to scope a static webpage with 10 pages and a contact form than website where the client guidance goes something along the lines of we want it to be a bit like Facebook {edit as applicable} but aimed at Pig Farmers {edit as applicable}.

The trouble with building complex applications is that it is often hard (if not impossible) to anticipate problems until you come across them. I suppose this has a lot to do with the rise Agile Development – using it as a way of getting away from specifications that often rapidly loose any relationship to the project they define.

Development is really an evolutionary affair and clients will change their minds in response to what they see – but God is (as they say) in the details – and it is often genuinely not possible to know how a project will go once it starts to take shape. Good project management I suppose the art of reconciling these evolutionary forces with budgets, clients and what is actually possible.

Right now in my current job I don’t really have any say in how projects are costed – and they are costed as well as anywhere else I have ever worked – which is to say as accurately as possible – but of course I have to work with budgets and liaise with clients over all the technical nitty-gritty – so I have lots of time to observe.

My current theory goes something along these lines (BTW all figures are just made up)

c = minimum cost
t = cost per database table
i = number of database tables

total cost = c + (t x i)

BUT this isn’t right yet there a number of additional factors that I am trying to work into the equation so far I have:

p = Client Knowledge – an overly knowledgeable client cause as much trouble as an IT somebody who is IT illiterate – ideally we need somebody who understands what you tell and has ideas of their own but can also understand advice.

z = a factor to fine tune t x i

For Example: if i = 10 then the total cost might work out as 1 x (t x i) but if i = 60 then total cost = 0.7 x (t x i)

I wonder what ever happened to my old graphics calculator…

To be continued…

widgEditor is back…

Over the weekend I found out that Cameron Adams aka The Man in blue has just released a new version of the fabulous widgEditor – an easy to use and easy to modify WYSIWYG editor mad with XHTML and JavaScript.

It has been 3 years since he released the 1st version so it is great that he has released an update and the ven better news is that he is working on version 2 (I can’t wait).

The great thing about widgEditor was that unlike all of the usual WYSIWYG suspects, it was easy to go into the code and change things about to get it to work how you wanted – a case of a limited feature set being an advantage as the end result was pretty elegant.

If you have never heard of or used widgEditor – check it out.