I guess then I am curious why we have chose to use them in the first place
for a majority of our tables.
I disagree with your arguement for not using them (there are other valid
reasons why some don't like them, but the mutliple entries problem is
easily avoided).
You can avoid, (AND SHOULD do so!), multiple entries by putting a unique
constraint on the columns in question (the ones that did make up the pkey).
No error checking is ever done/or needed by the user.
any way, I won't commit any changes. I just would like to see some
consistency in how our tables are developed.
mike
> Hi!
>
> I am (as always) strongly against surrogate keys (and any other surrogate
> stuff) for the fact that they are surrogate - they do not have any real
> ground. I see no benefit in their existence and a lot of bad. the first of
> them mentioned before and, for example, that this would allow for multiple
> entries with same set of FKs which would be ambigous data. You then need to
> put your own error checking instead of taking advantage of DB capabilities.
>
> So, although I am not a commiter, so it does not formally count, I would
> give my strong -1 here.
>
> dixi
>
> fedor.
>
>
>
>
>
> _______________________________________________________
> Tired of slow Internet? Get @Home Broadband Internet
> http://www.home.com/xinbox/signup.html
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
