Hi,

spielt es für die Perfomanz der DB prinzipiell eine Rolle ob einwertige PKs oder mehrwertige PKs benutzt werden?

Bei mir ist es nämlich so, dass ich durch die Normalisierung ziemlich viele größere PKs(~3Spalten) und dadurch auch größere FKs hab. Wenn ich nun eine Abfrage über mehrere Tabellen mache, wird die bei der normalisierten Version natürlich ungleich komplexer. Schlägt sich das auf die Performanz nieder?

Wie sind eure Erfahrungen???

...oder hängt das von der benutzten DB ab?

Viele Grüße,
KarlW

Warum nimmst du keine surrogate keys?

ich dachte, das widerspricht dem Normalisierungskonzept??? Die Tabellen sind dann größer, als sie sein müßten. Außerdem müßte noch die Integrität der Daten implementiert werden. Wenn beispielsweise 2 gleiche Datensätze eingefügt werden merkt das die DB ja nicht.

Außerdem dachte ich, dass ist ein schlechtes DB-Design, wenn man surrogate keys verwendet wos nicht notwendig ist???

Viele Grüße,
Karl

Dringend empfohlen: http://www.amazon.com/exec/obidos/tg/de ... 0201485559

Wo auch immer du deine Meinung herbekommst, es war keine gute Quelle...

... das war keine Aussage, sondern nur eine Frage. Und der Link zu dem Buch hilft mir jetzt auch nicht weiter.

Nach meinem Verständnis ist es doch so (und bitte korrigiere mich wenn ich irgendwo falsh liege!):
1) Durch die Einführung eines Surrogate keys wird ein zusätzliches Feld eingeführt, welches den bisherigen (merwertigen PK) ersetzt. Folglich entsteht eine transitive(?) Abhängigkeit. Was ich meine ist, dass es eine Abhängigkeit gibt:
surrogatePK <- ehemaliger zusammengesetzter PK <- restliche Felder der Tabelle
... und das ist mit Sicherheit ein Verstoß gegen die 3. oder 4. Normalform

Daher die Frage:
1) Ist ein Surrogate Key kein Verstoß gegen die Normalisierung?

2) Wem dem so ist, ist dann ein Surrogate Key nicht ein "Indiz" für ein schlechtes DB-Design?

Viele Grüße,
Karl

Jetzt wird philosophisch. :)

Eine bis ins Unendliche getriebene Normalisierung mag zwar akademisch gesehen sehr hübsch sein, muss aber weder die schnellste, noch die übersichtlichste/eleganteste Lösung sein.

Die von dir genannten zwei gleichen Datensätze, welche die Datenbank angeblich nicht erkennen würde, kannst du natürlich mit einem eindeutigen Schlüssel (unique-key) versehen.

Schöne Grüße
Sven

Karl, deine Aussagen sind komplett falsch. Es ist eher traurig dass dir mein Link nicht weiterhilft, aber das ist nunmal deine persoenliche Entscheidung.

@christian:
Mein Kritikpunkt war: Ich hab Dir eine konkrete Frage in einem Forum gestellt und Du schickst mir ein Link auf ein Buch bei Amazon... toll.
Mir ist auch klar, dass es Bücher zu dem Thema gibt.

@sven:
Nett, dass wenigstens einer auf meine Frage näher eingeht. :)
Ich weiß, dass ich nen unique key dazumachen kann. Ich meine damit nur, dass ich einen zusätzlichen Mechanismus programmieren müßte, welcher die Datensätze prüft, damit keine "Dubletten" in der DB entstehen können, die ich gar nicht will. (Bsp: 2 Personen in einer Tabelle Person, die sich nur anhand des Surrogate key unterscheiden, sollte es nicht geben). Deswegen dachte ich, dass es ein schlechtes DB-Design wäre, wenn sowas theoretisch möglich wäre.

Viele Grüße,
Karl

Du kannst dir das Wissen auch als PDF kaufen: http://www.dbdebunk.com/page/page/1103793.htm

@sven
...achso ... Mißverständnis. Man kann ja auch die einzelnen Felder unqiue machen. Das wäre eine Möglichkeit.

Hi Christian,

ich wollte mir aber kein Buch kaufen(auch nicht als PDF), sondern die Meinung von Leuten hören. Ich dachte dazu wären solche Foren hier da?

Da meine Frage bzgl. des Designs wohl nicht zweifelsfrei beantwortet werden kann nochmal meine andere Eingangsfrage:

Sind einwertige Primärschlüssel schneller als composidPKs?
Einsatzszenario:
"Tiefe" der Tabellenstruktur <= 6
composid IDs wären warsch. maximal 8 Felder groß.
Die Inhalte der "tieferen Tabellen" werden um einiges häufiger geändert, sind aber von der Spaltengröße eher klein (ca. 4 bis 5 Felder + PK)
2 Tabellen mit Spaltenanzahl größer 20 (+PK). Sonst unter 10 (+PK).

Ich hoffe, das ist ausreichend um Auskunft darüber geben zu können ob surrogatekeys hier einen Performanzzuwachs bringen können und wieviel Prozent das ausmacht.

Viele Grüße,
Karl

5%

@christian
dann sage ich mal danke für den Link :) Wenn es mein Thread wäre würde ich Dich dafür raten ... so ein Buch habe ich schon lange gesucht. Kommt auf jedenfall auf die "Must-Have"-Liste

@KarlW
Nimm es mir jetzt bitte nicht übel (auch wenn ich damit leben kann, wenn Du es doch tust) ... aber ich hoffe Du machst das nur für Dich und Du hast keinen zahlenden Kunden .... der wird sich nämlich in kürzester Zeit schwarz ärgern über das DB-Design. Oder der arme Kerl, der die SW/DB erweitern darf, nachdem Du schon gar nicht mehr daran denkst.

Achja ... und nur mal so am Rande ... um sicher zu stellen, dass keine doppelten Einträge in der Datenbank auftauchen, brauchst nun wirklich nix mehr zu programmieren ... das kann eine Datenbank schon ...

Von daher ... vielleicht doch mal ein Buch kaufen ...

Aber auch ich möchte Deine Frage beantworten ... mit der Antwort, die schon immer die wichtigste war: 42 ...

gtx
curio

P.S.: Sorry, aber musste sein ... denn ich darf im Moment eine Datenbank mit bis zu 6-wertigen, zusammengesetzten Schlüsseln anpassen ... und das ist wahrlich kein Spass ...

Ganz genau. Die zusammengehörigen Felder sind dann genauso eindeutig wie ein n-wertiger Primärschlüssel eindeutig wäre. Der unique constraint gilt für beide.
Du musst also in diesem Fall genauso viel - oder besser gesagt wenig - selbst programmieren. Einen doppelte Eintrag würde die Datenbank in beiden Fällen (aufgrund des unique constraints) nicht zulassen.

Schöne Grüße
Sven