Agreed, but... What good is a logging table if you don't have some sort of index on it? If you have a LOT of logging entries, you're looking at a LONG search time. So yeah, it depends on what you're doing, but it's a general "best practice". I personally don't like the idea of a keyless table... why not make sessionId, timestamp, remotehost, and URL your compound primary key? That way you've got guaranteed data integrity (you can't have the exact same data in the table twice) for audit purposes and your searches would be a lot faster.
The idea of a non-updatable table doesn't really apply here since we're talking about issues when Reactor's save() method can't be used correctly... although I suppose that's only an issue if you're trying to update a record. Creating one could conceivably work, but it won't know which columns values to exclude from the insert. On udpates it doesn't know which column to use for the wbere xx = yy. Anyway... I do agree that they're never mandatory. I just don't get why you'd decide not to have one. Laterz, J On Tue, 8 Aug 2006 00:26:44 +0200 wikiwikiman <[EMAIL PROTECTED]> wrote: > As usual, everything depends on what you want to do with > your table. > E.g. if your just logging certain events in your > application, why > would you need a PK, and if so how would you define it? > Or: what if > you don't want/need rows in your table to be updatable, > for auditing > reasons? > > Having found out the hard way, I agree that PK are mostly > a good idea > - but a good relational database design does not require > them on ALL > your tables. > > Wouter -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
