Firebird Musterdatenbank

[Morphie]

Hi,

wisst ihr, wo es eine Musterdatenbank für Firebird gibt, die so ziemlich alle Funktionen von Firebird demonstriert?

Hintergrund ist der, dass ich mir ein Diff-Tool schreibe, welches aus zwei Datenbanken ein SQL-Script aus den Meta-Daten generiert, mit der man eine der beiden Datenbanken abgleichen kann.
Das möchte ich natürlich so umfangreich wie möglich umsetzen, daher die Frage nach einer vollständigen Funktionsdemo.

Die emplyees.fdb ist da bei weitem nicht ausreichend.

[scrat1979]

Eine fertige Testdatenbank kenne ich nicht, jedoch ist vielleicht folgendes Tool für Dich interessant (komerziell)...

[mjustin]

Zitat:

Zitat von Morphie (Beitrag 1148812)

Hintergrund ist der, dass ich mir ein Diff-Tool schreibe, welches aus zwei Datenbanken ein SQL-Script aus den Meta-Daten generiert, mit der man eine der beiden Datenbanken abgleichen kann.

Genau das richtige für lange Winterabende zuhause :) - Es gibt auch schon fertige Lösungen für Firebid / InterBase die das sehr gut können, z.B. IBExpert

[Morphie]

Zitat:

Zitat von mjustin (Beitrag 1148839)

Es gibt auch schon fertige Lösungen für Firebid / InterBase die das sehr gut können, z.B. IBExpert

ich weiß, allerdings kann ich das 1. nicht schön komfortabel in mein Programm generieren (es soll bei Programmupdates die Datenbanken unserer Kunden aktualisieren)
2. kann ich das nicht entsprechend erweitern / auf events reagieren usw.

[mkinzler]

http://fbexport.sourceforge.net/fbcopy.html

[tsteinmaurer]

@Morphie: Ich traue solchen Diff-Ansätzen nicht, um Kunden-DBs zu aktualisieren. Da spielen einfach viel zu viele Faktoren mit. Ich würde mich daran gewöhnen, inkrementelle SQL-Skripts zu erstellen und über einen "Versions-Check" die nachspielen, wenn neue Skripts hinzugekommen sind. In diesen Skripts sind dann nicht nur DDLs möglich, sondern auch DML, wenn Daten-Updates notwendig sind, um von Version X auf Y upzudaten.

[Morphie]

Also wir fahren mit der Diff-Methode bei unserem jetzigen Projekt (mehr als 10 Jahre im Einsatz) bei mehreren hundert Kunden eigentlich ziemlich gut.

Da benutzen wir zwar nicht Firebird, aber vom Prinzip ists ja das selbe...

Im Gegenteil: ich vertraue einer inkrementellen Methode nicht so wirklich, bzw. vertraue nicht darauf, dass bei den Kunden nicht durch irgendwelche Fremdeinflüsse / fehlerhafte Updates (ja, die soll es geben, habe ich mal gehört) irgendwelche Änderungen in der DB auftauchen, die so nicht vorgesehen waren. Daher prüfe ich lieber gleich alles und passe die DB entsprechend an.

Natürlich muss man darauf aufpassen, dass die Daten konsistent bleiben und die Regeln für neue Felder / Indices / Constraints usw. zu den Daten passen.

Ich bin nun soweit mit meinem Diff-Tool fertig und teste nun fleißig. (daher auch die Ursprungsfrage nach einer großen MusterDB)
Bislang konnte ich keine Fehler produzieren, aber das mag vielleicht noch kommen ;-)

[neo4a]

Zitat:

Zitat von Morphie (Beitrag 1148917)

Also wir fahren mit der Diff-Methode bei unserem jetzigen Projekt (mehr als 10 Jahre im Einsatz) bei mehreren hundert Kunden eigentlich ziemlich gut.

Das ist wirklich keine belastbare Kategorie ;)

Zitat:

Zitat von Morphie (Beitrag 1148917)

Im Gegenteil: ich vertraue einer inkrementellen Methode nicht so wirklich, bzw. vertraue nicht darauf, dass bei den Kunden nicht durch irgendwelche Fremdeinflüsse / fehlerhafte Updates (ja, die soll es geben, habe ich mal gehört) irgendwelche Änderungen in der DB auftauchen, die so nicht vorgesehen waren. Daher prüfe ich lieber gleich alles und passe die DB entsprechend an.

Genau diese Prüfung ist das Problem: Arbeitest Du z.B. mit ForeignKey, so ist die Reihenfolge der Strukturänderung essentiell. Hier wird Dir kein generisches Diff-Tool helfen und Du bist ganz schnell bei Thomas' Ansatz.

Ist Deine DB nur ein "Daten-Eimer" ohne Eigenlogik wie referentieller Integrität, Trigger etc., dann kann Dein Diff-Tool bestimmt gut funktionieren.

[alex517]

Zitat:

Zitat von neo4a (Beitrag 1148937)

Genau diese Prüfung ist das Problem: Arbeitest Du z.B. mit ForeignKey, so ist die Reihenfolge der Strukturänderung essentiell. Hier wird Dir kein generisches Diff-Tool helfen und Du bist ganz schnell bei Thomas' Ansatz.

Ist Deine DB nur ein "Daten-Eimer" ohne Eigenlogik wie referentieller Integrität, Trigger etc., dann kann Dein Diff-Tool bestimmt gut funktionieren.

Mit entsprechende Tools wie IBEScript von IBExpert oder den Database Comparer von clevercomponents geht das ohne Probleme.

Wir setzen seit Jahren IBEScript ein um Datenbank-Struktur-Updates durchzuführen.
Funktioniert MIT viel "Eigenlogik wie referentieller Integrität, Trigger", Stored Procs, Views usw. hervorragend.

[neo4a]

Zitat:

Zitat von alex517 (Beitrag 1148949)

IBEScript

Ich habe vor ca. 5 oder 6 Jahren das Tool getestet, es hatte seinerzeit u.a. Probleme mit der Änderung von Feldgrößen. Möglich, dass das zwischenzeitlich behoben ist. Ich hatte ohnehin für Tools wie IBExpert keine Verwendung. Aber das ist doch gar nicht der Punkt.

Setze ich Fremd-Tools ein, verlasse ich mich auf deren Funktionalität. Beim von Thomas und mir präferierten Weg braucht man dagegen keinen One-Fits-All-Ansatz, sondern kann ganz präzise und effektiv die speziellen eigenen Anforderungen umsetzen. Ich habe das Update-Scripting z.B. in einer voll automatisierten Multi-Point-Replikation eingesetzt, wo Daten- und Strukturänderungen gleichzeitig und unbeaufsichtigt ablaufen mussten.

Insofern erfordert jeder eigene Aspekt auch eigene Lösungen.