Mike Haberman wrote:
>> Therefore, I -1 your proposal as a commiter. I will lift it only if you
>> really
>> convince me (and the others) that those keys are neccesary.
>>
>> Rafal
>
>
> 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.
> Almost all our tables have autoincrement primary keys. These are surrogate
> keys (other columns could have been used instead, but were not).
As I said, they are not "surrogate".
> So for
> example, TURBINE_PERMISSION.PERMISSIONID is one. Surrogate keys are
> basically void of any semantic meaning. They solve a lot of problems.
They have _a lot_ of meaning ;-)
>
> 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.
fedor
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
