Agreed. The only point I was making that ( particularly for anyone new to
the world of relational databases ) it is advisable to always try and look
for data in each record that uniquely identifies the row, before resorting
to automatic numbered keys. For example using a unique 8 digit user id made
up from the users name ( such as DANSTENN for my name ) as the primary key
would have many advantages over a numeric rowid - speed  basically. One can
then sort by the userid, serach by userid, and in many queries migh only
need to access the primary index- thus speeding things immensely.

Off topic in a way but worth reiterating (imo)

On 16/10/06 23:44, "Norman Palardy" <[EMAIL PROTECTED]>
wrote:

> 
> Many times normalizaton practices would dictate that you have a
> possibly meaningless unique key.
> Sometimes there is data that is unique per person that makes a nice
> key (social insurance number, employee number, etc)
> But sometimes there is no such candidate key and you have to invent one
> 
> In many databases rowid is a nice identifier for this purpose as it
> has no implicit meaning
> 
> And, that's the context in which this whole thread started. SQLIte
> has a rowid, but, buy default it is NOT a great candidate because
> SQLite does not insure that row id's are unique primary autoincrement
> columns. However, as Marco pointed out IF you define a key with those
> attributes then you will have one in you schema.
> 
> That's all I was suggesting; that you explicitly define such a key
> and not assume that one will be provided or created for you by the
> database engine.
> 
> _______________________________________________
> 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>

Reply via email to