I came across some code once. It was an API wrapper around some DB calls. Some of the API calls had integer argument. Turns out these are were taking primary keys as arguments, some of which were fixed to constants in the code. My guess this had something to do with the integrity being managed by App code (as repeated selects being joined in software) rather than the DB (as foreign key constraints or SQL based joins). I'm no DB expert then or now, nor do I claim to fully understand the pros and cons of DB v App managed integrity. But I don't imagine that was a very good idea. What if the DB has to be reconstituted and you're using auto-incremented pks (which is what that system happened to do)? Why pass pks around the code when you can use a join? I noticed a while back that Moveable Type uses numbers in its entry URLs. I haven't looked to see if these are bound to DB pks, but they are incrementing. This also strikes me as not a good idea. What if I have rebuild my blog and the numbers are rebound to different entries? Actually that's exactly what happened to me last year when the Berkeley db backing my MT install got totalled. Links people had made to my blog were rebound to different entries. It was off by six or something. Oops. I think Mark Pilgrim or someone wrote something clever once about indirecting MT entries using MT and Apache hacks, but I'm too lazy to look for it and naive enough to think I shouldn't have to. I suppose this is the bit where folks tell me that using GUIDs or URIs as primary keys is a stupid evil plot that any idiot would know about. Not enterprise enough perhaps. Certainly inefficient....
Previous Topic
