✔ [mySQL] Normalformen

D

DerEisige

Erfahrenes Mitglied
Hallo ich bin es mal wider.
Ich hadere gerade mit den Normalformen herum.
Der Theorie nach sollte man ja soweit gehen wie im folgenden beispiel.
2014-08-05_162648.jpg
Aber macht das wirklich sin?

Wen in der Tabelle MediumNameTyp dann insgesamt nur 3 Einträge sind (Titel, Synonym, Kanji),
das gleiche gilt auch für Sprache da sind es 5 Einträge.

Macht es da nicht mehr sin das alles in die Tabelle MediumName zu packen?
schon aus übersichtlichen gründen, denn wen man immer alle Normalformen einhehlt wägst die anzahlt der Tabellen schnell ins unermessliche und ich habe jetzt schon Probleme die Tabellen passend zu benenn.



Nun ist die Frage was ist sinnvoller wenn man es unter diesen punkten betrachtet Speicherverbrauch, Übersichtlichkeit und Funktionalität der Datenbank.
 
DerEisige hat gesagt.:
Nun ist die Frage was ist sinnvoller wenn man es unter diesen punkten betrachtet Speicherverbrauch, Übersichtlichkeit und Funktionalität der Datenbank.
Zum Vergrößern anklicken....

Speicherverbrauch: Heutzutage spielt der eher eine untergeordnete Rolle. Oder hast du Milliarden von Datensätzen?
Übersichtlichkeit: Eher eine Frage der Software, die dir die Tabellen anzeigt.
Funktionalität: Sollte bei normalisierten und nicht (oder nicht vollständig) normalisierten Datenbanken dieselbe sein.

Ich möchte gerne noch einen weiteren Aspekt in den Raum werfen: Performance.

Normalisieren geht durchaus mit Performanceeinbußen einher, wenn du ständig JOIN-Operationen ausführen musst. Natürlich gibt es auch hier Optimierungsverfahren (u. a. Materialized Views).

Auch Erweiterbarkeit spielt eine Rolle.
 
Zuletzt bearbeitet:
Ich hatte da an Materialized Views gedacht*, die es in MySQL allerdings (nativ zumindest) gar nicht gibt.

Aber ja, Views generell dienen eher der Zugriffskontrolle, denn beim Zugriff tun sie nichts anderes als das dahinterstehende Query auszuführen.


*) Ich habe es oben korrigiert
 
  • Ob komplett normalisieren Sinn macht oder nicht hängt sehr stark auch davon ab wie du/die Applikation vor hast die Daten abzufragen und anzuzeigen. Wenn du z.B. immer alles zusammen ausgeben willst, ist es wahrscheinlich Performance-technisch einfacher alles in einer Tabelle zu haben. In der Realität wird man aber wahrscheinlich meistens nur einen Teilbereich anzeigen lassen.
  • Diskspace ist Heute kein Problem mehr. Was hingegen immer eine kritische grösse ist, ist disk I/O. Dh. wenn ständig Daten von der Disk ins Memory hin und her geschrieben werden müssen kann auch das beste RDBMS nicht viel machen. Dieses Risiko ist bei Denormalisierten Datenbanken wahrscheinlich grösser.
  • Je weiter man normalisiert desto mehr joins werden nötig wenn man wieder alles verknüpfen möchte. Einen join auszuführen kostet die DB etwas. Es ist aber so, dass joins die Paradedisziplin jedes RBDMS sind.
  • Wichtige Gründe warum man normalisiert sind Datenintegrität und Redundanzen.
  • Updates auf Denormalisierten Tabellen können grosse locks verursachen.
  • Ein wichtiger Punkt den man nie ausser acht legen sollte ist zudem die Erweiterbarkeit, wie bereits ComFreek geschrieben hat. Normalisierte Tabellen lassen sich meist einfacher erweitern und warten.
  • Grundsätzlich sollte man sich am Anfang immer an einem sauberen Design orientieren. Dann wird man sehen wie sich dieses DB Design in der Praxis schlägt. Und wenn man dann verbessern muss, gibt es diverse Optionen dazu (Indexe, Mat Views, Denormalisieren, ...)
  • Normalisierte Strukturen sind write-optimiert. Write ist langsamer als read-operationen. Wenn man extrem viel mal mehr read anstelle write-operationen hat, ist Normalisierung eher weniger attraktiv. (das ist aber eher im OLAP/DWH Umfeld der Fall und eher selten bei OLTP)
  • Übrigens: du hast echt 1:1 Beziehungen?? Wohl eher 1:n
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück