[DB-Design] "IDs" als Integer oder String?

[bigpoint]

Ja, da ein Verein ja mehrere Sportarten betreiben kann.

Macht nichts, etwa so:

Sportvereine

- ID (INT AUTOINCREMENT)

- Name (Varchar)

- ... (Daten des Vereins)

Sportarten

- ID (INT AUTOINCREMENT)

- Sportarten_ID

- Bezeichnung

- ... (weitere Infos zur Sportart an sich)

Zwischen Sportvereine und Sportarten 1-n Beziehung, für die Tabelle Sportarten zusammengesetzter Schlüssel aus ID und Sportarten_ID

[geloescht_JesterDay]

Zwischen Sportvereine und Sportarten 1-n Beziehung, für die Tabelle Sportarten zusammengesetzter Schlüssel aus ID und Sportarten_ID

Vielleicht verstehe ich deinen Ansatz nicht, aber

1. ist eine autoinc ID für die Sportarten ja eine weitere (noch künstlichere) ID. Die Sportarten_ID reicht doch schon als PK, oder nicht?

2. Und wo stellst du bei diesen Beispiel den Zusammenhang zwischen Verein und Sportart her? Eben in der Art

Verein.ID - Sportart.ID

1 - 1

1 - 2

2 - 1

3 - 1

4 - 2

4 - 3

1 - 3

EDIT:

Oder ist die Sportarten Tabelle bei dir schon die Verbindungstabelle?

Dann hättest du doch aber nichts gewonnen, oder? Oder du hast zu jeder Sportart einen neuen Eintrag für jeden Verein der sie ausübt. Selbst wenn sie von 3 versch. Vereinen ausgeübt wird.

[bigpoint]

Oder ist die Sportarten Tabelle bei dir schon die Verbindungstabelle?

Ja aber vergiss deine Zwischentabelle die ist hier überhaupt nicht nötig.

Dann hättest du doch aber nichts gewonnen, oder?

Doch eine Tabelle weniger was wiederum bedeutet einen join weniger also bessere performenc, lesbare sql query usw…

Zu Beispiel 2

Verein.ID - Sportart.ID

1 - 1

1 - 2

2 - 3

3 - 4

4 - 5

4 - 6

1 - 7

Also Verein 1 hat zwei Sportarten (Judo und Karate) usw..

[el_pollo_diablo]

Vielleicht verstehe ich deinen Ansatz nicht, aber

da bist du nicht der einzige

Ja aber vergiss deine Zwischentabelle die ist hier überhaupt nicht nötig.

und wie würde das ganze dann aussehen, wenn z.b. verein 2 ebenfalls judo und karate anbietet? dann müssen in der sportarten-tabelle einträge dupliziert werden, was man ja vermeiden möchte, oder?

[geloescht_JesterDay]

Doch eine Tabelle weniger…

Und redundante Sätze dazugewonnen, das hast du noch vergessen

EDIT:

Dein Ansatz ist meiner, nur vor der Normalisierung.

EDIT2:

Ironie:

Eine weitere "Optimierung" wäre doch dann, die Sportarten gleich zu den Vereinen in 1 Tabelle zu nehmen. Dann würde man generell nur 1 Tabelle haben, die SQLs wären einfach und übersichtlich...

Das ist bei der Normalisierung von relationalen DBs eben immer die Sache. Man bekommt mehr Tabellen und muss die joinen. Wie weit man da gehen möchte muss sich jeder überlegen, aber den Schritt zu den 3 Tabellen sollte man hier schon tun.

[bigpoint]

Up.., ihr habt recht in diesem fällen braucht man die Zweieschentabelle.

:schlaf:

Ich habe die Tabelle Sportarten total anderes verstanden

Sorry

[Goos]

Es ist beides Möglich, dass habe ich auch nicht abgestritten! Aber wenn man eine Eindeutige Eindeutigkeit (1 mal pro Datenbank) haben möchte, dann ist ein Unique besser und wie gesagt unter MS SQL ist ein Unique schneller als ein Bigint.

Bitte gib doch Quellen oder sonstige Beweise an, wenn du schon so seltsame Behauptungen aufstellst.

"Ein GUID ist unter MS SQL schneller als ein BIGINT" ist abgesehen davon eh eine Stammtischaussage, da einerseits nicht angegeben wird wobei genau der Identifier schneller sein soll und ausserdem weder GUID noch BIGINT ihnen eigene, spezifische Geschwindigkeiten besitzen.

Goos

PS: Ich behaupte natuerlich das Gegenteil