Diskussion: Umstellung einer Datenbank in einem Projekt

[Muchacho]

Zitat:

Zitat von joachimd

[Ich muss leider allzuoft erleben, dass solcherlei Aussagen gebetsmühlenartig heruntergeleiert werden, ohne dass sich die Leute Gedanken darüber machen - nur weil es solche Schwergewichte wie IBM, Oracle, MS - und auch Sybase (mit der ASE) vorbeten.

Jawohl!

und weiter:

RWarnecke hat hier ganz einfache Frage gestellt und gleich bricht hier eine Diskussion über Zukunft unseres Planeten aus.

Was ist besser Query oder Table, was ist DBMS etc…?

Man sieht sofort, dass hier Theoretiker am Werk sind (ist nicht böse gemeint!)

Die richtige Fragestellung wäre:


Wie groß ist das Programm?

Wie viel Zeit hat man für die Umstellung?

Ist das eine professionale Anwendung oder programmiert man zu Hause (Zeitdruck?)?

Muss man eventuelle Kunden mit Update beliefern?

Ist BDE im Spiel?

Was für eine Datenbank benutzt man jetzt?


Und noch viele andere Fragen.

Eine Umstellung eines Programms ist keine 10 Minuten – Forum Entscheidung.


Und hier meine Antwort auf die Frage:

Was ist besser Query oder Table?

Es hängt immer davon ab, was ich erreichen möchte und eine pauschal Antwort ist hier nicht möglich
es seitdem kann man mir im Gegenzug diese Frage beantworten:


Was ist besser Kartoffel oder Reis?


Muchacho

[mkinzler]

Ich bin halt ein Theoretiker und vielliecht auch ein Vollidiot.
Wenn einer etwas fragt, antworte ich halt. Mein Fehler werde das Feld jetzt den Profis überlassen, welche sich wirklich auskennen und in der Zukunft meine Fresse halten!

[Muchacho]

Zitat:

Zitat von mkinzler

Ich bin halt ein Theoretiker und vielliecht auch ein Vollidiot.
Wenn einer etwas fragt, antworte ich halt. Mein Fehler werde das Feld jetzt den Profis überlassen, welche sich wirklich auskennen und in der Zukunft meine Fresse halten!

@mkinzler

Wie ich schon betont habe: Ist nicht böse gemeint.

Ich weiß schon seit langem, dass Du sehr gut bist, aber in den Software Häuser spielt die Music manchmal ganz andere Melodie!

Nichts für ungut

Muchacho

[joachimd]

Zitat:

Zitat von mkinzler

Bei den meisten DBMS handelt es sich um SQL-Server, von denen ging ich aus. Im Kontrast hierzu sah ich Desktop Datenbanken, also ein System ohne Server, wo alle Clients direkt auf die Datei(en) zugreifen und sich über Sperren synchronisieren.

hmmmm....wie passt in dieses Bild jetzt in zB Embedded FireBird? Der ist nämlich ein echter "SQL Server", aber trotzdem eine Desktop Datenbank :( Die Welt ist leider nicht schwarz (BDE/Paradox) und weiß (Oracle), es gibt durchaus aus viele, viele dazwischen.
nix für ungut...ich breche die Diskussion jetzt ab, wollte eigentlich auch gar nicht groß diskuttieren, sondern nur die Unklarheiten, die dadurch beim Fragesteller sicherlich aufkommen, richtigstellen.
Mach Du bitte trotzdem weiter...bitte,bitte,bitte ;)

[joachimd]

Zitat:

Zitat von RWarnecke

1. Worauf muss man achten ?
2. Lohnt es sich das Programm komplett neu aufzubauen ?
3. Wenn im Programm DB-Komponenten (TDBEdit, TDBLabel u.s.w.) habe, sollte ich diese ersetzen ?
4. Umstellung von TTable auf TQuery (ja/nein) ?

Ein bisschen was zum Thema: Ein(!) möglicher Weg weg von BDE/Paradox und hin zu einem Client/Server (und natürlich auch SQL sprechenden) System, könnte der ADS sein. Auf der diesjährigen CodeRage habe ich einen Vortrag dazu gehalten. Die Aufzeichnung gibt es hier. Der Aufwand ist natürlich immer vom bestehenden System abhängig, kann aber durchaus auch innerhalb weniger Minuten vonstatten gehen.

[RWarnecke]

Hallo Joachim,

ich habe Deinen Vortrag auf der Roadshow in Stuttgart gesehen und war davon echt begeistert. In meinem konkreten Fall geht es um eine BDE die abgelöst werden soll. Ich habe auch schon mit eurem Vertrieb telefoniert bezüglich Lizenzen etc. Das Gespräch hat mich ein wenig abgeschreckt, die ADS zu nehmen. Deshalb bin ich auch gerade dabei mir die Migration zu anderen DBMS anzuschauen.

Desweiteren geht es mir darum, wie und welchen Weg ich gehe für die Umstellung. Der Weg sollte unabhängig davon sein, egal auf welches System migriert wird.

[hoika]

Hallo,

also mein Weg weg von Paradox war.

1. Paradox durch Interbase6 / BDE / SQL-Links ersetzt

2. Ersatz aller langsamen TTable-Methoden durch TQuery
Langsam wurde durch Test mit einer "fully populated" DB gemacht
Danach gab es einen Mischmasch aus TTable und TQuery

3. Schrittweiser Ersatz der TTable durch TQuery
Ich hab da einfach bei meinen kleinsten DB-Units angefangen

4. Ersatz aller TQuery durch TMyQuery
TMyQuery = class(TQuery)
TMyQuery ist also immer noch eine BDE-TQuery

In diesem Zuge wurden alle Forms von direkten TMyQuery bereinigt,
jaja, RAD war halt früher so

5. Mein Clou ;)
{$IFDEF BDE}
TMyQuery=class(TQuery)
{$ELSE}
TMyQuery=class(TpFIBDataSet)

// fehlende Methoden nachbauen, u.a. die AutoCommits der BDE
{$ENDIF}

1.-5. TESTEN / TESTEN / TESTEN


Und warum dieser ganze Aufwand ?
Das Programm befindet sich im Einsatz und muss während der Umstellung
weiterhin erweitert/gepflegt werden.

Hm, Zeitaufwand.
Angefangen, als IB6 Opensource geworden ist ...
(Der reine DB-Code sind etwa 750.000 Zeilen).

Ende: bald ...

Um noch mal auf "richtige Datenbanken" zu kommen.

Paradox zerschiesst im Mehrbenutzerbetrieb (ausser Novell-Server)
regelmäßig seine Indizes (index out of date).
Der Absturz eines Clients während des Schreibens führ oft zu kaputter Tabelle
(Die Datei ist beschädigt, aber nicht der Vorspann).

Das ist für mich dann keine "richtige Datenbank" mehr.


Heiko

[RWarnecke]

Hallo Heiko,

danke für die Beschreibung wie Du die Anwendung umgestellt hast. Auch so hatte ich es mir vorgestellt. Der einzigste Vorteil bei mir wäre, ich brauche bis zum jetzigen Zeitpunkt keinen Paralellbetrieb zu garantieren.

Daszu habe ich noch eine Frage, wie hast Du die Tabellen umgestellt ? Manuell oder mit einem Tool ?

[mkinzler]

In deinem Fall bietet es sich an, die Datenbank neu zu entwerfen. So kannst du die erweiterten Features des neuen DBMS besser nutzen. Zudem waren die meisten Paradox&Co Datenbanken die mir bisher untergekommen sind, alle wenig bis garnicht normalisiert und hatten nur teilweise richtige Schlüssel. Ich persönlich würde bei datenbezogenen Schlüsseln auf künstliche umstellen.

[generic]

Normal ist das Programm von der Datenbank unabhängig.

Du solltest Funktionen aufrufen welche sinngemäß sagen:

Code:

HoleKunde()
SpeichereKunde()
LöscheKunde()

Generell sollte es deinen Programm egal sein, was innerhalb der Funktionen passiert.
Hauptsache deine Kundenobjekte werden gefüllt.

Wenn du diese Funktionen nun über ein Interface oder in einer passenden Objekt Vererbung nutzt,
dann lässt sich die Datenbank einfach austauschen.

Delphi-Quellcode:

TBasisPersistenz = class
  function HoleKunde(Kundennummer: cardinal): TKunde; abstract;
  procedure SpeichereKunde(K:TKunde); abstract;
  procedure LöscheKunde(K:TKunde); abstract;
end;

TMSSQL = class(TBasisPersistenz);

TRESTSQL = class(TBasisPersistenz);

TMYSQL = class(TBasisPersistenz);

Mit einem Interface sieht das leicht anders aus, funktioniert aber genau so.
Ein Interface kann bei Unit-Testing Vorteil haben.

Vorteil der Methode, du kannst z.B. auch REST-Services nutzen.
Einfach die Klasse austauschen und die Welt zum laden, löschen und speichern ist offen.