Große Datenbank / 1:n oder 1:1 ?

[Chrisi]

Hallo zusammen,

es ist mal wieder Zeit mir ein wenig Rat einzuholen :-) Ich plane eine große DB auf Basis von MySQL. Vollständige Datensätze, bzw. Daten die zusammengehören werden es wohl ca. 2 Millionnen werden.

Die Daten stammen alle aus verschiedenen Quellen, so das mal ein Datensatz einen Wert besitzen kann die in einer anderen Quelle nicht vorhanden sind. Vom Grundgerüst wäre es aber möglich eine maximale Anzahl an Werten zu bestimmen die grob für die Speicherung benötigt werden. Jedoch nicht unbedingt welche Werte genau, mal kann es ein Zahlenwert sein, anders wo aber wieder TEXT ...

Nun meine Frage, macht es Sinn eine Datenbank mit der Menge an Datensätzen in eine 1:N Tabelle zu schreiben ? Ein Datensatz hat im schnitt 10 Werte, was bedeuten würde:

10x2000000 = 20000000

Also wenn ich jetzt nicht falsch liege sind es ca. 20 Millionen :-) Ist sowas überhaupt machbar ? Bzw. macht es Sinn bei einer solchen Menge mit 1:N zu arbeiten ?

Eine 1:1 Beziehung würde mir das ganze optisch vereinfachen und die Zahl der Datensätze noch in einem anständigen Rahmen halten, jedoch bin ich damit dann recht unflexibel bei der Speicherung der Daten.

Die Belastung der DB wäre 2seitg auch recht groß, einmal werden in kurzen abständen immer wieder die Daten nachgeladen und aktualisiert, also eine Menge UPDATES und INSERTS und dann die Abfragen die von aussen kommen also die SELECTS.

Würde mich freuen wenn mir da jemand ein wenig helfen kann.

Viele Grüße

Chrisi ...

[Cheatah]

Hi,

Nun meine Frage, macht es Sinn eine Datenbank mit der Menge an Datensätzen in eine 1:N Tabelle zu schreiben ?

es macht auf jeden Fall keinen Sinn, diese Frage von der Menge der Daten abhängig zu machen. Reduziere die Betrachtung auf z.B. 100 Datensätze und stelle Dir die Frage, ob eine 1:n-Beziehung sinnbehaftet ist.

Eine 1:1 Beziehung würde mir das ganze optisch vereinfachen

Eine 1:1-Beziehung nennt sich "Spalte".

Die Belastung der DB wäre 2seitg auch recht groß, einmal werden in kurzen abständen immer wieder die Daten nachgeladen und aktualisiert, also eine Menge UPDATES und INSERTS und dann die Abfragen die von aussen kommen also die SELECTS.

Dann sorge nicht nur für passende Indexe, sondern für _wenige_ passende Indexe. Der Fokus sollte dennoch auf "passend" liegen.

Cheatah

[Ilja]

yo,

es macht auf jeden Fall keinen Sinn, diese Frage von der Menge der Daten abhängig zu machen.

wenn du ein grillabend für freunde machst, spielt dann bei deinen vorbereitungen und einkäufe die menge der eingeladenen gäste auch keine rolle ? bei mir schon, alleine wieviel bier ich kaufen muss, damit ich auch noch welche abbekomme....

Ilja

[Cheatah]

Hi,

es macht auf jeden Fall keinen Sinn, diese Frage von der Menge der Daten abhängig zu machen.
wenn du ein grillabend für freunde machst, spielt dann bei deinen vorbereitungen und einkäufe die menge der eingeladenen gäste auch keine rolle ? bei mir schon, alleine wieviel bier ich kaufen muss, damit ich auch noch welche abbekomme....

im Gegensatz zum Grillabend skalieren bei einer Datenbank die getätigten Einkäufe mit der Zahl der Gäste mit - eine ordentliche Planung (lies: DB-Layout) vorausgesetzt. Allein den Platz für die Gäste muss ich entsprechend groß wählen, bzw. ich muss rechtzeitig nachmieten.

Cheatah

[Ilja]

yo,

im Gegensatz zum Grillabend skalieren bei einer Datenbank die getätigten Einkäufe mit der Zahl der Gäste mit - eine ordentliche Planung (lies: DB-Layout) vorausgesetzt. Allein den Platz für die Gäste muss ich entsprechend groß wählen, bzw. ich muss rechtzeitig nachmieten.

und du kannst dir nicht vorstellen, dass die menge der datensätze eine rolle beim design spielt und sogar der inhalt der daten ?

Ilja

[Chrisi]

Hi,

wenn Ihr euch Googlebase mal anschaut könnt Ihr bestimmt besser verstehen was ich meine:

http://base.google.de/base/step1offerunauth?hl=de_DE

Dort kann man prima sehen wie unterschiedlich teilwese die Attribute sind die erfasst werden können. Dort kann man sich sogar selber seine eigenen Schablonen anlegen das macht die ganze Sache extrem flexibel, was ich super finde.

Dort werden immer Grunddaten erfasst, zu diesen Grunddaten werden dann immer Attribute hinterlegt. Bis dahin einfach :-)

Aber wie werden die veschiedenen Artikeltypen gespeichert ? Also jene die man ganz zum Anfang auswählen muss, die als Vorrausetzung für den ArtikelTyp festgelegt werden.

Ich nehme mal an das es dort auch eine Menge 1:N geben wird :-)

Viele Grüße ...

Chrisi

[Cheatah]

Hi,

und du kannst dir nicht vorstellen, dass die menge der datensätze eine rolle beim design spielt und sogar der inhalt der daten ?

der Inhalt der Daten selbstverständlich. Die Menge eher nicht. Die Menge der Änderungen, ja, aber nicht die der Datensätze.

Cheatah

[Ilja]

yo,

der Inhalt der Daten selbstverständlich. Die Menge eher nicht. Die Menge der Änderungen, ja, aber nicht die der Datensätze.

so ähnlich müssen die entwickler von access gedacht haben, machen wir erst mal ein dbms, dass bei 100 datensätze funktioniert und schauen dann, wie es im grossen aussieht.....

spass beiseite, die performance spielt neben anderen kriterien eine wichtige rolle beim entwicklen einer datenbank. die menge der datensätze hat in abhängigkeit vom design einen ganz wesentlichen einfluss darauf. deswegen verwundert mich deine aussage, das design nicht in abhängigkeit von der größe der datenbank zu sehen.

Ilja

[seth]

gudn tach!

wenn du ein grillabend für freunde machst, spielt dann [...] die menge der eingeladenen gäste auch keine rolle ? bei mir schon, alleine wieviel bier ich kaufen muss, damit ich auch noch welche abbekomme....

hmm, "welche"... *ueberleg*, ach so! du willst also deine gaeste mit alkohol gefuegig machen, du chuft!

prost
seth

[Ilja]

yo,

grundsätzlich kann mysql solche datenmengen verarbeiten. ich würde erst einmal den "normalen" weg der datenmodellation gehen und dann schauen, ob es überhaupt einen handlungsbedarf bezüglich der performance gibt. allerdings solltest du noch einmal ein wenig genauer sagen, um welche daten es sich handelt. so ist es schwer, sich ein bild davon zu machen.

Die Daten stammen alle aus verschiedenen Quellen, so das mal ein Datensatz einen Wert besitzen kann die in einer anderen Quelle nicht vorhanden sind.

dann sollte die spalte den wert NULL aufnehmen können, also keine grosse sache.

Vom Grundgerüst wäre es aber möglich eine maximale Anzahl an Werten zu bestimmen die grob für die Speicherung benötigt werden.

keinen plan, was du damit meinst. ;-) willst du damit sagen, dass bestimmte daten auf jeden fall vorhanden sein müssen, damit der datensatz aufgenommen wird ?

Jedoch nicht unbedingt welche Werte genau, mal kann es ein Zahlenwert sein, anders wo aber wieder TEXT ...

das kann auf ein nicht geeignetes datenbank-design hinweisen, muss aber nicht. aber dazu sind mehr details notwendig.

Nun meine Frage, macht es Sinn eine Datenbank mit der Menge an Datensätzen in eine 1:N Tabelle zu schreiben ? Ein Datensatz hat im schnitt 10 Werte, was bedeuten würde:

also eine 1:N tabelle besteht schon mal aus zwei tabellen und nicht einer, sonst kann man ja das 1:N nicht darstellen. ;-) und jetzt wird mir glaube ich auch klarer, was du mit zahlen und text meinst. du speicherst quasi attribute eines datensatz in die N tabelle und die attribute unterscheiden sich in ihrer domäne. das habe ich gerade auch bei meinem letzten datenbank-design gemacht, hatte aber auch "gute" gründe dafür. die frage bei dir ist, ob man diese atttribute nicht besser auf verschiedene spalten aufteilt ?

Also wenn ich jetzt nicht falsch liege sind es ca. 20 Millionen :-) Ist sowas überhaupt machbar ? Bzw. macht es Sinn bei einer solchen Menge mit 1:N zu arbeiten ?

gundsätzlich ja, sogar noch viel mehr. und 20 millionen wird es ja nur, wenn du wirklich alle 2 millionen datensätze mit all ihren attributen anzeigen willst. den bildschirm möchte ich sehen. ;-) also in aller regel sollte die abfragen weniger treffer beinhalten. wichtig ist dabei natürlich der index über den fremdschlüssel.

Eine 1:1 Beziehung würde mir das ganze optisch vereinfachen und die Zahl der Datensätze noch in einem anständigen Rahmen halten, jedoch bin ich damit dann recht unflexibel bei der Speicherung der Daten.

das ist eine möglichkeit, unter einer vorraussetzung, nämlich wenn die anzahl der attribute einen maximalwert nicht überschreitet, sagen wir 10. 1:N und 1:1 sind dann sicherlich beides gehbare möglichkeiten. welcher besser ist, dazu fehlen ein paar infos.

Ilja

[Chrisi]

Hi,

dann mal näheres zu meiner Planung :-) Ich möchte gern Produkdaten und Dienstleistungen erfassen.

Mein Plan:

Eine Tabelle namens "item_mask" mit "Masken", diese Maske legt fest welche Attribute eine Quelle hergibt, welche ich davon speichern möchte und wenn ich sie speichern möchte unter welchem Namen.

Die Tabelle ist quasie der "Bauplan" für Untertabelle item_attributes, in dieser werden immer nur die attribute die ein item haben kann zusammengefasst.

Leidergottes können sich die Atrribute unter den Produkten schon recht unterscheiden, mal wird eine Größe angeben "für z.B. Kleider oder Schuhe", mal ist es ein Abflugtermin für eine Kurzreise, die PS Zahl für ein KFZ oder wieviel Traffic zu einem DSL Anschluss gehört.

Vielleicht macht es auch Sinn 2 Tabellen zu erstellen die so verfahren:

item
item_attributes

Unter item speichere ich nur de Grunddaten, also das was fast immer zutrifft, und unter attributes kann ich über eine 1:n Beziehung alles ablegen was vorher keinen Platz gefunden hat. Die Daten die in der Tabelle item_attributes liegen würde dann wohl nur für die Ausgabe auf dem Monitor dienlich sein, bei Suchanfragen "Detailsuche" oder sowas diese Daten zu berücksichtigen dürfte es dann schwer werden, aber das wäre nicht so wichtig.

Denke das wäre eine Mischung aus beidem die Sinn macht und nicht so kompliziert ist wie meine erste Idee.

Wie würdet Ihr sowas machen ?

Viele Grüße

Chrisi ...

[Ilja]

yo,

was du machen willst ist, verschiedene entitäten in einer tabelle zu speichern (deswegen auch unterschiedliche attribute). wie gesagt, ich habe das bei meinem letzten db-design genauso gemacht, hatte aber auch einen grund, nämlich weil die anzahl der entitäten und deren attribute nicht fest bestimmbar war. oder mit anderen worten, es können in zukunft entitäten/attribute hinzukommen oder wieder verschwinden.

und genau das ist die frage bei dir. wenn du genau die jeweiligen entitäten und deren attribute ausmachen kannst, dann mach für jede entiät mit den entsprecheneden attributen eine eigene tabelle. wenn das nicht bestimmbar ist, dann muss du alle entitäten in eine einzige tabelle unterbringen und eben die attribute in eine n:m beziehung. welche attribute nun welcher datensatz haben kann, das wird in der attribute tabelle gespeichert, sprich einem attribut wird produkt/dienstleistung in einer extra spalte zugeordnet.

Ilja