Datenbank - Normalisierung Richtlinie oder Pflicht?

[Grolle]

Hallo,

ich habe mal eine grundsätzliche Frage und würde gerne hören wie Ihr das handhabt! Ich habe in meiner neuen Anwendung eine Rechtesystem. Diese besteht aus einem Formular, ~ 40 Checkboxen wo man die Rechte entsprechend zuweisen kann. Soweit so gut. In der Datenbank wird der Wert als string gespeichert (also 40x 0 oder 1 hintereinander). Laut erster Normalform müsste ich aber 40 Felder mit boolean-Werten speichern (atomarer Wertebereich), was aber beim verarbeiten ungemein aufwändiger wäre. Sind Normalformen verpflichtend einzuhalten oder sind das eher "Richtlinien"?

Viele Grüße ...

[mkinzler]

Wenn du die Tabelle richtig Normalisieren würdest hättest du 40 Einträge und nicht 40 Felder. Ich würde das aber nicht als aufwendiger ansehen, da du den string ja auch zerlegen musst.
Die von dir gewählte Lösung sieht man aber recht oft.
In der Regel ist Normalisierung aber sinnvoll, wobei von fall zu Fall aber entschieden werden muss, welcher Normalisierungsgrad ( bis zu welcher Normalform) sinnvoll ist.

[freak4fun]

Es sind Richtlinien. Niemand wird bei dir vorbei kommen und schauen das du auch ja die höchst Mögliche Normalform hast. :mrgreen:

[alzaimar]

Eine Datenbank muss immer so konzipiert sein, das sie für den Aufgabenbereich optimal geeignet ist. Eine Verwaltungs-DB wird immer an der 3.NF orientiert sein, wobei man nicht jedes Detail durchnormalisieren muss. Ein Datawarehouse dagegen bricht mit so ziemlich jeder Konvention hinsichtlich des Normalisierens, hier geht es nur um Geschwindigkeit bei der Auswertung.

Bei deinem Design sehe ich große Probleme bei der Auswertung und Filterung. Stringoperationen eignen sich nicht dazu, Daten effizient zu filtern. Auch wirst du auf deine kodierte Information keinen Index setzen können, um Abfragen zu beschleunigen.

Wenn Du jedoch eh nur wenige Einträge hast, ist das wurscht. Aber dann kannst Du auch eine Stringlist nehmen und deine Daten als Textdatei ablegen.

[Grolle]

Hi,

Zitat:

Zitat von mkinzler

Wenn du die Tabelle richtig Normalisieren würdest hättest du 40 Einträge und nicht 40 Felder.

So war das auch gemeint!

Zitat:

Zitat von freak4fun

Es sind Richtlinien. Niemand wird bei dir vorbei kommen und schauen das du auch ja die höchst Mögliche Normalform hast. :mrgreen:

Glück gehabt :zwinker:

Zitat:

Zitat von alzaimar

Bei deinem Design sehe ich große Probleme bei der Auswertung und Filterung. Stringoperationen eignen sich nicht dazu, Daten effizient zu filtern. Auch wirst du auf deine kodierte Information keinen Index setzen können, um Abfragen zu beschleunigen.

Der String wird ja nur einmal bei der Benutzeranmeldung aus der Datenbank gelesen. Somit habe ich für eine "Session" alle Rechte in einem String und kann die auf die entsprechenden Elemente in der Applikation verteilen. Einen Index werde ich da nicht brauchen. Es werden ja schätzungsweise nur 5-20 Rechtegruppen.

Viele Grüße ...

[Satty67]

Blöde Laienfrage:

Wenn schon komprimiert auf einen Wert, wäre es dann nicht einfacher, die 40 Bool-Werte in einem 64bit Integer zu speichern und die Bits abzufragen?

[Grolle]

Hi,

Zitat:

Zitat von Satty67

Blöde Laienfrage:

Wenn schon komprimiert auf einen Wert, wäre es dann nicht einfacher, die 40 Bool-Werte in einem 64bit Integer zu speichern und die Bits abzufragen?

Klar, ist auch naheliegend, aber der Wert kann natürlich auch noch wachsen. Wieviel, kann ich jetzt noch nicht sagen.

Viele Grüße ...

[omata]

Zitat:

Zitat von Grolle

...der Wert kann natürlich auch noch wachsen. Wieviel, kann ich jetzt noch nicht sagen.

Und genau deshalb solltest du Normalisieren, nur dann ist dein System flexibel. Somit schließt sich der Kreis und wir sind wieder bei der ersten Antwort...

Zitat:

Zitat von mkinzler

Wenn du die Tabelle richtig Normalisieren würdest hättest du 40 Einträge und nicht 40 Felder.

Normalisierung ist wichtig, damit die Datenbank die Möglichkeit erhält die Daten selbstständig korrekt zu halten. Diese Datenintegrität ist das wichtigste Merkmal der Normalisierung und die wichtigste Funktion einer Datenbank. Eine Datenbank enthält die Daten einer Firma, das sind die wichtigsten Informationen, sie halten länger als jede Anwendung. Softwareprogramm sind unwichtig, im Vergleich zu Daten in einer Datenbank. Deshalb ist die Normalisierung dieser Daten oberstes Ziel und immer durchzuführen. Die Überlegung, nicht zu normalisieren ist einfach nur sträflich. Damit schaufelt man sich sein eigenes Grab, weil man nicht flexibel und sicher (Datensicherheit) auf Veränderungen/Neuerungen reagieren kann bzw. eben ein unnötiger Mehraufwand entsteht.

Fazit: Mach es gleich ordentlich.

[Grolle]

Hi,

@omata
Die Datenbank ist ja bis auf diesen einen Punkt normalisiert. Der String ist für die Lösung mit der ich am flexibelsten bin, aber eben nicht ganz im Sinne der 1 Normalform :angel2:

Viele Grüße ....

[Phoenix]

Also ich kenne Systeme, die sind zwar normalisiert, in der DB werden jedoch keine Relationsinformationen gepflegt. Das heisst, obwohl ein Feld eigentlich ein Fremdschlüssel ist, kann man alles dort eintragen - auch wenn es in der eigentlich referenzierten Tabelle keinen Eintrag zu dem Schlüsselwert gibt. Hintergrund ist Performance, bzw. konkret das Vermeiden von (sehr kurzen, aber sehr häufigen) Table-Locks wenn eine der ansonsten referenzierten Tabelle aktualisiert wird.

Genauso kann man aus Performancegründen auf eine Normalisierung verzichten, wenn es wirklich notwendig ist. Aus Erfahrung kann ich jedoch auch sagen: Wenn es nicht durch besondere Gründe notwendig ist, auf die Normalisierung zu verzichten, gibt es keinen Grund es NICHT zu tun :zwinker: