Optimale Datenbankstrukur

**Darksoldier7** · 16.06.2007 12:17

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** · 16.06.2007 12:30

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** · 16.06.2007 12:41

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** · 16.06.2007 12:46

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** · 16.06.2007 13:22

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** · 16.06.2007 13:32

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 · 16.06.2007 13:33

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** · 16.06.2007 13:39

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

**Darksoldier7** · 16.06.2007 13:52

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** · 16.06.2007 13:55

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!

Thema: Optimale Datenbankstrukur

LinkBack

Themen-Optionen

Optimale Datenbankstrukur

Aktive Benutzer

Aktive Benutzer

Lesezeichen

Lesezeichen

Berechtigungen