Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation

[Mavarik]

Zitat:

Zitat von jobo (Beitrag 1313713)

Aber Du hast Recht, letzlich dürfte genau das "beim Update vergessen" mit einem richtigen DM bei redundanzfreier Datenhaltung nicht passieren.

Gerade da... Nicht den bösen User vergessen, der per Restore Zwei verschiedene Versionsstände zurückspielt...
Bei einer Tabelle kann Dir das nicht passieren...

Redundanzen sind Supi... Dann kann ich bei einem Datenverlust alles wieder herstellen... Beste Beispiel ist ein Neu & Änderungsjournal.

Eine Inkonsistenz wurde festgestellt... Kein Thema zurück zu letzten bekannten Version und ab da das Journal nochmal loslassen...

Jede Datenbank kennt Ihren aktuellen Journalstand? Bingo - Der böse User hat was falsches Kopiert... Total egal... Das System ist selbstheilend durch Redundanz...

Mavarik

PS.: So macht es meine Software auch... Nur die Exe noch auf der Platte - Kein Thema schwupdiWup alle RTF Files und alle anderen Dateien und Unterverzeichnisse sind wieder da... Wer braucht noch Installationsprogramme... :-)

[DeddyH]

Reden wir jetzt wirklich von Datenbanken oder von irgendwelchem selbstgestrickten Record-Geraffel? In "richtigen" DBMS geht es nämlich eher darum, Redundanzen zu vermeiden, um Inkonsistenzen auszuschließen.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1313721)

Reden wir jetzt wirklich von Datenbanken oder von irgendwelchem selbstgestrickten Record-Geraffel? In "richtigen" DBMS geht es nämlich eher darum, Redundanzen zu vermeiden, um Inkonsistenzen auszuschließen.

Nun ja ... so ganz nun auch wieder nicht ;)

In den richtigen Systemen unterscheidet man Read- und Write-Model. Das Write-Model ist die Wahrheit und das Read-Model ist eine Projektion dieser Wahrheit.

Warum? Weil es in den meisten Systemen mehr Lese- als Schreibzugriffe gibt. Und mit den richtigen Read-Modellen kann man die Last einer Datenbank erheblich verringern, weil eben keine JOINS benötigt werden.

Das Write-Model ist aber auf jeden Fall nicht redundant.

[jobo]

Zitat:

Zitat von DeddyH (Beitrag 1313721)

Reden wir jetzt wirklich von Datenbanken ..

Also selbst bei Records halte ich Redundanzen für unpraktisch bzw. kritisch. Und ja, ich habe von Datenbanken geredet und spreche aber von Redundanzen im Sinne der Normalform (wie im Negativ Beispiel angeführt PLZ>Ort).

Ein Logsystem, welches Werteänderungen mitschreibt setze ich auch ein, wie sicher auch viele andere, aber das ist vollkommen autark und in keiner Weise logisch in die Datenverarbeitung involviert, nicht mal transaktional, was man ja sonst idR auch gerne hat bei einem RDBMS, sonst wäre es größtenteils sinnlos.

Dass so ein Log ggF. bei einem Recoveryproblem o.ä. helfen kann, ist klar, dafür wurde es ja u.U. aufgebaut.
Ein solches Log hat aber mit der NF nichts zu tun.

[jobo]

@Sir Rufo
Es war aber von Datenmodell und Haltung die Rede, nicht von Transport und Darstellung oder?

[frankyboy1974]

Hallo,

die meisten Programmierer kennen die ersten drei Normalformen, tatsächlich hat Codd aber wesentlich mehr Normalformen veröffentlicht. Ich würde deswegen raten, das Problem verstößt gegen die 25. Normalform.:-D

mfg

[Sir Rufo]

Zitat:

Zitat von jobo (Beitrag 1313727)

@Sir Rufo
Es war aber von Datenmodell und Haltung die Rede, nicht von Transport und Darstellung oder?

Jepp, Read- und Write-Model liegen ja auch in dem/einem DBMS. Mit dem Transport oder der Darstellung hat das nichts zu tun - ausser, dass sich das Read-Model daran orientiert, was nachher in der Darstellung benötigt wird.

[Aurelius]

Zitat:

Zitat von jobo (Beitrag 1313712)

@Aurelius: Hast Du im Arbeitsvertrag stehen, dass Du niemals die Normalform verletzen darfst? ;)

Meine Rückfrage war eher Interessenshalber, da ich dort keine Verletzung erkennen kann. :) Aber allgemein versuche ich die Datenbank so "perfekt" wie möglich zu halten. Macht es einfacher eine schöne Anwendung darum zu stricken und gibt mir ein gutes Gefühl :angel:

Zitat:

Oder anders: Wenn es um Inhalte geht, die meine eigene Anwendung nutzt, auswertet und sich jenachdem anders verhält, würde ich eine hohe Bindung an die Kernobjekte bevorzugen.
Sind es dagegen "irgendwelche" Kundendaten, die vielleicht sogar selbst beim Kunden nur importiert werden, nie oder selten angefasst werden und nur für einen weiteren DL gehalten und dann exportiert werden, würde ich das sehr gern "weiter weg" lagern.

Gefällt mir :thumb:

[Dejan Vu]

Wenn man nicht aufpasst, hat vor lauter 3NF die Performance außen vor gelassen. Dem RDMBS ist es i.a. egal, ob man nun 10 oder 50 bit-Spalten pro Datensatz hat. Na ja, zumindest ist das bei SQL-Server so.

Also, ich würde mir das 2x überlegen, ob ich die Optionen wirklich alle einzeln in einer Detailtabelle vorhalten würde.

Es kann ja sein, das man das gruppieren kann. Oder einfach doch 100 Bit-Spalten in die Tabelle klatschen. Von der Performance her ist das jedenfalls bei weitem das Beste.

Ich habe Anwendungen, bei denen der Kunde solch optionale Spalten selber deklariert und die Anwendung im Hintergrund die Tabelle per ALTER TABLE einfach entsprechend updatet.

Man muss imho beim DB-Design immer Einfachheit, Performance und Normalform in Einklang bringen.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1313771)

Es kann ja sein, das man das gruppieren kann. Oder einfach doch 100 Bit-Spalten in die Tabelle klatschen. Von der Performance her ist das jedenfalls bei weitem das Beste.

Kann ich ausdrücklich bestätigen, zumindest für alle Fälle, in denen die DB große bis riesengroße Datenmengen vorhält. In meiner OSM-Verwaltung (OpenStreetMap) hatte ich anfangs auch erst versucht, wie aus dem Lehrbuch alle Redundanzen weitgehend zu vermeiden – mit dem Ergebnis, daß Abfragen inakzeptabel lange benötigten. Nachdem ich die Normalisierung wieder soweit rückgängig gemacht hatte, daß in der Tabelle für Orte (Millionen von Datensätzen) die Bundesländer, Länder, Provinzen etc. als String verfügbar waren und nicht mehr als Verweis auf die jeweiligen Sub-Tabellen BUNDESLAND, LAND, PROVINZ etc., bewegten sich die Abfragezeiten wieder in erträglichem Rahmen.