DenkzeitWiki

Suchen:

Aktuelle Änderungen Printable View Änderungen Bearbeiten

DBSchemaEvolution > DBTransformation > DLR > DynamicLanguageRuntime > DSL > DomainSpecificLanguages > DVCS > DistributedVersionControlSystem > DataAbstraction > DataBinding > DataCleaning > DataCrunching > DataDriven > DataDrivenProgramming > DataSets > DataSet > DatabaseDesignClear Trail
Main /

Database Design

DBMS
RDBMS

Normalisierung

On Keys

In a DB there is Data and Plumbing:

Plumbing refers to the primary and foreign keys that the DB needs to find database records and relate them to one another. [1]

Composite keys (multi column primary keys) make any kind of Object/Relational mapping and persistance in general harder. Life is so much easier with surrogate keys. You can always make unique constraints where it's necessary.

This is not a 'legacy' approach; this is the way the relational model works, and is the correct or 'normal' way to model this concept in a relational database.

The best compromise is probably to keep the proper composite primary keys in place, and add a surrogate single-column key with a unique constraint on it.

If a db developer is using surrogate keys correctly, then there is no problem. All they've done is take a natural key and created a surrogate for it, which can make many things easier to do in development.
The problem comes when developers haven't been exposed to the relational model and then they start thinking the surrogate key *is* the primary key.


On Constraints


Edit - BackLinks - Tags - Page Hist - Print - Changes - Home - Orphans - Help

Zuletzt geändert am 25.04.2007 21:56 Uhr und seit 7. April 2005 712 aufgerufen.