Diskussion: Umstellung einer Datenbank in einem Projekt

[mkinzler]

Ja, Ein DataSet kann mehr ist daher aber u.U. auch langsamer, da viel Dinge im Hintergrund ablaufen. Dies bieter sich z.B. bei der Nutzung von dataaware Komponenten. Da du von diesen weg willst könnte ein Query reichen. Auch wenn Hansa das natürlich anders sieht.

[RWarnecke]

Mein derzeitiger Favorite ist UniDAC. Die sind einfach, schnell zu erlernen und übersichtlich zu konfigurieren. Zudem unterstützen UniDAC ja noch mehrere DBMS, womit ich auch wieder vorgesorgt habe, falls noch eine anderes DBMS kommt oder wieder ein Wechsel durchgeführt werden muss, aus welchem Grund auch immer. Deshalb werde ich es so machen, wie ich es in Beitrag #24 geschrieben habe. Um bestehende Daten zu migrieren werde ich den Weg einschlagen, wie es Hansa geschrieben hat.

Das ganze bedeutet zum Anfang sehr sehr viel Aufwand. Aber den Weg werde ich gehen und hoffe mal, dass mein Kunde mitspielt.

[Der.Kaktus]

Zitat:

Zitat von RWarnecke

Mein derzeitiger Favorite ist UniDAC. Die sind einfach, schnell zu erlernen und übersichtlich zu konfigurieren. Zudem unterstützen UniDAC ja noch mehrere DBMS, womit ich auch wieder vorgesorgt habe, falls noch eine anderes DBMS kommt oder wieder ein Wechsel durchgeführt werden muss, aus welchem Grund auch immer. Deshalb werde ich es so machen, wie ich es in Beitrag #24 geschrieben habe. Um bestehende Daten zu migrieren werde ich den Weg einschlagen, wie es Hansa geschrieben hat.

Das ganze bedeutet zum Anfang sehr sehr viel Aufwand. Aber den Weg werde ich gehen und hoffe mal, dass mein Kunde mitspielt.

sicher eine Sache des "Preises" was der "Kunde" bezahlen will(kann) ;-)..naja.......

[mkinzler]

Wobei sich dann die Frage TxxQuery oder TxxDataSet dann erledigt hätte.
Aber warum über den Export nach CSV gehen, wenn mann das auch direkt aus Delphi kann?
Zudem würde ich, wei schon erwähnt, untersuchen, ob die Datenbankstruktur optimal ist. ( also eine 1:1 Umsetzung empfehlenswert ist)

[RWarnecke]

Zitat:

Zitat von mkinzler

Aber warum über den Export nach CSV gehen, wenn mann das auch direkt aus Delphi kann?
Zudem würde ich, wei schon erwähnt, untersuchen, ob die Datenbankstruktur optimal ist. ( also eine 1:1 Umsetzung empfehlenswert ist)

Du beantwortest die Frage schon fast selbst. Wenn ich die Datenbankstruktur eventuell ändern muss, dann muss ich doch den Weg über einen Export gehen oder nicht ?

[mkinzler]

Nicht unbedingt, man kann dies auch in Abfragen oder im Programm erledigen

[RWarnecke]

Dafür habe ich noch zu wenig Erfahrung mit solchen Umstellungen. Deshalb werde ich erstmal den sicheren Weg über die Textdatei wählen.

[hoika]

Hallo,

die BDE läuft auch noch unter Vista / Windows 7 ...

TQuery, TDataSet

Unter FIBPlus gibt es bei der nornalen TQuery kein Open,
d.h. die ist wirklich nur dazu dazu, Insert/Update/Delete zu machen.

Deshalb ja auch meine TMyQuery als Ableitung von TDataSet,
weil ich alles mit einer Komponente machen will.


Heiko

[RWarnecke]

Das weiss ich auch. Aber die Datenbank wird nicht weiterentwickelt und das Setup für das Programm ist so wie ein vierfacher Salto wie vom 1 Meter Brett. Fast unmöglich, wegen der UAC unter Vista und 7.

[Hansa]

Zitat:

Zitat von RWarnecke

Du beantwortest die Frage schon fast selbst. Wenn ich die Datenbankstruktur eventuell ändern muss, dann muss ich doch den Weg über einen Export gehen oder nicht ?

Ist zumindest bei weitem der flexiblere. Die Datenstruktur wird sich wohl definitiv ändern (müssen). Im Endeffekt geht es schneller von der Hand, die Daten zuerst zu exportieren, als sich mit Tools oder unbekannten Fähigkeiten vom Programm XY rumzuschlagen, das angeblich mehr oder weniger von alleine läuft, dies aber in Wirklichkeit nicht tut und zu guter Letzt der Import scheitert.

Ist der alte Datenbestand erstmal in der Textdatei, dann ist ja immer noch eine andere Sache was danach damit passiert. Die Textdatei soll ja nur die reinen Daten enthalten. Das ist somit völlig entkoppelt von der neuen DB-Struktur. Wenn ich nun Lust habe ein Feld in Land und PLZ zu zerlegen, das vorher so aussah "USA-20000" und "LAND-PLZ" hiess, dann steht es erstmal so in der Textdatei und basta. Das Import-Programm müsste dann eben das Teil zerlegen. Alternativ könnte man das auch direkt beim Exportieren erledigen, aber egal.

Die neue DB müsste dann eben ein Feld "Laenderkennzeichen" haben und eines "PLZ". Das alte Ding in die neue DB reinzukriegen wäre dann einfach :

Delphi-Quellcode:

DataSetX.FieldByName ('Laenderkennzeichen').AsString := copy (AltFeld,1,3);
DataSetX.FieldByName ('PLZ').AsInteger := IntToStr (copy (AltFeld,5,5));

Das "-" wird eben ignoriert. Jetzt ist nicht nur das alte Feld in 2 neue zerlegt, sondern gleich mit, noch das alte zusammengesetzte Feld in 2 verschiedene Typen aufgeteilt, sinnvoll umbenant etc. In dem schnell konstruierten Beispiel hat man sogar noch Speicherplatz gespart etc. In deser Richtung gibts fast unbegrenzte Möglichkeiten.

[RWarnecke]

Den Vorteil, so wie Hansa es beschrieben hat, sehe ich auch in einem Export der bestehenden Daten. Zum einen habe ich erstmal eine Sicherung der Daten und zum zweiten kann ich dann die Exportierten Daten so anpassen, wie ich es möchte.

Ich habe gerade noch den Paradox Viewer gefunden. Auf den ersten Blick sieht das Teil garnicht schlecht aus. Werde es heute laufe des Tages es ausgibieg testen und dann hier berichten. Dieser Viewer soll nur zur Unterstützung dienen.

[nahpets]

Hallo,

eventuell schaust Du Dir mal die Komponente TBatchMove an, sie benötigt noch die BDE, was ja bei Deinem Altsystem auch der Fall ist. Mit dieser Komponenten kann man recht einfach Tabellen zwischen Datenbanken kopieren. Zum Kopieren müssen sie halt beide über die BDE erreichbar sein. Das gilt aber nur für die Kopierroutinen, die ja nur einmalig benötigt werden und ist für den späteren Zugriff auf die Zieldatenbank nicht relevant.

Die Komponente bietet auch die Möglichkeit, beim Kopieren unterschiedliche Spaltennamen zu matchen. Problemfälle kann sie in Paradoxtabellen protokollieren. Der Programmieraufwand hält sich in Grenzen, da ein Programm für viele Tabellen genutzt werden kann. Je Quell- und Zieltabelle benötigt man halt den Namen der Quell- und Zieltabelle, die Namen der "Fehler"-Tabellen und eine Stringliste mit dem Matching der Spalten (sofern hier keine 1:1-Übernahme erfolgt).
Bei einer 1:1-Übernahme kann man hiermit in eine Schleife alle Tabellen einer Datenbank kopieren, man muss nur die Tabellennamen jeweils austauschen und den Kopiervorgang starten.

Mit dieser Komponente habe ich schon Daten zwischen diversen (kleineren) Datenbanken ausgetauscht, in der Regel war die Quelle dbase oder Paradox und das Ziel Oracle oder SQL-Server.

Die Komponente bietet verschiedene Modi für die Datenübernahme, von hinzufügen, über hinzufügen und aktualisieren, reinem kopieren, reinem aktualisieren bis zum Löschen.
Hierüber dürfte auch eine Normalisierung der Tabellen möglich sein, wenn man Quelle und Ziel geschickt auswählt und so eine Quelltabelle in mehreren Schritten in die entsprechenden Zieltabellen übernimmt. Muss man im Zielsystem aber erst noch neue Schlüssel generieren, dann dürfte die Leistungsgrenze der Komponente erreicht oder überschritten sein.

http://edn.embarcadero.com/article/25620

[Sharky]

Zitat:

Zitat von 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.

Es kommt immer darauf an was gewünscht wird.

Nehmen wir einmal an Du hast eine Tabelle mit einem Integer-Feld als ID(PK) und 30 Felder a 10Char. Davon hast Du nun 10.000 Datensätze.

In deinem Programm hast Du nun ein Grid oder so um die ersten vier Char Felder anzuzeigen (als Auswahlliste).

Bei einem

SQL-Code:

SELECT * FROM tabelle

(oder verwendung von TTable) werden jetzt also

(4 Byte + 30*10Byte) * 10.000 = 3.040.000 Byte geladen.

Benötigt wird für die Anzeige aber nur

SQL-Code:

SELECT ID,Feld1,Feld2,Feld3,Feld4 FROM tabelle

Also

(4 Byte + 4*10Byte) * 10.000 = 440.000 Byte :!:

Wenn Du nun die Details eines Datensatzen benötigst lädst Du diese genau dann wenn Du sie benötigst.

SQL-Code:

SELECT * FROM tabelle WHERE ID = akuelleIDausAuswahlListe

Das ist einer der Vorteile eines Query

[Muchacho]

Hi Sharky, :-D

Ist Open und Active nicht das Gleiche?


Außerdem Open sollte immer „geschützt“ werden z.B.:

Delphi-Quellcode:

 try
  Open;
 except
   on E:Exception do
   begin 
    //
   end
 end;

Muchacho

[Sharky]

Hai Muchacho,

wenn Du genau hinsiehst kannst Du erkennen das der Code mit Open und Active nicht von mir ist ;-)

Zitat:

Zitat von Muchacho

... Außerdem Open sollte immer „geschützt“ werden z.B.:

Habe ich, ehrlich gesagt, noch nie gemacht.

[Muchacho]

Zitat:

Zitat von Sharky

Habe ich, ehrlich gesagt, noch nie gemacht.

Sharky,

solltest Du aber :mrgreen:

Muchacho

[Muchacho]

Sharky

Du hast ein Formular mit sagen wir 10 Querys

Jetzt kriegst Du einen Anruf von einem Kunden:

„Hi, Sharky, ich kriege immer bei Öffnen des Formulars ein SQL Fehler, was ist los?“

Was meinst Du Sharky, wie könnte Dir [try/except/end] Block weiterhelfen? :gruebel:

Muchacho

[Mithrandir]

Zitat:

Zitat von Muchacho

Was meinst Du Sharky, wie könnte Dir [try/except/end] Block weiterhelfen? :gruebel:

Gar nicht, denn dann fällt die eigentlich immer recht aussagekräftige SQL-Fehlermeldung weg.
Btw, Muchacho, der http://www.delphipraxis.net/template.../icon_edit.gif - Button möchte gerne benutzt werden. ;)

[RWarnecke]

Der Sourcecode war von mir einfach nur niedergeschrieben, da es um ein kurzes einfache Beispiel ging mit TxxQuery und TxxDataset. Das ist jetzt aber auch nicht das Thema.

Auf jedenfall zeigt das Beispiel von Sharky deutlich, was man an Traffic einsparen kann, wenn man die TTable-Komponenten durch TxxQuery-Komponenten ersetzt.

[Muchacho]

Zitat:

Zitat von Daniel G

Zitat:

Zitat von Muchacho

Was meinst Du Sharky, wie könnte Dir [try/except/end] Block weiterhelfen? :gruebel:

Gar nicht, denn dann fällt die eigentlich immer recht aussagekräftige SQL-Fehlermeldung weg.
Btw, Muchacho, der http://www.delphipraxis.net/template.../icon_edit.gif - Button möchte gerne benutzt werden. ;)

Sorry wg. Edit. :oops:

Was [try/except/end] Block an dieser Stelle betrifft irrst Du Dich gewaltig, sorry. :shock:

Manche aussagekräftige Meldungen von SQL-Server sind natürlich nur für Gott verständlich. :mrgreen:

Darüber hinaus wäre es nicht schlecht,wenn das Formular (trotzt Fehler) weiter läuft
und nicht z.B. OnShow zusammenbricht, meinst Du nicht?

Tja

Muchacho

[Sharky]

Bitte dieses Thema in einem anderen Thread bereden.

Danke :stupid:

[Muchacho]

Zitat:

Zitat von Sharky

Bitte dieses Thema in einem anderen Thread bereden.

Danke :stupid:

Sharky,

ich habe gedacht, dass man hier dem RWarnecke helfen sollte auf vernünftige Art und Weise Datenbank umzustellen.

Da sollte man schon reagieren wenn hier Anfänger Fehler präsentiert werden (und zwar auch durch Dich), oder?

Du kannst natürlich das abwürgen, kein Problem :mrgreen:

Muchacho

[mkinzler]

Ob die Fehlermeldungen vom SQL-Server nun für Gott oder auch für seine Schäfchen verständlich sind, hat aber mit der Frage des TE nichts zu tun.

[Muchacho]

Zitat:

Zitat von mkinzler

Ob die Fehlermeldungen vom SQL-Server nun für Gott oder auch für seine Schäfchen verständlich sind, hat aber mit der Frage des TE nichts zu tun.

Nun mal sehen, ob das nichts mit diesem Thema zu tun hat. :evil:

Gerade bei Umstellung einer Datenbank ist es sehr wichtig, dass man SQL Fehler schnell erkennt und beseitigt.

Aber auch im „normalen Betrieb“ ist es „gang und gäbe“ SQL Befehle jeglicher Art durch try/excpet /end Blöcke zu überwachen.

In einem except Abschnitt kann man verschiedene Kontextbezogene Fehlermeldungen ausgeben.

Sehr hilfreich ist es auch an dieser Stelle z.B. Query.SQL.Text bzw. Query.Name auszulesen.

Mit einem on E:Exception do weiß man dann zum einem was SQL-Server zu sagen hat
und zum anderem, wie sieht gerade ausgeführte SQL Anweisung aus, usw…

Vorteile solcher Vorgehensweise sind, wie ich meine, unbestritten


Muchacho

[mkinzler]

Haben aber mit der grundlegeneden Fragestellung nichts zu tun.
Es steht natürlich ausser Frage, dass das "Abfangn" von Exceptions wichtig ist. Ich bin mir aber sicher, dass der TE weiss wie so etwas geht.

[Muchacho]

Natrürlich :-D bin schon weg!

Muchacho

[RWarnecke]

Wenn ich die Datenbank umstelle und aus der lokalen BDE eine Client/Server Datenbank werden soll, gibt es da irgendwelche Richtwerte für die Systemvoraussetzung eines Datenbankservers ? Mit Richtwerte meine ich bei z.B. 100 Benutzern so und so viel xx RAM Arbeitsspeicher u.s.w. Ich habe bis jetzt immer nur kleinere Sachen gemacht, wo eine einfache Workstation ausgereicht hat. Meistens waren es nur 2 - 5 User.

[mkinzler]

Das hängt sicherlich auch von dem verwendeten DBMS und Betriebssystem ab.

[RWarnecke]

Ok, da ich beides anbieten möchte, sowohl Linux als auch Windows. Gibt es dazu ein paar Anleitungen und Links, wo man solche Berechnung für die einzelnen DBMS nachlesen kann. Hauptsächlich interessiert mich Firebird. Oder weiss jemand einen Link, wo das ganze mal für alle gängigen großen DBMS (Oracle, MS-SQL, MySQL, Firebird u.s.w.) zusammengefasst wurde.

[Hansa]

Zitat:

Zitat von RWarnecke

Ok, da ich beides anbieten möchte, sowohl Linux als auch Windows..

Und das ist Dein Ernst ? :mrgreen: Hier stehen jetzt 70 Beiträge. Ist bereits eine einzige Tabelle nach Firebird konvertiert ? Scheint ja wirklich kein Problem zu sein, wenn sogar Linux unterstützt werden soll. Womöglich gar für MS-SQL. 8-)

Nene, also ehrlich. So wird das absolut nichts werden. Oder hat ein Kunde Linux gefordert ? Wenn ja, warum ? Weiss er, wieviel das im Endeffekt kostet ? Stichwort : TCO.

[mkinzler]

Hansa hat zuviele MS Werbeprospekte gelesen. :mrgreen:
FireBird läuft prblemlos auf Linux, Oracle und MySQL auch.

[RWarnecke]

Zitat:

Zitat von mkinzler

Hansa hat zuviele MS Werbeprospekte gelesen. :mrgreen:
FireBird läuft prblemlos auf Linux, Oracle und MySQL auch.

Das glaube ich auch. Das Programm soll nur auf Windows laufen. Für den Firebird-Server möchte ich meinem Kunden anbieten, Ihn auf Windows oder Linux laufen zu lassen.

[Hansa]

Zitat:

Zitat von mkinzler

Hansa hat zuviele MS Werbeprospekte gelesen.

Sieht so aus. :mrgreen: Also gut : "ich will jetzt das Programm für Linux. Soll angeblich billiger als Windows sein. Aber in der Fa. läuft MS-SQL, das muss dann schon recht gut sein. Also das dann bitte sehr auch noch dazu." Klasse, was ? :wall: :mrgreen:

Ich klinke mich damit solange aus, bis eine mittelgrosse Tabelle für eine einzige DB und Windows konvertiert ist. :duck:

[RWarnecke]

Für die Umstellung habe ich mich jetzt Entschieden, die UniDAC-Komponenten neu einzuführen und als DBMS benutze ich Firebird. Ich stelle mir allerdings noch die Frage welche Edition wäre jetzt sinnvoll zu kaufen ?

[mkinzler]

http://www.devart.com/ibdac/editions.html
Wenn du die Extras der Pro benötigst.

[hoika]

Hallo,

Zitat:

Gibt es dazu ein paar Anleitungen und Links

So eine Anleitung kann es nicht geben,
weil jede Anwendung verschieden ist
und damit auch die Art der DB-Abfragen.

Ich habe FB (1.5 SS Windows) hier bei ~50 gleichzeitigen Usern
auf der DB laufen.
Unter IBPhoenix.com gibt es aber auch Meldungen zu > 250 gleichzeitigen Usern.

Zum RAM:
Bei FB spielt die User-Zahl nur bei der CS-Variante eine Rolle.
Dort bekommt jede Connection (~ jeder User) eigenen RAM.


CS - Classic Server
SS - Super Server


Heiko

[RWarnecke]

Daraus schliesse ich, dass die Konfiguration des Server hardwareseitig garnicht ausschlaggebend ist, wieviele User darauf zugreifen können. Ist das richtig so ?

[hoika]

Hallo,

jein ...

Muss man leider so sagen.

Bsp 1:
Pentium 800 Ghz, 1 GB RAM
20 User


Bsp 2:
DualCore 3200 Ghz, $GB RAM
20 User


Klar sollte hier sein, dass der DualCore die Anfragen
"schneller" bearbeitet als der 800er.

Es kommt aber ganz darauf an, wie viele Abfragen an den Server gestellt werden
und wie komplex sie sind.
Und gaaanz wichtig, wie viel als Ergebnis übers Netz läuft.


Bei 4GB Ram kann auch der DB-Cache schön hochgesetzt werden.
Das hilft dann bei Selects (er muss nicht so oft auf die "lahme" Platte zugreifen)

Ich habe einen Kunden, der hatte nen 233er Pentium (Win-NT) mit 128 MB Ram als Server.
Es waren aber auch nur 2-4 User dran, die kaum was gemacht haben.


Der Superserver benutzt pro User etwa 200-300 kB RAM für die Kommunikation
(Quelle kann ich raussuchen, das ändert sich aber eh pro Version).
Er läuft als ein Prozess, jede Verbindung ist ein Thread.
Wegen "ein Prozess" nutzt ein Multi-Prozessor nur bedingt.

Der Classic (jede Verbindung ist ein Prozess) benutzt pro Verbindung
eine einzustellende Größe (habe die Berechnung gerade nicth im Kopf.
Hier muss man einfach nachrechnen, sonst swappt der Server.
Vorteil: Multi-Prozessoren werden benutzt.


Kurz und gut:
Prüfe, was deine Anwendung mit dem Server anfangen will.


Heiko

[mkinzler]

Hier gibt es ab FB2.5 einige Änderungen ( seit letzter Woche liegt der RC1 vor).
Neu ist die Version SuperClassic, welche die Möglichkeit bietet pro Kern einen Prozess zu starten( der dann, wie bei der Superserver, mehrere Threads verwendet)

[RWarnecke]

Danke Heiko für die ausführliche Beschreibung. Das hilft mir schon mal weiter.