in reply to Re: Re: Safe for SQL
in thread Safe for SQL


why doesn't your DBA or whoever is in charge of the DB and tables.. just set up an identity column. that way, each time a record gets inserted - it will have a unique ID.


it just may be a bit easier for you and them.

Replies are listed 'Best First'.
Re: Re: Re: Re: Safe for SQL
by Anonymous Monk on Dec 10, 2002 at 17:03 UTC
    Well, that's a good suggestion, but The Voice Of Reason is not resposible for much, if any, of what gets done here. The problem is that I have to send one and I need to know if this will do with no problems/errors. Thanks though.
Re: Re: Re: Re: Safe for SQL
by jk2addict (Chaplain) on Dec 17, 2002 at 19:43 UTC

    Sometimes, IDENTITY columns are a Bad Thing for uniqueness (AKA, why I like uuid instead). Why? Well, three reasons IMHO.

    1. They're finite. Let's take a shopping cart as a simple example. If I have an IDENTIY/AUTOINC column for each item added, that adds up over time. Will I max out that BIGINT field? Eventually. Granted it may be a loooong time down the road, but why build in that limitation to begin with?

    2. Uniqueness. :-) What's the difference between row 243 in one table and row 243 in another table? Sometimes, nothing except their uuid. For example: db data change logs in an app. If each row has a unique id, then I can use it as a foreign key in the log data table. Sure I could use numbers, but uuids provide a little more assurence that the foreign key IS correct, instead of coincidentally matching by number.

    3. Sometimes, IDENTITY/AUTOINC columns are pure evil. I've seen on more than one occasion that the ident/autoinc seed for a table gets reset, after which time the next IDENTITY number may actually be from a record that was previously deleted. Next thing you know a join is fubar just because a new entry aquired an old identity seed. It shouldn't happen, but it does sometimes.

    My point? Good question. :-P