Sure. Dangerous to generalise on these things. The old problem of rippling cascade keys, is a nasty one and like you say - depends on whether the dat involved is likely to remain static or be modified once created. it also comes down to issues of performance vs flexibility and whether one needs to or wants to make use primary key index to enforce data integrity.
For huge databases it can become very important to make good and optimal use of indexes, not just for searching and lookups but also to speed up sorting and reports. On 17/10/06 01:06, "Karen" <[EMAIL PROTECTED]> wrote: > > On Oct 16, 2006, at 7:42 PM, Daniel Stenning wrote: > >> The principle of linking relational tables via real data is part >> of the >> whole RDB approach > > That is exactly what I was told about 17ish years ago and how I setup > DB's... > > But sometimes it can get hairy when the components of compound keys > (or even single field text keys) needs to change (as many human > readable things tend to do) in a relational scheme unless the DB > itself handles the updating of all the tables that hold relational > links to that record through that text (compound or not) key. > > What I wound up doing in certain situations (it's not best for ALL > situations) is defining multiple keys for performance... > > A string (compound or single) key to enforce uniqueness efficiently > (lots of records being added often) and searching/sorting, but also > create an increment based primary integer key to make relational > links to that record. > > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives of this list here: > <http://support.realsoftware.com/listarchives/lists.html> > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
