Link to home
Start Free TrialLog in
Avatar of Fej
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
ASKER CERTIFIED SOLUTION
Avatar of kelfink
kelfink

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of nigelrivett
nigelrivett

If you want to be pedantic - the definition of a database (or at least one) includes that every row is unique - to guarentee this you must have a unique constraint on every table.
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).
Avatar of Fej

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
If this is one to many then you should put a unique index on the one field or have some means of preventing duplicates.
Avatar of Fej

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