Replicating
Ha! I just had my first successful test of replicating a Microsoft Access 2003 database design to a MySQL server! In fact, because of the way I work, it also handles incremental design changes. I can re-arrange, rename, and modify the field types in Access, press a button, and the fields alter in the live database. The system is user-extensible, (for a given level of user) and handles multiple client and server versions.
This was the major initial work before tackling the core problem... replicating the actual data between the database systems. I solved that one in my head weeks ago, but you can't really copy data if you have nowhere to put it.
My programming style is to build vast wodges of code to perform a particular task very well, and then connect them up later on. The archetypal modular technique. Nothing really works (except theoretically) until the final day when everything is plugged together. It's like making a jigsaw puzzle by painting each piece in isolation with the belief that, at the end, it will all fit and make a pretty picture. My special talent is that, somehow, it does.
I've learned that pretty top-level design documents are worth almost nothing, and that you need to get into the messy guts of a problem and see what shape reality itself wants to take. Then build upwards. I've seen too many plans that have big boxes in their entity diagrams saying, essentially, "the magic happens here" with neatly labelled arrows leading in and out.
Sorry, but computers don't do that. What you really mean is that there needs to be a big box on your project Gantt chart labeled "the work happens here" with the name of your best programmer written below it, and no completion date.
There's a saying; "First, you need to define the problem." And that's absolutely true, but it doesn't automatically follow that the solution will then be obvious, or possible. Fermat's last theorem was a perfectly straightforward question, simple even, defined in precise mathematical terms. And it still required 300 years of work.
In my case, the hardest job was handling the renaming of fields. Assume all the fields in a table are re-named, and potentially re-ordered. How do you apply the changes to an older copy of the database if, by definition, the identifying information has been lost? (Solution: attach unique ID metadata to the database fields. In the 'description' if you have to.)
Explaining computer programming is awfully hard. There aren't really very good metaphors, and so programming stories generally end up as boring as fishing stories, bogged down in incomprehensible detail. Or you try to make it metaphorical, even lyrical, but it looses all touch with the reality of what you did.
You can't even just show off the finished program, because often the most complex coding is hidden behind a simple and clean interface. Just look at the Google homepage; you really have no idea how staggeringly difficult it is to turn a single box of search terms into a simple list of results, because it's all out-of-sight, and you assume. Programs which seem the most complicated are usually just offloading the intelligence requirements onto the user.
This was the major initial work before tackling the core problem... replicating the actual data between the database systems. I solved that one in my head weeks ago, but you can't really copy data if you have nowhere to put it.
My programming style is to build vast wodges of code to perform a particular task very well, and then connect them up later on. The archetypal modular technique. Nothing really works (except theoretically) until the final day when everything is plugged together. It's like making a jigsaw puzzle by painting each piece in isolation with the belief that, at the end, it will all fit and make a pretty picture. My special talent is that, somehow, it does.
I've learned that pretty top-level design documents are worth almost nothing, and that you need to get into the messy guts of a problem and see what shape reality itself wants to take. Then build upwards. I've seen too many plans that have big boxes in their entity diagrams saying, essentially, "the magic happens here" with neatly labelled arrows leading in and out.
Sorry, but computers don't do that. What you really mean is that there needs to be a big box on your project Gantt chart labeled "the work happens here" with the name of your best programmer written below it, and no completion date.
There's a saying; "First, you need to define the problem." And that's absolutely true, but it doesn't automatically follow that the solution will then be obvious, or possible. Fermat's last theorem was a perfectly straightforward question, simple even, defined in precise mathematical terms. And it still required 300 years of work.
In my case, the hardest job was handling the renaming of fields. Assume all the fields in a table are re-named, and potentially re-ordered. How do you apply the changes to an older copy of the database if, by definition, the identifying information has been lost? (Solution: attach unique ID metadata to the database fields. In the 'description' if you have to.)
Explaining computer programming is awfully hard. There aren't really very good metaphors, and so programming stories generally end up as boring as fishing stories, bogged down in incomprehensible detail. Or you try to make it metaphorical, even lyrical, but it looses all touch with the reality of what you did.
You can't even just show off the finished program, because often the most complex coding is hidden behind a simple and clean interface. Just look at the Google homepage; you really have no idea how staggeringly difficult it is to turn a single box of search terms into a simple list of results, because it's all out-of-sight, and you assume. Programs which seem the most complicated are usually just offloading the intelligence requirements onto the user.