Sehr viele Referenzen auf globalen Datenpool

Welcher der angegebenen Wege passt?

  • 1. Global, nur eine Tabelle Bestand, Kunde und Bestellung mit Fremdschlüssel jeweils auf den Händler

    Stimmen: 3 100,0%
  • 2. Pro Händler jeweils eine eigene Tabelle in einer Datenbank

    Stimmen: 0 0,0%
  • 3. Eigene Datenbank pro Händler mit jeweils drei Tabellen

    Stimmen: 0 0,0%
  • 4. Nichts von dem, was besser ist, erläutere ich im Thread...

    Stimmen: 0 0,0%

  • Umfrageteilnehmer
    3

baddax

Neuer Benutzer
Beiträge
4
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
 
Werbung:
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

Lösung 1. Falls Dir das von den Tabellengrößen als zu groß erscheint: Datenbanken können mit recht großen (Groß im Sinne durchaus im mehrstelligen Millionenbereich) hantieren - und das schnell. Und wenn das wirklich zu eng wird: Partitionierung. Viele kleine Tabellen haben den Nachteil, daß die internen Kataloge größer werden und Caching-Algorithmen ausgebremst werden.
 
Lösung 1, ganz klar. Alles andere ist unprofessionell.

Ich verstehe allerdings Deine Bestand-Tabelle nicht so recht.
 
Ich finde die Erläuterung unvollständig. Natürlich Lösung 1 vom Tabellenlayout her, aber:

Soll zu jeder Zeit mit dem gesamten Datenbestand gearbeitet werden oder sollen unterschiedliche Händler mit unterschiedlichen Servern an unterschiedlichen Standorten Zugriff auf unterschiedliche Informationen haben oder teilen sich alle den selben Bestand und es gibt nur einen Server?
 
Hallo,

danke für die Antworten und, @akretschmer, die Erläuterung des technischen Hintergrunds. Also insgesamt die fünf genannten Tabellen, Bestand, Kunde und Bestellung jeweils erweitert um das Feld haendlerId.

Zur genaueren Beschreibung des Szenarios:
- ein Webserver, auf den alle Händler und alle Kunden zugreifen, also dreischichtig: Browser <-> Webserver <-> DBserver
- Händler verwalten ihren Bestand, ihre Kunden und die Bestellungen
- Kunden suchen im Bestand des Händlers, dessen Kunde sie sind (und führen weitere Aktionen aus, wie z.B. eine Bestellung)
- weiteres im folgenden

Zum Schallplatten-Pool:
Alle Händler teilen sich den Plattenpool, um die Metadaten einer Platte einheitlich und genau einmal zu haben. Beispiel:
- neue Schallplatte der Rolling Stones wird veröffentlicht
- Händler A und B und C bestellen diese Platte für ihren Bestand
- Händler A fügt sie im System seinem Bestand hinzu; da noch nicht im Pool, gibt er dabei alle Metadaten ein -> neuer Eintrag in Tabelle Schallplatte, dann neuer Eintrag in Bestand mit schallplattenId und haendlerId
- Händler B und C fügen sie im System ihren Beständen hinzu; Platte ist bereits im Pool, sie geben keine Metadaten mehr ein -> für beide ein neuer Eintrag in Bestand mit schallplattenId und haendlerId

Im einzelnen zu den angefragten Punkten:
Ich verstehe allerdings Deine Bestand-Tabelle nicht so recht.
Jeder Händler hat einen Bestand an Platten. Dieser entspricht in der Regel einer Teilmenge aller Schallplatten (Händler A hat Platten im Bestand, die Händler B nicht im Bestand hat).
Kunden des Händlers durchsuchen dessen Bestand. Für die Suche und Darstellung werden die Metadaten zu den einzelnen Platten aus der Tabelle Schallplatte gezogen. Daher die Referenz 'schallplattenId'.

Etwas unsicher bin ich mir bzgl. der Suche: Bei nur einer Tabelle Bestand { id, haendlerId, schallplattenId } würde man in der Bestandtabelle immer auf Basis des Händlers suchen; alle Platten, die er eh nicht in seinem Bestand hat, müssen nicht durchsucht werden. Also:
1. Ziehe alle Platten aus Tabelle Schallplatte, die der Händler in seinem Bestand hat
2. Durchsuche die Ergebnismenge anhand von den Suchkriterien und liefere die passenden Platten
Das spricht wohl für ein gewisses Caching des Bestands eines Händlers, um ihn zu durchsuchen (wohl als Frontend-DB und nicht auf Applikationsebene (zu viel Daten). Das Thema DB-Caching ist dabei neu für mich...

Soll zu jeder Zeit mit dem gesamten Datenbestand gearbeitet werden oder sollen unterschiedliche Händler mit unterschiedlichen Servern an unterschiedlichen Standorten Zugriff auf unterschiedliche Informationen haben oder teilen sich alle den selben Bestand und es gibt nur einen Server?
Zu jeder Zeit und über einen Webserver mit verschiedenen Clients (Browsern), siehe Beschreibung des Szenarios zu Beginn dieses Kommentars. Jeder Händler hat seinen eigenen Bestand (siehe Anmerkung zum ersten Zitat). Abfragen erfolgen also immer im Kontext des Händlers der angemeldet ist, bzw. bei einem Kunden-User im Kontext des Händlers, den der User ausgewählt hat. Als Kunde logge ich mich also immer für einen bestimmten Händler ein, bzw. browse anonym durch den Bestand eines gewählten Händlers.

Hoffe, ich konnte das Szenario etwas deutlicher machen. Danke für die Rückmeldungen - Rückfragen und Vorschläge bitte jederzeit.
 
Etwas unsicher bin ich mir bzgl. der Suche: Bei nur einer Tabelle Bestand { id, haendlerId, schallplattenId }

Ich denke mal, diese Tabelle braucht keine eigene ID - Händler und Platte sind zusammen eindeutig und können als PK genutzt werden. Du sparst 1/3 (naja, nicht ganz) an Tabellengröße ein. Je nach Art der Suchanfragen ein Index über (händler,platte) und einer nur über platte sollten Abfragen flott machen.
 
1. Ziehe alle Platten aus Tabelle Schallplatte, die der Händler in seinem Bestand hat
2. Durchsuche die Ergebnismenge anhand von den Suchkriterien und liefere die passenden Platten
Das spricht wohl für ein gewisses Caching des Bestands eines Händlers, um ihn zu durchsuchen (wohl als Frontend-DB und nicht auf Applikationsebene (zu viel Daten). Das Thema DB-Caching ist dabei neu für mich...
Das wird dir zum Verhängnis werden und deine Abfrage nur verlangsammen. Entweder du hast einen zentralen DB Server oder du hast lokal eine DB Instanz die Daten des Master Servers spiegelt. Letzteres ist natürlich nicht trivial.
Ersteres hingegen bedeutet: Wenn du erst einen Teil der Tabelle an den Client schickst um ihn dort zu durchsuchen verlierst du viel Zeit und verschwendest Bandbreite. Wenn deine Suche komplett von der DB übernommen wird braucht das vieleicht einen Hauch mehr Performance an der DB aber deine Bandbreite wird geschont weil nur das Ergebnis über die Leitung geht. Die DB braucht mit einem passenden Index auf Bestand über HänderID nicht sehr lange um die verschiedenen Bestände zu unterscheiden.

Generell kann man noch sagen das man sich über das Recht auf Korrekturen an Tabellen wie Schallplatte Gedanken machen muss. Die Wirken sich ja auch auf alle Händler aus.
 
Danke, @beide, für die Rückmeldung. Ich habe den Eindruck, ich unterschätze die Leistungsfähigkeit von Datenbanken im Vorfeld zu sehr.

Ich denke mal, diese Tabelle braucht keine eigene ID - Händler und Platte sind zusammen eindeutig und können als PK genutzt werden.
Stimmt. Das kann man weiterführen - auch in Verbindung mit der Rechtevergabe und Mitarbeiterverwaltung:
Code:
Schallplatte {
   id (PK)
   titel
   interpret
   /*... weitere Metadaten*/
}

Haendler {
   id (PK)
   name
}

Person {
   id (PK)
   name
   /*... weitere Metadaten*/
}

Rolle {
   id (PK)
   titel
}

Benutzer {
   personId (PK)
   haendlerId (PK)
   rollenIds
}

Bestand {
   haendlerId (PK)
   schallplattenId (PK)
}

Bestellung {
   haendlerId (PK)
   personId (PK)
   schallplattenId (PK)
}

Auch bei den Tabellen Benutzer und Bestellung sind, wie bei Bestand, jeweils vorhandene Felder zusammen eindeutig.
Zudem kann so eine Person so bei verschiedenen Händlern Kunde oder auch Mitarbeiter sein, entsprechend der dem Benutzer zugewiesenen Rollen (Kunde, Verkäufer, Bestandverwalter usw.).

Wenn deine Suche komplett von der DB übernommen wird braucht das vieleicht einen Hauch mehr Performance an der DB aber deine Bandbreite wird geschont weil nur das Ergebnis über die Leitung geht. Die DB braucht mit einem passenden Index auf Bestand über HänderID nicht sehr lange um die verschiedenen Bestände zu unterscheiden.
Okay, das klingt gut. Lässt sich anhand der vorliegenden Infos eigentlich ggf. eine Empfehlung bzgl. Datenbankserver vornehmen?

Generell kann man noch sagen das man sich über das Recht auf Korrekturen an Tabellen wie Schallplatte Gedanken machen muss. Die Wirken sich ja auch auf alle Händler aus.
Ja, das stimmt. Entweder hat nur der Ersteller das Recht und andere können Änderungen vorschlagen. Oder alle Benutzer mit bestimmten Rollen können Änderungen vorschlagen, die vorgenommen werden, wenn der Ersteller in Zeitraum X kein Veto einlegt.
Oder bei dem Zufügen einer Platte zum Bestand kann ein Händler entweder auf den vorhandenen Eintrag in Schallplatten referenzieren (wie derzeit definiert), aber alternativ auch einen eigenen Eintrag vornehmen und dabei alle Felder anders definieren, die er anders haben will - dann liegt nicht so viel Verantwortung beim Ersteller des Schallplatteneintrags. Dann müsste man entweder in Tabelle Schallplatte noch eine Referenz auf den Originaleintrag haben oder eine weitere Tabelle einführen, die letztlich genau wie Tabelle Schallplatte aussähe, plus Referenz. So würde man bei Abfragen den Originaleintrag zu einer Schallplatte nehmen und dessen Felder ggf. mit den Werten, die ein Händler für "seinen" Eintrag gemacht hat, mergen.
 
Ich denke PG ist eine gute Wahl wenn man sich sowieso in das Thema reinarbeiten muss und es um so viele Datensätze geht. Know-How und Webclient-Werkzeugkästen werden sicher häufig MySQL preferieren aber ich kann mir nur Gründe vorstellen warum MySQL schlechter wäre als PG :)
 
Werbung:
Zurück
Oben