atomisierte Datenbank ?

[Fantasyfr]

Also erst mal eins Vorweg und zwar wollte mir jemand weiß machen das dieses Model angeblich total "schei**e" ist:

Beispiel:

Tabelle: User
ID|Username|Password
1 |Hans    |Zaun
2 |Blub    | Der

Tabelle: User2Info
ID|user_id|user_info_id
1 |1      |1
2 |2      |2

Tabelle: user_info
ID|Straße  |Ort
1 |Allee  1|Musterstadt
2 |Blastr 2|Musterstadt

Er hat dann irgend was von atomisierten Datenbank geredet die dann ungefähr so aussehen:

Beispiel:

Tabelle: Username
ID|Username
1 | Hans
2 |Blub

Tabelle: Password
ID  |Password
Hans|Zaun
Blub|der

Tabelle: Straße
ID  | Straße
Hans| Allee 1
Blub| Blubstr 1

Tabelle: Ort
ID   | Ort
Hans | Musterstadt
Blub | Musterstadt

Also ich finde dieses System nicht gerade Vorteilhaft.
Meine Frage gibt es dieses System "atomisierte Datenbank" wirklich? Wenn ja gibt es irgend eine Seite wo man sich darüber belesen kann ?
Achja er sagte noch das mein System (erstes Beispiel) sehr langsam bei großen Datenmengen (so ab 100.000) wäre. Stimmt das?

Mfg
Fantasyfr

[Rouven]

Hello,

hmh, also mein spontaner Eindruck ist, dass sein Modell ziemlich daneben ist. Ob dein Modell optimal ist, darüber kann man streiten, je nachdem ob man von der Straße auf den Ort schließen kann wäre da nochmal eine Aufspaltung drin, aber im Prinzip...
Du hast zwei Tabellen, die jeweils einen Sacheverhalt abbilden (obige Anmerkung mal außen vor):
Benutzer
Adresse
und die dazugehörige Kreuztabelle.
Wenn dir allerdings ernsthaft jemand den anderen Vorschlag gemacht hat wäre zu fragen, ob du uns Teile vom Modell unterschlägst -- vielleicht hat der Vorschlag ja einen Hintergrund.
Generell sei dir der Wikipedia-Artikel zum Thema Normalisierung angeraten.
Performancemäßig bist du mit deinem Modell tendenziell besser bedient, du musst zur Wiederherstellung des gesamten Sachverhalts zwei Joins ausführen, im anderen Modell 3.

MfG
Rouven

[Fantasyfr]

Hello,

hmh, also mein spontaner Eindruck ist, dass sein Modell ziemlich daneben ist. Ob dein Modell optimal ist, darüber kann man streiten, je nachdem ob man von der Straße auf den Ort schließen kann wäre da nochmal eine Aufspaltung drin, aber im Prinzip...
Du hast zwei Tabellen, die jeweils einen Sacheverhalt abbilden (obige Anmerkung mal außen vor):
Benutzer
Adresse
und die dazugehörige Kreuztabelle.
Wenn dir allerdings ernsthaft jemand den anderen Vorschlag gemacht hat wäre zu fragen, ob du uns Teile vom Modell unterschlägst -- vielleicht hat der Vorschlag ja einen Hintergrund.

Nunja er erklärt mir nächste Woche mehr über sein System, dann kann ich ja mit mehr Infos zurück kommen ^^. Er meinte aber noch zu mir, das ich mein System am besten so schnell wie möglich vergessen solle weil es laut ihm humbuck ist.

Generell sei dir der Wikipedia-Artikel zum Thema Normalisierung angeraten.
Performancemäßig bist du mit deinem Modell tendenziell besser bedient, du musst zur Wiederherstellung des gesamten Sachverhalts zwei Joins ausführen, im anderen Modell 3.

Nunja hier ist er mit dem Spruch gekommen das bei mir die gesamte Tabelle in den Arbeistspeicher geladen werden muss bei ihm nicht
sondern nur die Tabellen die er zum angegebenen moment brauch.

Achja er sagte noch irgend was davon das seine Datenbank am Ende ca. 1000 Tabellen haben wird. Frage ist das überhaupt mit MySql möglich?

MfG
Rouven

[Rouven]

Hello,

Achja er sagte noch irgend was davon das seine Datenbank am Ende ca. 1000 Tabellen haben wird. Frage ist das überhaupt mit MySql möglich?

möglich vielleicht, weiß nicht genau wo die Grenze liegt, müsste ich nachschlagen. Aber extrem unüblich, so ein Modellansatz ist mir in 10 Jahren nicht unter gekommen.
Für gewöhnlich hat die reine Lehre (siehe Normalformen) das Problem, dass mit zunehmender Normalisierung das Datenmodell so zerstreut ist, dass die Anzahl der Joins auf die Performance drückt. Dementsprechend wird stellenweise dazu tendiert, das Modell NICHT aufzuteilen sondern maximal bis auf die 3. NF runterzugehen, teilweise nur auf die 1.
Sein Argument mit dem "alles Laden" ist nur bedingt nachvollziehbar. Ja, er kann anhand eines Benutzers vielleicht schnell rausfinden, in welcher Stadt der wohnt, dazu muss er nur zwei Tabellen joinen, aber er bildet damit keinen fachlichen Zusammenhang ab. Sein Modell ist gewissermaßen auf den einzigen Zweck ausgerichtet der Anwendung bzw. ihren Anforderungen zu dienen. Eigentlich ist der Konsens, dass Daten stabiler sind als Funktionen, so dass man ein korrektes Modell der relevanten Umwelt aufbaut und darauf seine Funktionen aufsetzt.
In seinem Modell alle Straßen in Musterdorf zu finden ist extrem krank, wenn nicht stellenweise falsch - er müsste nämlich alle Nutzer aus Musterdorf finden, dann deren Straßen - wo ist der Sinn? Was macht er, wenn ein Benutzer in zwei Orten wohnt? Dann bringt seine Zerlegung sogar falsche Treffer - sie ist demnach zwar verlustfrei, aber nicht abhängigkeitserhaltend, um da mal zwei Begriffe einzustreuen.

MfG
Rouven

[Ilja]

yo,

normalisierung, bzw. datendesign ist schwieriges thema. meine erfahrung ist die, das selbst in diverser literatur und webseiten (wikipedia eingeschlossen) es falsch verstanden wird.

grundsätzlich ist es so, dass für den einen das datendesign stimmig sein kann und für den anderen wäre genau das gleiche model nicht mehr stimmig. daraus folgt, es gibt nicht das EINE daten-design, sondern es ist umgebungsabhängig, bzw. wie deine fachlichen vorgaben sind.

viele verstehen schon gar nicht den sinn von normalisierung. es geht nicht darum, redundanzen zu entfernen, das stimmt nämlich gar nicht, sondern es geht um abhängigkeiten und somit um kontrollierbarkeit. das ist der einzige sinn und zweck von guten datenbank-design und somit auch von normalisierung.

da wir deine fachlichkeiten nicht kennen, können wir auch nicht beurteilen, ob es gut oder weniger geeignet ist.

Ilja