Ok, hier liegt dann aber eine sehr starke Bindung der Tabellenstruktur an die Benutzeroberfläche vor.
Wenn das Programm nur bei einem Kunden läuft ist das kein Problem.
Bei vielen Kunden gibt es Drausen aber verschiedene Versionen der Software, wobei die Datenbankstruktur immer zur Anwendung passen muss.
Manchmal macht ein Programmupdate nicht das was es soll und der Kunde muss wieder die Vorgängerversion benützen.
Das Problem ist nur, dass die Struktur der
DB geändert wurde und es keinen Weg zurück gibt.
Lange Rede, kurzer Sinn - die Datenbankstruktur sollte so gebaut werden, dass sie sich nicht ändern muss, nur weil die Anwendung neue Optionen zur Konfiguration bekommen hat.
Dazu kann man z.B. eine Key/Value Tabelle verwenden.
Code:
Key | Value
==============================================================
UI.Reporting.DefaultPrinter | Epson 4200
UI.Reporting.AllowCangePrinter | True
UI.Reporting.DefaultCopies | 1
Logger.File | C:\Users\xxx\Logs\info.log
Logger.LogLevel | 2
Die Keys werden durch die Punkt-Notation strukturiert, damit man leicht erkennen kann was zusammengehört.
Da mehrere Rechner mit einer Datenbank verbunden sein können, sollte man die Tabelle noch um den Rechner- oder Terminalname aufbohren:
Code:
Instance varchar(50)
Key varchar(50)
Value varchar(250)
Zitat
Baum-Darstellung
