ERM - Wie füge ich am günstigsten Daten ein?

[P4r4]

Hi,

folgendes:
Ich habe ein Personalien-Datenbankmodell normaliesiert.

Ich habe einen Entity-Typ namens personalien mit folgenden Attributen:

id, email, handy, gebid, nameid, vornameid, strasseid, hausnrid, plzid, ortid, lk1id, lk2id, telid

Die Attribute mit der Endung id stehen jeweils in einer n:1 Beziehung zu einem Entity-Typ dessen Namen identisch mit dem Teil vor id ist.
Bspl.:
zu gebid gehört das Entity-Typ: geb;
zu nameid gehört das Entity-Typ: name;
...
(AUßER: lk1id, lk2id. Dazu gehört der Entity-Typ lk mit den Attributen: lkid und lkname)



Diese Entity-Typen haben jeweils die Attribute (z.B. bei geb) gebid und geb.

Die Dazugehörigen Tabellen habe ich auch schon in MySQL erstellt. (Dies SQL-Datei habe ich angehängt)
_______________
Wenn ich nun eine Person in die Datenbank aufnehmen will, wie setze ich das am sinnvollsten um?

Zunächst müsste doch überprüft werden, ob bereits ein identischer Eintrag in einer den Tabellen geb, name, vorname, strasse, hausnr, tel, lk, ort oder plz vorhanden ist.

Wenn keiner vorhanden ist, muss ein neuer Eintrag in den entsprechenden Tabellen erstellt und die neue id in die taballe personalien übernommen werden.
Wenn einer vorhanden ist, so muss nur die id des bereits vordhandenen Eintrags übernommen werden.

Wie kann ich nun dies am besten mit einer möglichst geringen Anzahl von SQL-Querys umsetzen?

(Einigermaßen verständlich? )

[seb]

Wow...dafür dass das, wenn ich die in deiner Erklärung vorkommenden Begriffe "lk1" und "lk2" richtig interpretiere, eine Abiturienten-Datenbank werden soll, gehst du die Sache ganz schön gründlich an....ein bisschen zu gründlich, würd ich sagen.

Welchen Sinn soll es haben, für jede Eigenschaft einer Person eine eigene Tabelle anzulegen, wenn keine davon mehr speichert als einzigen Wert?

Okay, du sparst vielleicht ein paar Bytes an Speicherplatz ein, wenn es im Jahrgang 10 Leute gibt, die "Matthias" heißen, und der String "Matthias" so nur 1x statt 10x gespeichert werden muss.

Aber auch nur auf den ersten Blick. Für mich sieht das nach ner Milchmädchenrechnung aus: Wahrscheinlich benötigen die zusätzlichen Tabellendefinitionen mehr Speicherplatz, als du damit bei ein paar hundert gespeicherten Personen einsparst.

Und selbst bei einer Million Datensätzen hättest du bestenfalls ein paar hundert Kilobyte rausgeholt.

Ich bezweifel sehr, dass das den zusätzlichen Implementierungsaufwand und den Performanceverlust durch das bei jedem Lesevorgang erforderliche "Zusammensuchen" der Daten aus den verschiedenen Tabellen (wenngleich der natürlich genauso unter die Kategorie "praktisch nicht wahrnehmbar" fällt) wert ist.

Fazit: Bleib einfach bei einer Tabelle. Damit würde das Hinzufügen einer neuen Person exakt einen Query kosten - das wären dann so wenige wie möglich .

[P4r4]

Hi,

danke für deine Antwort.

Es ist nichtmal für einen Jahrgang ... es ist nur für einen Kurs

Also es ist für unseren Informatikkurs. Wir behandeln gerade Datenbanken und mein Lehrer hat mich gebeten einen Part daraus zu übernehmen. Dabei soll eine Kurs-Datenbank erstellt werden, in der wir weitgehendst normalisieren.
Grundsätzlich hast du recht! Es würden kaum Anomalien auftreten, wenn ich EINE Tabelle nehmen würde. Nur wir sollen das halt so lösen, um das Prinzip zu verdeutlichen.

Das ERM habe ich schon entwickelt und vorgestellt und in Tabellen einer MySQL-DB haben wir das auch schon umgesetzt.
Das nächste mal würden wir dann an das Eingeben der Daten gehen. Wie das geht ist mir schon klar, nur wie und wo kann ich mir Querys dabei sparen?
Gibt es eine Möglichkeit eine Art if-Anweisungen in ein Query einzubauen?
... Ansonsten würde ich den großteil über PHP lösen.

Danke
Para