Optimale Datenbankstrukur

[Darksoldier7]

Hallo zusammen,
ich stehe vor einem kleinen Problem und hoffe, dass ich hier ein paar Tipps bekomme.

Ich schreibe ein Programm, dass z.B. Krankheiten archivieren kann. Es soll Auswahlkriterien, in dem Beispiel hier Symptome, bereitstellen und dann die Krankheiten auswählen, die zu diesen Symptomen passen.

Nun mein Problem: Da die Datenbank sehr groß werden kann/wird, brauche ich eine optimale Datenbankstruktur.
Was würdet ihr mir in diesem Fall empfehlen?

Liebe Grüße,
Darksoldier7 aKa Chilee

 

[Prophet]

Also optimal ist immer relativ. Du solltest dich immer daran halten möglichst kleine datentypen zu verwenden ohne das du mögliche eingaben ausschließt (Inkubationszeit braucht kein int da es nie einen wert um die 4 mrd. erreicht).

Um eine konkrete struktur vorzuschlagen muss man wissen was genau gespeichert wird und welche daten optional einfach oder mehrfach auftreten. Ausserdem was für daten enthalten sind.

Bei großen datenbanken ist auch immer wichtig darauf zu achten das man die richtige Datenbank auswählt. Man kann nicht grundsätzlich MySQL verwenden und SQlite würde bei sowas vollkommen überfordert. Mal ein bisschen umhören und dann schauen welche bei deinen anforderungen die beste leistung liefert (MSSQL, MySQL, Oracle, usw.). Allerdings habe ich hier keine großen erfahrungen meine projekte waren bis dato nur spielereien die nie große datenbanken brauchten.

 

[Darksoldier7]

Natürlich, ich dachte, dass das selbstverständlich ist - werde wohl bei MySQL bleiben, wenn es Wikipedia schafft wird es wohl auch das schaffen.
Mir ging es persönlich eher um die generelle Struktur, dass man die Datentypen möglichst klein halten sollte sehe ich als Selbstverständlichkeit an. Ob ich eben eine Tabelle "Krankheit" und "Symptome" oder eine für beides usw. machen sollte, da mir bis jetzt keine wirklich sinnvolle eingefallen ist.

Liebe Grüße,
Darksoldier7 aKa Chilee

 

[Prophet]

Du solltest schon etwas präziser sein was die informationen angeht welche gespeichert werden sollen. Eine krankheit kann mehrere symptome haben und viele krankheiten haben dieselben syptome. Also brauchen Krenkheiten und symptome auf jeden fall getrennte tabellen. Eine frü die krankheiten (id, name, beschreibung, inkubationszeit, ansteckung, usw.) und eine für die syptome. Wobei du dir noch überlegen musst auf welche art du die symptome mit den krankheiten verknüpfst. Schließlich kann ja ein symptom auf mehrere krankheiten zutreffen, genauso wie mehrere krankheiten ein syptom aufweisen können.

 

[Darksoldier7]

Hallo Prophet,
genau da weiß ich nicht weiter - wie verknüpfe ich die Symptome mit den Krankheiten? Andersrum wäre es ja leicht...
Mir ist bis jetzt nur die Lösung eingefallen, jedem Symptom eine einzigartige Nummer zu geben und sie in verschiedene Teilgebiete zu unterteilen. Die Krankheiten hätten dann eine Nummer, ähnlich der ISBN.

Hier ein Beispiel:
Person A hat Halsschmerzen, Kopfschmerzen und ihre Gelenke schmerzen.
Jetzt ist "Halsschmerzen" in der Tabelle "HNO-Symptome", Kopfschmerzen bei "Allgemein-Symptome" und "Gelenkschmerzen" bei "Rheumatische-Symptome"(Nur als Beispiel, ich weiß nicht, ob die Gruppen stimmen)
Die Krankheiten haben dann in einem extra Feld eine - mit bestimmter Syntax - Nummer, die die Symptome einsetzt. Sie könnte so aussehen:

[HNO-Beschwerden]-[Allgemein-Beschwerden]-[Rheumatisch-Beschwerden]

was dann so aussehen könnte:
745-638-45

Was hältst du/ihr von dieser Lösung?

Lieber Gruß,
Darksoldier7 aKa Chilee

 

[Prophet]

das problem ist nur das eine krankheit vll mehr als ein symptom pro gruppe hat. Ich würde die symptome auch nicht so kategorisieren. Du könntest alle syptome in einer tabelle lagern und jedes mit einer id verpassen. Jede krankheit hat dann ein blob/binary/varbinary feldindem die ids aller verknüpften syptome steckt. Um gekehrt sollten auch die syptome einen solchen link zu allen krankheiten enthalten die sie beschreiben. Das ist zwar theoretisch redundant erleichtert aber die rückwärtssuchen nach krankheiten die zu speziellen syptomen passen sehr!

> MySQL AB :: MySQL 5.1 Referenzhandbuch :: 11.4.2 Die BINARY- und VARBINARY-Typen
> MySQL AB :: MySQL 5.1 Referenzhandbuch :: 11.4.3 Die Spaltentypen BLOB und TEXT

 

[w7]

in einer der vergangenen iX stand ein Artikel über die Partitionierung von Datenbanken in PostgreSQL (glaube ich... vllt war es ja auch Oracle), ich würde an deiner Stelle eine solche Partitionierung mit internen Verknüpfungen durchführen.

 

[Prophet]

Ja stimmt, für die suchoptimierung sehr sinnvoll:
> Forenblogger » Datenbank richtig nutzen (2) - Partitionierung

 

[Darksoldier7]

Die Idee mit dem TEXT-Feld klingt sehr plausibel. Ich würde es nur etwas abändern:
Jedes Symptom bekommt in einem TEXT-Feld die id aller Krankheiten, die dieses Symptom aufweisen.
Wenn man jetzt 3 Symptome angibt, die jeweils auf ein paar Hundert Krankheiten zeigen, werden die herausgefiltert, die am meisten Übereinstimmung haben.

 

[Prophet]

Du könntest als such parameter ja noch einstellen das die krankheiten mit allen symptomen oder mit einem teil aller syptome übereinstimmen müssen. Ich würde aber kein textfeld sondern ein blob oder binary verwenden!

 

[morl]

Kommaseparierte Wertepaare oder gar Blob-Felder in der Datenbank sind nicht sonderlich sinnvoll für die verknüpfung von Datensätzen und zudem auch noch sehr unflexiebel.
Man könnte zur verknüpfung eine Struktur wie folgt verwenden:

Tabelle 1: disease
Tabelle 2: symptom
Tabelle 3: disease_symptom_rel

Tabelle 1 und 2 enthalten die entsprechenden Daten und jeder Datensatz in ihnen eine eindeutige ID.
Die Tabelle 3 würde dann nur 2 Felder bekommen die die ID's der Tabellen 1 und 2 miteinander verknüpft.
So ist es recht einfach möglich Verknüpfungen hinzuzufügen oder zu entfernen. Mit einfachen JOIN's kann man sich so die benötigten Daten holen.

werde wohl bei MySQL bleiben, wenn es Wikipedia schafft wird es wohl auch das schaffen

Hast du dir mal die Serverarchitektur hinter Wikipedia angeschaut. Da sind locker 50 Datenbankserver am rödeln um die Last zu bewältigen. Ich glaube aber kaum das deine Datenban solchen Belastungen ausgesetzt wird.

Ich kann aus Erfahrung sagen, das MySQL mit großen Datenbanken eine Probleme hat. 2 GB Datenbankgröße steckt MySQL noch locker weg. Wenn du allerdings kompliziertere Datenbankabfragen hast, dann sollte man schon optimieren oder die Hardware aufstocken.
Jedes Datenbanksystem kommt bei einer gewissen Last an seine Grenzen aber da nehmen sie sich alle nicht so viel...es sein denn man hat genügend Geld in der Tasche ;)...aber in diesen Fall lohnt sich dann eher die Anschaffung weiterer Hardware.

Ich glaube aber kaum, das du mit den Krankheiten und Symptomen auf eine Datenbankgröße kommst die in irgendeiner Art und Weise bedenklich wäre. 5 Millionen Datensätze sind bei guter Behandlung noch lange kein Problem.

 

[Darksoldier7]

Hey morl,
danke für die Antwort! Hört sich sehr vielversprechend an :)
Ach ja, wegen MySQL - das läuft alles nur in meinem "home-RZ", und da hab' ich die möglichkeit bis 3-4 Computer zu clustern, die auf hohe Leistungen kommen, die für dieses Projekt reichen sollten.

Lieber Gruß,
Darksoldier 7