« As We May Hack | Main | ADSL: 28 Months Later »

Counters as identifiers: a stupid evil plot

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.


April 14, 2004 10:02 PM

Comments

Christian Murphy
(April 14, 2004 11:18 PM #)

Good point in general. (Manually joining queries sounds like an extreme form of masochism.)

For what it's worth, you can change the URLs fairly easily on Movable Type, through the Weblog Config / Archiving section in the Admin interface. Lots of info available through this search:

http://www.google.com/search?q=MTArchiveDate+format+MTEntryTitle+dirify

Mark Pilgrim's Apache redirect had to do with forwarding from old URLs. If you don't want to bother with that you don't have to. You can keep the old article files or delete them. (Movable Type won't delete them on its own just because you change your archive paths.)

Craig McClanahan
(April 15, 2004 07:33 AM #)

Your basic point can actually be broadened a bit -- PKs should never be visible to users (as part of a URL or anything else). It's amusing, and saddening at the same time, to see the blogserver community finally understand this and start offering the concept of "permalinks". Why should they have ever published anything *but* permanent URLs in the first place?

On the other hand, if your blogserver's backup policies are so bad that they can't restore a database from a backup tape (and therefore restore your PKs), you've probably got more serious problems :-).

Bill de hra
(April 15, 2004 11:02 AM #)

Craig,

Yes, my point is that MT permalinks expose counters by default.

But.. backup policy doesn't count for anything if the applications backup/restore functions don't work or are brittle - every operator learns this eventually. The time Berekely DB died I had a full backup. But in MT, it only takes one failed read on an entry in the restore/import process to hose the key order and thus the URLs. MT's dump format is line-oriented but it might as well have been binary in its brittleness - XML is your only man for this stuff.

Anyway, the details of the backing store should be wholly incidental to restoring the entries (which are identified in web-space not db-space).

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1224