Schema für Trennung Benutzer- und Systemtabellen in einer DB

[openshinok]

hallo,
ich erstelle gerade eine neue Datenbank. In vorherigen Anwendungen hatte ich öfters das Problem wenn ich eine Anwendung neu installiere dass ich manche Tabellen mit Daten "vorfüllen" musste dass die Applikation funktioniert. Beispiel bei Aufträgen die Tabelle mit den Stati der Aufträge, nicht definiert, offen, in Arbeit, abgeschlossen.

Wie kennzeichnet ihr solche Tabellen? Macht ihr ein Kürzel/Prefix in die Tabellen? Oder sucht ihr auch immer chaotisch nach den Tabellen bei denen etwas zu übernehmen ist?

[hwoess]

Ich arbeite da meistens mit einer stored proc, in der die ganzen Initialisierungsarbeiten drinnen stehen. Die braucht man dann am Anfang nur einmal aufrufen und gut ist's. Habe das zudem so abgesichert, dass die proc nur dann arbeitet, wenn bestimmte Tabellen noch leer sind, damit auch bei einem versehentlichen späteren weiteren Start nichts passieren kann.

bye,
Helmut

[openshinok]

hallo,
stehen da nur die INSERT's drinnen oder auchd ie CREATE's?

[hwoess]

Hängt von dir ab, im Prinzip kann man alles in einer einzigen riesigen Procedure machen, ich allerdings habe es lieber etwas aufgeteilt, also Creates und Daten-Inits getrennt. Erst mache ich die Creates und wenn das okay war kommt das Init.

bye,
Helmut

[openshinok]

jo, guter Plan, werde nur die INSERTs rein packen.

[O. Helper]

Um auch spätere Updates zu berücksichtigen könntest Du folgende Logik in Deiner Applikation einbauen:

- Anlagescript mit den Objecten; wird bei der Neuanlage einer DB ausgeführt.
- Die DB einhält eine Tabelle mit SetUp-Informationen; darunter eine Versionsnummer der DB
- In einem separaten Ordner der App legst Du Dateien mit Update Scripts / Insert Stammdaten ab, der Dateiname enthält die Versionsnummer z.B. UPD_22.sql für Version 22
- Bei App-Start wird die Versionsnummer aus der DB ausgelesen, nachgesehen ob es neuere Update-Script Dateien gibt und führt die dann aus.
- Natürlich enthält jedes Script ein Update für die DB Version in der Datenbank.

So könntest Du auch Datenbereinigungen bei Problemen etc. abarbeiten lassen.

Fehlt nur noch ein LiveUpdate für die Applikation

[openshinok]

hm auch eine Super Idee, kann ich auch gut für Module gebrauchen wenn ich keinen direkten Zugriff mehr auf die Datenbank haben sollte. Derzeit habe ich immer direkten Zugriff auf die Datenbank und fahre mit MSSQL Examiner einen Vergleich der Entwicklungsdatenbank mit der Livedatenbank beim Kunden. Der gleicht mir dann auf Knopfdruck die Datenbanken an.