Migrating Databases

Currently, for various reasons, I seem to be heavily involved in moving databases around. Not just the data, but the databases themselves. If you’re at all geeky, it’s kind of interesting, seeing how other people organise data as opposed to how I prefer to do it, and looking at the future-proofing of such data. If you’re not geeky then don’t read any further, you’ll just get bored. There’ll be something else along later for you, I’m sure.

In one case, the client is moving from an on-line service provider to an in-house solution that’ll be written solely by Yours Truly. In a lot of ways it’s a complete nightmare – the provider will only export the data in one format, an Excel spreadsheet. That then has to be converted to something that’ll work with SQL, then get tweaked so it’ll work without crashing on import to MySQL, and that’s just to get it into a “temporary” table before I do a whole bundle of conversions on the data in order to get it all to work in the way I want it to.

In the other main scenario (there are a couple of other smaller jobs too, but two main jobs at the moment) I’m going the other way – from an existing in-house database (on MS Access) to a much more stable, versatile, and extensible on-line version with nice web front-end and a bundle more functionality. Again, it’s producing some interesting challenges- not least that Access really doesn’t like exporting to anything. Ever.

All the same though, both jobs are interesting and (dare I say it) fun. They’re making me think (hard) and come up with solutions to problems, which is actually always something I enjoy. Once I’ve got the current data migrated over, then I get to do a load of other stuff with it in order to fit it all in with the plans/ideas that’re already present, and that again will be something I enjoy.

Yes, I truly am that sad. Worrying, isn’t it?