|
|
|
uneasy relationships between layers
Tuesday, November 20 2007
There was sleet on the ground this morning but with the boiler up and running it didn't take much effort for me to make my laboratory toastier than it has been since September. I made a fire in the woodstove but didn't tend it quite as religiously as I had been.
In the laboratory I put an effort into doing something I've been putting off for over a year: adding composite primary key support to my generic web-based MySQL editing system. Up until today, in the databases I created, I enforced a one primary key per table rule, but that rule doesn't exist in the wild world of databases. The recent effort to integrate X-Cart tables into my editing environment has finally forced my hand.
It turned out, though, that adding multiple primary key support was easier than I had imagined. In cases where I had multiple primary keys, I just made them into an associative array, serialized them, and stuck them to the ends of the various query strings where they're needed. It's a little clunky, but (like all complex systems) my editing system depends on layers of code added over different periods of time. Some is old and nearly obsolete, but the system relies on it nonetheless. Other stuff (like the code I added today) is new, but it only handles special situations while the nearly-obsolete code handles the stuff it misses. I'm sure our genome and Microsoft Vista are full of such imperfect code relationships. After a certain point one can be tempted to start over from scratch, building a system from the ground up without the uneasy relationships between layers. But it's hard to find the motivation when your old Frankencode works just fine.
For linking purposes this article's URL is:
http://asecular.com/blog.php?071120 feedback
previous | next |
