Hallo,
wie stelle ich folgendes Problem auf Datenbankebene dar:
Schallplatte {
id
titel
interpret
... weitere Metadaten: Veröffentlichungsjahr, Label, Illustrator, etc.
}
Haendler {
id
name
}
Bestand {
id
schallplattenId
}
Kunde {
id
name
}
Bestellung {
id
kundenId
bestandId
}
- Es gibt zehntausende Händler (Tabelle Haendler).
- Es gibt hunderttausende Schallplatten (Tabelle Schallplatte)
- Metadaten der Schallplatten (Titel, Interpret, Label, etc.) sind immer gleich, daher ein globaler Pool (Tabelle Schallplatte)
- jede Platte kann theoretisch bei jedem Händler im Bestand sein
- für ihren Bestand halten die Händler somit nur die ReferenzId auf die Platte im Pool (Tabelle Bestand)
- jeder Händler hat beliebig viele Kunden, die Platten bestellen (Tabelle Kunde)
- für die Bestellungen hält der Händler also nur die KundenId und die BestandId (Tabelle Bestellung)
- Usecases für Abfragen über mehrere Händler sind nicht primärer Bestandteil, wären aber ggf. denkbar (was aber natürlich auch über die Software geschehen kann):
--- "Händler A hat Platte X nicht. Welcher Händler hätte Platte X?"
--- Reports: "Wie oft ist Platte X verfügbar?" oder "Wieviel Bestellungen gibt es von Platte Y?" ...
Die Menge an Datensätzen ist also tendenziell eher höher bei den theoretischen Zahlen von 10000 Händlern * 100000 Platten, dazu die Kunden und Bestellungen pro Händler.
Ich frage mich jetzt, was hierfür die beste Architektur ist. Die "globalen" Pools für Platten und für Händler sind mE klar, jeweils eine Tabelle. Was wäre aber besser für die Daten Bestand, Kunde und Bestellung?
1. Global, also insgesamt jeweils nur eine Tabelle Bestand, Kunde und Bestellung mit Fremdschlüsseln jeweils auf den Händler
2. Pro Händler jeweils eine eigene Tabelle in einer Datenbank
3. Eigene Datenbank pro Händler mit jeweils drei Tabellen
4. Was anderes
Die Frage stelle ich mir bzgl. der Performance bei Abfragen, da bei entsprechender Menge an Händlern und Kunden viele Suchzugriffe 'zeitgleich' wahrscheinlich sind. Und sicher auch, ob der Ansatz so in die richtige Richtung geht...
Viele Grüße
Sebastian
wie stelle ich folgendes Problem auf Datenbankebene dar:
Schallplatte {
id
titel
interpret
... weitere Metadaten: Veröffentlichungsjahr, Label, Illustrator, etc.
}
Haendler {
id
name
}
Bestand {
id
schallplattenId
}
Kunde {
id
name
}
Bestellung {
id
kundenId
bestandId
}
- Es gibt zehntausende Händler (Tabelle Haendler).
- Es gibt hunderttausende Schallplatten (Tabelle Schallplatte)
- Metadaten der Schallplatten (Titel, Interpret, Label, etc.) sind immer gleich, daher ein globaler Pool (Tabelle Schallplatte)
- jede Platte kann theoretisch bei jedem Händler im Bestand sein
- für ihren Bestand halten die Händler somit nur die ReferenzId auf die Platte im Pool (Tabelle Bestand)
- jeder Händler hat beliebig viele Kunden, die Platten bestellen (Tabelle Kunde)
- für die Bestellungen hält der Händler also nur die KundenId und die BestandId (Tabelle Bestellung)
- Usecases für Abfragen über mehrere Händler sind nicht primärer Bestandteil, wären aber ggf. denkbar (was aber natürlich auch über die Software geschehen kann):
--- "Händler A hat Platte X nicht. Welcher Händler hätte Platte X?"
--- Reports: "Wie oft ist Platte X verfügbar?" oder "Wieviel Bestellungen gibt es von Platte Y?" ...
Die Menge an Datensätzen ist also tendenziell eher höher bei den theoretischen Zahlen von 10000 Händlern * 100000 Platten, dazu die Kunden und Bestellungen pro Händler.
Ich frage mich jetzt, was hierfür die beste Architektur ist. Die "globalen" Pools für Platten und für Händler sind mE klar, jeweils eine Tabelle. Was wäre aber besser für die Daten Bestand, Kunde und Bestellung?
1. Global, also insgesamt jeweils nur eine Tabelle Bestand, Kunde und Bestellung mit Fremdschlüsseln jeweils auf den Händler
2. Pro Händler jeweils eine eigene Tabelle in einer Datenbank
3. Eigene Datenbank pro Händler mit jeweils drei Tabellen
4. Was anderes
Die Frage stelle ich mir bzgl. der Performance bei Abfragen, da bei entsprechender Menge an Händlern und Kunden viele Suchzugriffe 'zeitgleich' wahrscheinlich sind. Und sicher auch, ob der Ansatz so in die richtige Richtung geht...
Viele Grüße
Sebastian