String in Mehrdimensionales Array wandeln

[Delmar]

Hallo Atarimaster,

ich kann diese Struktur nicht anwenden, da ich insgesamt knapp 50 verschie-
dene Felder in dem Formular habe. Teilweise normale Einzelfelder wie z.B.
"SystemName", "InstalledPerson", "SerialNo", etc.

Dann habe ich aber wiederum diese kombinierten Felder, die ja eigentlich eine
Art Tabelle darstellen. Neben den genannten "Firewall" und "External DNS" gibt
es auch andere wie "External Storage". Hier wären die Felder wie folgt:

externalStorage_0_volume
externalStorage_0_size
externalStorage_0_type
externalStorage_0_filerName
...

Von dieser Struktur kann ich nicht weg, da der Kunde zum einen maximale Flexi-
bilität bzgl. der Erweiterung der Felder und Revisionssicherheit fordert. Daher
die folgende kompletet Tabellenstruktur:

name (Parametername)
value (Wert)
created (Datum)
created_by (User)
changed (Datum)
changed_by (User)
status (aktiv / inaktiv)

Wird der Wert eines Feldes geändert, wird der bestehende Eintrag auf Status
inakitv gesetzt und ein neuer Eintrag mit dem gleichen Parameternamen aber
dem neuen Wert angelegt. Wie gesagt, Priorität 1 in dem Projekt sind Flexibilität
und Revisionssicherheit.

 

[rm -r *]

Ich denke nach wie vor, das man das mit einem vernünftigen Datenbankdesign besser lösen kann.

Man müßte sich halt anschauen, was an Daten erfasst wird und wie man das in verschiedene Tabellen aufsplittet, die man dann miteinander verknüpft.

Die Lösung mit den Feldern name, value, usw. die Du oben gepostet hast, finde ich unschön und es sollte auch anders gehen.

Ich Programmiere jetzt seit acht Jahren zeugs für's Internet und da waren auch echt komplexe Sachen mit fiesen Eingabemasken bei, aber mit einem vernünftigen Datenbankdesign hat das noch immer funktioniert, auch wenn da dann teilweise ganz schön der Kopf raucht.

 

[maceis]

Ich denke nach wie vor, das man das mit einem vernünftigen Datenbankdesign besser lösen kann.

Man müßte sich halt anschauen, was an Daten erfasst wird und wie man das in verschiedene Tabellen aufsplittet, die man dann miteinander verknüpft.
...

Genau das selbe wolte ich auch schreiben .

 

[Delmar]

Hm ... und wie könnte man das mit der Revisionssicherheit hinbekommen?

 

[maceis]

Was genau meinst Du mit "Revisionssicherheit"

Alle Informationen, die Du kodiert in den Wert eines Feldes packst, kannst Du doch auch in separaten Feldern unterbringen. Wenn Du irgendwann mal keine 1:1 Beziehungen hast, splittest Du auf in zwei (oder mehr) Tabellen und verknüpfst diese über ein Schlüsselfeld.

Insgesamt sollte man darauf achten, dass man keine Informationen doppelt vorliegen hat - erst recht keine, die sich verändern kann.
Also z.B. nie in zwei Feldern oder Tabellen die Versandadresse eines Kunden. Zieht der Kunde um, wirds kompliziert. Lieber eine Kundentabelle und die Zuordnung zur Tabelle Bestellungen dann über eine unveränderliche Kundennummer.

 

[Delmar]

Mit Revisionssicherheit meine ich, dass ich alle Änderungen, die in einem Feld gemacht
werden vorhalten muss inkl. wann und wer den Wert des Feldes geändert hat - also eine
Art Versionierung.

Das Prinzip der Normalisierung ist mir schon klar und verfolge ich normaler Weise auch
sehr strikt. Auf Grund der genannten Anforderungen rückt das Thema Normalisierung
aber in den Hintergrund. Die optimale Lösung wird es hier nicht geben, die Frage ist halt,
welchen Tod man sterben will bzw. muss.

 

[maceis]

Die Anforderung hatte ich noch nie.
Spontan fallen mir zwei Ansätze dazu ein.

1. Du hast für jede Tabelle eine mit den aktuellen Werten, eine ander mit "Aktionen". Darin wird jede Änderung gespeichert inkl. der zugehörigen Metadaten. Das hat den Vorteil dass in der aktuellen Tabelle nur die Nutzdaten stehen (die bleibt damit relativ kompakt und somit schneller) in der anderen (die ja mit der Zeit sehr groß werden kann) die Verwaltungsdaten. Verknüpfung über ein id-Feld.

2. Du könntest bei Änderungen nicht den Datensatz ändern sondern kopieren. In jedem Datensatz müsstest Du dann die erforderliche Informationen mitschleppen. "Aktuell" ist dann immer der, mit dem höchsten Änderungsdatum. Das würde auch gehen, erscheint mir aber auf den ersten Blick als weniger schön.

Dass MySQL das Erstellungs-/Änderungsdatum automatisch eintragen kann, weißt Du sicher.

 

[Delmar]

Ansatz 1 gefällt mir ganz gut. Werde ich mal näher betrachten. Das Problem
was ich jetzt habe ist, dass ich in der Entwicklung schon recht weit fortge-
schritten bin und die einzelnen Klassen und AppController schon fast final sind.

Ich werde mich mit Euren Ideen und Anregungen mal zurückziehen und diese
für das Projekt bewerten - werde Euch dann mitteilen, was es geworden ist.

Ich danke Euch jedenfalls sehr für die Diskussion. Es ist schön zu wissen, dass
die User hier immer noch so hilfsbereit sind wie früher.


In diesem Sinne ...