Fedor Karpelevitch wrote:
>> Any key that is assigned by the database system is considered surrogate.
>
> There is a big difference. Those tables which have IDs are "entity"
> tables, in which each row represents an entity (object if you wish). And
> ID is not surrogate here because it uniquely identifies this entity. No
> other field or combination of them can be used instead because all other
> fields are just attributes. In Permission table example you can argue
> that permission_name can be used instead, but it is not so. What if you
> want to change name of the permission (say you had a typo)? How would
> you tell that this is the same permission? That's what ID is for.
> Although any attribute may change ID will tell you that this is the same
> entity.
>> I apoligize if I was unclear in my first post. I can post more
>> informations regarding the benefits of them, but I didn't think it
>> would be a big problem since we are already making haavy use them. I
>> just didn't see why we were incosistent with our use of them.
>
> We are very cnsistent. The tables which do not have their own IDs are
> not "entity" tables, they are "cross-reference" tables. Rows in those
> tables do not represent any entities, so they do not need IDs.
I totaly agree with what Fedor wrote above. The current DB setup
seems very clear and consistent to me.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
