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

[Aurelius]

@ mkinzler:
Genau so einen Aufbau mit 3 Tabellen habe ich gemeint.
Aber bist du dir sicher dass die erste Variante die 2. Normalform etc. verletzt? Schließlich sind die Steuerinformationen ja nur abhängig vom Primary Key.

ID	Name	...	VIPKUNDE	MAHNSPERRE
1	Müller	...	1	0
2	Maier	...	0	0
3	Werner	...	1	1

@ Mavarik:
Warum ist eine dynamische Erfassung für dich so ein NoGo? Ich finde die eigentlich annehmbar

@ all: Danke für die Rückmeldungen

[Mavarik]

Zitat von Aurelius:

@ Mavarik:
Warum ist eine dynamische Erfassung für dich so ein NoGo? Ich finde die eigentlich annehmbar

Verteile Tabelle sind wie verteilte Datei...

Inkonsistenzen sind vorprogrammiert. Tabelle A wird upgedatet Tabelle B nicht Daten passen nicht mehr zusammen...
Eine Exception an der falschen Stellen... (Ja es gibt Transaktionen...)

Ein User kopiert eine Datei von a noch b oder nur eine Tabelle...

Alles unnötige Fehlerquellen - Einfach meine Erfahrung der letzten 34 Jahre Programmierung.

Eingabe in einem Grid? Vielleicht Deine..., aber meine Kunden können da nicht mit umgehen.

Die brauchen

Label: Edit
[ ] Checkcaption
Combobox [Speedbutton]

[&Speichern] [&Abbrechen]

Und nicht etwa ein DBNavigator mit Post & Refresh...

[DeddyH]

Zitat von Mavarik:

Inkonsistenzen sind vorprogrammiert. Tabelle A wird upgedatet Tabelle B nicht Daten passen nicht mehr zusammen...

Dann solltest Du Dein DB-Design aber noch einmal sehr gründlich überdenken. RDBMS sind ja eben dafür erdacht worden, damit so etwas nicht passieren kann.

[jobo]

Zitat von DeddyH:

Dann solltest Du Dein DB-Design aber noch einmal sehr gründlich überdenken. RDBMS sind ja eben dafür erdacht
worden, damit so etwas nicht passieren kann.

Vermutlich hat er das. Ich habe ihn so verstanden, dass es ein allgemeiner Beitrag zu seinen schlechten Erfahrungen war.
Aber Du hast Recht, letzlich dürfte genau das "beim Update vergessen" mit einem richtigen DM bei redundanzfreier Datenhaltung nicht passieren.

[Mavarik]

Zitat von jobo:

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 von 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.

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 von DeddyH:

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]

@Aurelius: Hast Du im Arbeitsvertrag stehen, dass Du niemals die Normalform verletzen darfst?
So eine Diskussion ist auf dieser Ebene m.E. müßig, bzw. gibt es bei Deiner Idee wichtigere Fragen. Wieviele Systeme gibt es, die bspw. explizit PLZ und Stadt abspeichern?
U.a. kann man sich vielleicht streiten, ob die Relationstabelle einen eigenständigen Primärschlüssel bekommt, wie vorgeschlagen oder ob die beiden Fremdschlüssel reichen, m.E. Geschmackssache.

Dymamische Anzeige/ Eingabe ist eine reine Kosten / Nutzen Geschichte. Wenn der Kunde zahlt, machst Du das Feld eben in die Maske rein. Wenn Du keine Lust und oder keine Zeit hast, obwohl der Kunde zahlt, tja..
Aber dann gibt es da Dinge, die würde ich von Fall zu Fall genau überlegen.

Beispiel Mahnsperre: Es kommt mir so vor, als ob das eine relativ zentrale Bedeutung für den ein oder anderen Business Case hat und das würde ich nicht unbedingt irgendwo unter ferner liefen abfackeln.
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.

[Aurelius]

Zitat von jobo:

@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

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