6
CSharp - Update einer Datenbankstruktur
Guten Abend,
ich habe ein kleines Programm geschrieben, das ich mittels eigener Updateroutine auf dem neuesten Stand halte (Nicht publishing). Das funktionniert auch stabil. Das Programm verbindet sich mit einer SQL Express Datenbank. Was ist nun die Best Practice um die Datenbankstruktur aktuell zu halten; sprich wenn ich Änderungen an der Datenbank vornehmen muss? Mein Programm läuft in 3 Filialen mit jeweils eigenem SQL Express Server. Ich habe mich jetzt immer aufgeschaltet und die Datenbankänderungen händisch vorgenommen.
Muss ich jetzt beim starten jede Tabelle einzeln überprüfen? IF NOT TABLE Exists - THEN CREATE? Und dann noch für jedes Feld? Was wenn dann mal den Datentyp eines Feldes ändern würde? Ich glaube da wird der Code explodieren ;)
Ich könnte mir vorstellen daß Ihr Pros da ganz andere Tricks auf Lager habt ;) Kann mir da jemand einen Tipp geben?
Umgebung: C# unter VisualStudio mit SQLExpress
Schönen Abend gewünscht.
ich habe ein kleines Programm geschrieben, das ich mittels eigener Updateroutine auf dem neuesten Stand halte (Nicht publishing). Das funktionniert auch stabil. Das Programm verbindet sich mit einer SQL Express Datenbank. Was ist nun die Best Practice um die Datenbankstruktur aktuell zu halten; sprich wenn ich Änderungen an der Datenbank vornehmen muss? Mein Programm läuft in 3 Filialen mit jeweils eigenem SQL Express Server. Ich habe mich jetzt immer aufgeschaltet und die Datenbankänderungen händisch vorgenommen.
Muss ich jetzt beim starten jede Tabelle einzeln überprüfen? IF NOT TABLE Exists - THEN CREATE? Und dann noch für jedes Feld? Was wenn dann mal den Datentyp eines Feldes ändern würde? Ich glaube da wird der Code explodieren ;)
Ich könnte mir vorstellen daß Ihr Pros da ganz andere Tricks auf Lager habt ;) Kann mir da jemand einen Tipp geben?
Umgebung: C# unter VisualStudio mit SQLExpress
Schönen Abend gewünscht.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 375332
Url: https://administrator.de/contentid/375332
Ausgedruckt am: 03.12.2024 um 18:12 Uhr
6 Kommentare
Neuester Kommentar
üblicherweise schreibt man sich irgendwo den aktuellen Stand der DB-"Version" hin. Bei einem update der Software liefert man das Updatescript mit und führt das dabei dann aus. Die Historie der Updatescripts behält man, falls man mal irgendwo mehrere Updates nachholen muss. Nach dem Update aktualisiert man den Wert der Version und ist damit dann durch.
Aber bei 3 Filialen .... ist das ja den Aufwand nicht wert
Aber bei 3 Filialen .... ist das ja den Aufwand nicht wert
Hallo,
ja, eigentlich schon. Geht aber auch um den Lerneffekt.
Konkret heisst das, daß es schon auf das, "Jede Tabelle" - "Jedes Feld" einzeln überprüfen und gegebenenfalls verbessern / erstellen hinausläuft? Statt in einem separaten Update Skript kann das ja auch das Hauptprogramm überprüfen. Also beim Start -> Stimmt DB nicht, dann mach die einzelnen Änderungen.
Ich habe mir die Frage gestellt, ob es nicht irgendwie ein "Export-DB-Structure" im SQL Management Studio gibt, das man im Programm einfach laden konnte. (Rein spekulativ). So ne Datei konnte man ja dann mit dem Update ausrollen und importieren.
Danke dir für deine Antwort.
mfG
ja, eigentlich schon. Geht aber auch um den Lerneffekt.
Konkret heisst das, daß es schon auf das, "Jede Tabelle" - "Jedes Feld" einzeln überprüfen und gegebenenfalls verbessern / erstellen hinausläuft? Statt in einem separaten Update Skript kann das ja auch das Hauptprogramm überprüfen. Also beim Start -> Stimmt DB nicht, dann mach die einzelnen Änderungen.
Ich habe mir die Frage gestellt, ob es nicht irgendwie ein "Export-DB-Structure" im SQL Management Studio gibt, das man im Programm einfach laden konnte. (Rein spekulativ). So ne Datei konnte man ja dann mit dem Update ausrollen und importieren.
Danke dir für deine Antwort.
mfG
naja technisch geht das schon, aber bleibt dann bei einem reinen Vergleich zwischen zwei Ständen. Das Ding ist halt, das Datenbankänderungen oft mehr nach sich zieht, als nur "neues Feld anlegen". Datentyp ändern benötigt oft ein"wegschieben" der Daten um sie dann neu an zu legen. Oder Daten davor/danach aufbereiten. Deshalb macht man idR ein dediziertes Updatescript für sowas. Da steht dann nicht nur drin das sich das Feld A von string auf int geändert hat, sondern auch, das sich die Daten vor der Änderung um buchstaben erleichtert wird. Bzw das diese Buchstaben in ein neues Feld kommen.
Hmm, stimmt. Daran habe ich nicht gedacht. Soweit mal klar. Ich dank dir für deine Antworten.
Ich lass mal auf bis morgen dann mach ich hier den Deckel drauf. Vielleicht kommt noch was.
Bis dann.
Ich lass mal auf bis morgen dann mach ich hier den Deckel drauf. Vielleicht kommt noch was.
Bis dann.
Hallo Cubic,
in anderen Sprachen nutzt man dafür Datenbank-Frameworks, die einem die Verwaltung auf ein Minimum reduzieren.
In PHP nutze ich zum Beispiel gerne Doctrine-ORM.
Das funktioniert wahlweise mit Annotations im Code oder mit XML-Dateien.
Das kann einem dann auch gleich die Basis-Klassen für neue Tabellen und Relationen generieren usw.
Ich glaube da gibts für C# so Sachen wie NHibernate, Dapper oder Entity Framework.
Die können auch meist schon Ugrade-/Downgrade-Skripts anfertigen.
In die Richtung könntest du mal schauen.
in anderen Sprachen nutzt man dafür Datenbank-Frameworks, die einem die Verwaltung auf ein Minimum reduzieren.
In PHP nutze ich zum Beispiel gerne Doctrine-ORM.
Das funktioniert wahlweise mit Annotations im Code oder mit XML-Dateien.
Das kann einem dann auch gleich die Basis-Klassen für neue Tabellen und Relationen generieren usw.
Ich glaube da gibts für C# so Sachen wie NHibernate, Dapper oder Entity Framework.
Die können auch meist schon Ugrade-/Downgrade-Skripts anfertigen.
In die Richtung könntest du mal schauen.
Hallo,
sorry für die späte Antwort. Ich schaue mir die Tools mal genauer an.
Danke.
sorry für die späte Antwort. Ich schaue mir die Tools mal genauer an.
Danke.
