Fej
asked on
Is it ok to have a 'keyless' table in a database?
Hello,
I am structuring a database for the first time, and have been doing a little reading on 'good' database design.
I am under the impression that all 'good' database tables should have a unique key for each record. Is this correct? Or is it ok do have a table where the records don't have a unique key?
Thanks,
Fej
I am structuring a database for the first time, and have been doing a little reading on 'good' database design.
I am under the impression that all 'good' database tables should have a unique key for each record. Is this correct? Or is it ok do have a table where the records don't have a unique key?
Thanks,
Fej
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I should add that the 'keyless' table has another table which has a 'one-to-many' relationship with it. Does that keep it 'relational'? And referential blah blah is enforced.
Thanks,
Fej
Thanks,
Fej
If this is one to many then you should put a unique index on the one field or have some means of preventing duplicates.
ASKER
Thanks for the help both of you. To bad I can't split up the points. So I gave it to the first answer since both were good enough.
Cheers,
Fej
Cheers,
Fej
Or you could say that behind the scenes the database engine itself will hold row identifiers (physical location if nothing else).
Doesn't really matter - if you need a unique constraint then add one. Sometimes (e.g. for import tables) you don't want any constraints as it could cause problems with the import and you check the data and move it to production tables later.
In general - every table that doesn't just hold transient data would have a unique constraint - otherwise there will be no way of distinguishing dupicate rows (i.e. processing them individually).