Diskussion: Umstellung einer Datenbank in einem Projekt

[hoika]

Hallo,

von Hand, schön zu Fuss.
Und nach jedem Umbau TESTEN !!!

Das Rüberschieben habe ich für Anfangstest per IBDataPump gemacht.

Zu Paradox / künstliche Schlüssel.
Einspruch Euer Ehren

Gerade meine Nutzung des AutoInc als künstlicher Schlüssel war ein Grund,
warum ich nicht gross an der Datenstruktur was machen musste.

Id Autoinc -> Id Integer


Aber MKinzler hat trotzdem "etwas" Recht

Manche Datenstruktur in meinem Programm wurde nur deshalb so anlegt,
weil es unter Paradox nicht anderes oder sehr schwer ging.


Heiko

PS:
auf IBPhoenix.com gibt es 2 interessante Artikel Pdx->Interbase
"My lock file has grown too large"
"Pdx->Interbase in 40 days"

[HeikoAdams]

Zu 4:
Es gibt IMHO zwei gute Gründe, auf TTable Kompos zu verzichten.
1) Die Dinger dienen eigentlich nur der Abwärtskompatibilität zur BDE
2) TTables machen im Prinzip ein SELECT * FROM <Tabelle> und fragen parallel noch sämtliche Informationen zu allen Spalten der Tabelle ab, was bei großen Tabellen mit vielen Datensätze eine echte Bremse sein kann.

[Hansa]

Moin,

der Fragesteller ist wohl eher an Erfahrungen interessiert. Wo es hakt usw. Hierzu mein Bericht. Im Prinzip mache ich das auch ungefähr so wie Hoika. Zuerst muss man ja mal an die alten DB-Daten rankommen. Egal ob BDE oder sonstwas. Jetzt hatte ich da auch mit Datapump und sonstigen Tools rumexperimentiert. Oder mit EXTERNAL FILE in Firebird. Sieht auf den ersten Blick schön aus, aber der Krempel macht IMHO im Endeffekt mehr Ärger, als er nützlich ist.

Ich bin dann kurzerhand hingegangen und habe die Daten zuerstmal quasi 1:1 in normale Textdatei exportiert. Zuerst als CSV. Und was zu erwarten war : egal welches Trennzeichen, irgendwo war es trotzdem in einem Feld. Dann Test mit festen Feldlängen. Das CSV-Problem war zwar weg, aber es tauchten Felder auf, die beschädigt waren. Wohl durch Stromausfälle etc. Jetzt hat man da aber ellenlange Textzeilen und kriegt vielleicht noch relativ leicht raus, welche Zeile das Problem verursacht, aber nicht wo in der Zeile genau. Auf Dauer auch nicht empfehlenswert.

Letztenendes mache ich das mittlerweile so : jedes alte Feld kommt in extra Zeile einer Textdatei. Auf der Delphi/FB-Seite lese ich die dann einfach per readln (..); und übergebe das Ganze mit FieldByName usw. Ist jetzt da ein unlogisches Feld drin, z.B. ' ' wo integer erwartet wird, dann bleibt Delphi zumindest mal in der entsprechenden Zeile des Import-Programms stehen. Ist das Feld klar, dann lasse ich das Export-Programm genau dieses kaputte Feld anzeigen. Man könnte auch die Textdatei direkt danach untersuchen. Aber das sind normalerweise dann wegen "pro Feld eine Zeile" zu viele Zeilen.

Ist die alte DB in keinster Weise normalisiert, dann wirds aber echt kritisch.

Zeitaufwand schätze ich mal auf max. 3 Tabellen pro Tag, also Programmierung der jeweiligen Export/Import-Programme. Die Zeit, die die Programme zum Ablauf brauchen nicht eingerechnet ! Mehr geht kaum. Es ist schon viel Handarbeit.

[RWarnecke]

Bis bisheriges Resüme aus den ganzen Antworten ist in Stichpunkten zusammengefasst :

• Alle Tabellen von Hand umstellen auf das neue DBMS
• Alle TTable umstellen auf Query (z.B. TQuery oder TUniQuery)
• Bei der Umstellung auf Query als ersten Weg erstmal ein SELECT * FROM <tabelle> machen, im Nachgang wenn es funktioniert nachkontrollieren ob es Optimierungsmöglichkeiten (Views Stored Procedures etc.) gibt.
• Zusätzlich zu der Umstellung drauf achten, dass man Daten vom Layout trennt (Datenmodul, Klasse oder Interface wie in Beitrag #20).

So würden jetzt meine 4 großen Hauptpunkte aussehen, für eine Umstellung von Datenbank A nach B.

Zitat von Hansa:

Letztenendes mache ich das mittlerweile so : jedes alte Feld kommt in extra Zeile einer Textdatei. Auf der Delphi/FB-Seite lese ich die dann einfach per readln (..); und übergebe das Ganze mit FieldByName usw. Ist jetzt da ein unlogisches Feld drin, z.B. ' ' wo integer erwartet wird, dann bleibt Delphi zumindest mal in der entsprechenden Zeile des Import-Programms stehen. Ist das Feld klar, dann lasse ich das Export-Programm genau dieses kaputte Feld anzeigen. Man könnte auch die Textdatei direkt danach untersuchen. Aber das sind normalerweise dann wegen "pro Feld eine Zeile" zu viele Zeilen.

Das hier hört sich nach einer sehr guten Idee an. Zumal man dann auch DBMS unabhängig ist, wenn man sich das Import/Export Programm gleich so aufbaut.

Zitat von Hansa:

Zeitaufwand schätze ich mal auf max. 3 Tabellen pro Tag, also Programmierung der jeweiligen Export/Import-Programme. Die Zeit, die die Programme zum Ablauf brauchen nicht eingerechnet ! Mehr geht kaum. Es ist schon viel Handarbeit.

Da ich das nicht jeden Tag mache, würde ich hier eher hergehen und 2 Tabellen pro Tag sagen.

[Hansa]

Zitat von RWarnecke:

Da ich das nicht jeden Tag mache, würde ich hier eher hergehen und 2 Tabellen pro Tag sagen.

Sagen wir mal so : sollte es gelingen auf die beschriebene Art und Weise die erste mittelgrosse Tabelle nach FB zu exportieren, da gehe ich mal eher von 3 Tagen aus. Für erste Tabelle, wohlgemerkt. Der Teufel liegt da im Detail und das hält zumindest anfangs gewaltig auf. Mal andersrum gesagt : habe hier eine alte DB mit 60 Tabellen. Bin am überlegen, die wie beschrieben umzustellen. Alternative wäre, zumindest Grunddaten von Hand einzufügen. Allerdings : das Endprogramm für die Daten an sich ist schon soweit fertig, egal wo die jetzt genau herkommen und die FB-DB steht auch. Es müssten allerdings 120 Programmchen gemacht werden. Schätze ca. 2-3 Wochen insgesamt. Aber nur, weil da viel abgekupfert werden kann. D.h. Grundgerüst ist ja immer gleich und es gilt lediglich die entsprechenden Datasets und Felder anzupassen.

Davon mal abgesehen : was soll das dauernd mit dem TTable, TQuery etc. ? Das ist doch alles längst überholt. Bei mir gibts lediglich aus Komp.Gründen eine Query. Normal wäre TDataset-Abkömmling.

[RWarnecke]

Zitat von Hansa:

Davon mal abgesehen : was soll das dauernd mit dem TTable, TQuery etc. ? Das ist doch alles längst überholt. Bei mir gibts lediglich aus Komp.Gründen eine Query. Normal wäre TDataset-Abkömmling.

Was ist jetzt da der Unterschied ? Da ich bei den ganzen Komponenten von AnyDAC, UniDAC, FIBPlus u.s.w. immer wieder eine Query-Komponente sehe.

[Hansa]

Zumindest bei FIBPlus ist sie wohl nur dazu da, dass die BDE-Leute nicht zuviel Angst kriegen.

[RWarnecke]

Zitat von Hansa:

Zumindest bei FIBPlus ist sie wohl nur dazu da, dass die BDE-Leute nicht zuviel Angst kriegen.

Nett, aber worin liegt jetzt genau der Unterschied zwischen einer Query und einer Dataset Komponente ?

[mkinzler]

Es kommt hierbei aber auch an, was man benötigt. Ein TxxDataSet hat viel mehr Features als ein TxxQuery aber auch einen größeren Overhead.
Wobei die TIBCQuery von IBDAC eine echtes DataSet in Hansas Sinne ist.
Ein TxxDataSet bietet sich an, wenn du mit <Kompo>.Append()/.Insert(), .Delete() usw. arbeiten willst.

[RWarnecke]

Das würde also heißen, wenn ich zum Beispiel folgenden Code habe :

Delphi-Quellcode:

with xxQuery do 
begin
  SQL.Clear;
  SQL.Text := 'SELECT * FROM tabelle';
  Open;
  Active := true;
  Edit1.Text := FieldByName('Feld1').AsString;
{...}
  Active := false;
  Close;
end;

Dann bin ich mit einer TxxQuery besser bedient oder wie darf ich das verstehen? Ich kann noch nicht so richtig den Unterschied sehen zwischen TxxQuery und TxxDataset.