Kauf- und Kontenverwaltung - Datenbank notwendig?

[jobo]

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

[Delphi.Narium]

Zitat von jobo:

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

Oh Mist, hab' ich nicht dran gedacht, da ich fast nur noch SynEdit nutze.

@Asura
ADOTable ist für die statische Anzeige eines Tabelleninhaltes, ADOQuery für die Ausführung von SQL-Statements.

DataSource benotigt ein TDataSet, ADOQuery und ADOTable sind beide von TDataSet abgeleitet, funktionieren also beide.

Einfach mal von beiden eins aufs Formular pappen, 'ne DataSource dazu und im Objektinspektor zum DataSource bei DataSet schauen, was da so zur Auswahl steht. Alles was da angezeigt wird, kann man auch nutzen.

Bezüglich Deiner Alternative zum SelAvail: Ja, das geht auch so, mit SelText bekommst Du ja den markierten Text. Wie und ob das bei unterschiedlichen Komponenten unterschiedlich funktioniert ist ja eher nachrangig, Hauptsache: Ziel erreicht

Das Memo ist für die Eingabe von SQLs. Dort tut sich nichts, außer Du gibst dort was ein. Deine Eingabe wird dann an die ADOQuery weitergereicht und nach deren öffnen, mit Hilfe einer DataSource und den dieser zugeordneten Datenkomponente (z. B. einem DBGrid), angezeigt.

Mal einen nicht wirklich sinnvollen Quelltext, mit dem man das demonstrieren könnte:

Delphi-Quellcode:

ADOQuery.Close;
ADOTable.Close;
ADOTable.TableName := 'users';
DataSource.DataSet := ADOQuery;
ADOQuery.SQL.Text := 'select * from users where ID = 1';
ADOQuery.Open;
ShowMessage('Sieht man jetzt den User mit der ID 1?');
ADOQuery.Close;
ADOTable.Open;
ShowMessage('Sieht man jetzt alle User?');
ADOTable.Close;

Dieser Quelltext ist so in etwa für eine Demonstration geeignet, aber nicht für den wirklichen Betrieb.

Wenn ich etwas benötige, um beliebige Daten anzuzeigen, nutze ich nie eine ADOTable, sondern immer nur ADOQuery (bzw. bei anderen Datenbankkomponenten die entsprechenden Gegenstücke). Will ich alle Daten einer Tabelle sehen, dann ist die Abfrage eben Select * from ebendertabelledieichsehenwill.

Ein Hin und Her per Zuweisung von diversen DataSet-Nachkommen zu eine DataSource macht nur den Quelltext verwirrend und scheint mir nicht zielführend.

Mal eben wild zusammengedaddelt so eine Art "Demo"

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, DB, ADODB, ExtCtrls, DBCtrls, Grids, DBGrids, ComCtrls;

type
  Tfrm = class(TForm)
    DataSource: TDataSource;
    ADOQuery: TADOQuery;
    pnTop: TPanel;
    StatusBar: TStatusBar;
    DBGrid: TDBGrid;
    DBNavigator: TDBNavigator;
    Splitter: TSplitter;
    ADOConnection: TADOConnection;
    btnSQL: TButton;
    btnEnde: TButton;
    pnInfo: TPanel;
    SQLEingabe: TMemo;
    Splitter1: TSplitter;
    Tabellen: TMemo;
    procedure btnEndeClick(Sender: TObject);
    procedure btnSQLClick(Sender: TObject);
    procedure TabellenDblClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  frm: Tfrm;

implementation

{$R *.dfm}

procedure Tfrm.btnEndeClick(Sender: TObject);
begin
  ADOQuery.Close;
  ADOConnection.Close;
  Close;
end;

procedure Tfrm.btnSQLClick(Sender: TObject);
var
  slTables : TStringList;
  slFields : TStringList;
  i        : Integer;
  k        : Integer;
begin
  if not ADOConnection.Connected then begin
    if ADOConnection.ConnectionString = '' then begin
      ADOConnection.ConnectionString := PromptDataSource(handle,'');
    end;
    if ADOConnection.ConnectionString <> '' then begin
      ADOConnection.Open;
      Tabellen.Lines.Clear;
      slTables := TStringList.Create;
      slFields := TStringList.Create;
      ADOConnection.GetTableNames(slTables,false);
      for i := 0 to slTables.Count - 1 do begin
        Tabellen.Lines.Add(slTables[i]);
        ADOConnection.GetFieldNames(slTables[i],slFields);
        for k := 0 to slFields.Count - 1 do begin
          Tabellen.Lines.Add(Format('  %s',[slFields[k]]));
        end;
      end;
      slTables.Free;
      slFields.Free;
    end;
  end;
  if ADOConnection.Connected then begin
    ADOQuery.Close;
    ADOQuery.SQL.Clear;
    if SQLEingabe.SelLength <> 0 then begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.SelText));
    end else begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
    end;
    if Trim(ADOQuery.SQL.Text) <> '' then begin
      ADOQuery.Open;
    end;
  end;
end;

procedure Tfrm.TabellenDblClick(Sender: TObject);
begin
  if Tabellen.SelText <> '' then begin
    SQLEingabe.SelText := Tabellen.SelText;
  end;
end;

procedure Tfrm.FormCreate(Sender: TObject);
begin
  if FileExists(ChangeFileExt(Application.ExeName,'.sql')) then begin
    SQLEingabe.Lines.LoadFromFile(ChangeFileExt(Application.ExeName,'.sql'));
  end;
end;

procedure Tfrm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  SQLEingabe.Lines.SaveToFile(ChangeFileExt(Application.ExeName,'.sql'));
end;

end.

Und das Formular dazu:

Delphi-Quellcode:

object frm: Tfrm
  Left = 4
  Top = 4
  Width = 1000
  Height = 640
  Caption = 'Demo-Datenbankoberfläche ;-)'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  OnClose = FormClose
  OnCreate = FormCreate
  PixelsPerInch = 96
  TextHeight = 13
  object Splitter: TSplitter
    Left = 0
    Top = 265
    Width = 992
    Height = 8
    Cursor = crVSplit
    Align = alTop
    Beveled = True
  end
  object pnTop: TPanel
    Left = 0
    Top = 0
    Width = 992
    Height = 41
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 0
    object btnSQL: TButton
      Left = 8
      Top = 8
      Width = 97
      Height = 25
      Caption = '&SQL ausführen'
      TabOrder = 0
      OnClick = btnSQLClick
    end
    object btnEnde: TButton
      Left = 112
      Top = 8
      Width = 75
      Height = 25
      Caption = '&Ende'
      TabOrder = 1
      OnClick = btnEndeClick
    end
  end
  object StatusBar: TStatusBar
    Left = 0
    Top = 594
    Width = 992
    Height = 19
    Panels = <>
  end
  object DBGrid: TDBGrid
    Left = 0
    Top = 273
    Width = 992
    Height = 296
    Align = alClient
    DataSource = DataSource
    TabOrder = 2
    TitleFont.Charset = DEFAULT_CHARSET
    TitleFont.Color = clWindowText
    TitleFont.Height = -11
    TitleFont.Name = 'MS Sans Serif'
    TitleFont.Style = []
  end
  object DBNavigator: TDBNavigator
    Left = 0
    Top = 569
    Width = 992
    Height = 25
    DataSource = DataSource
    Align = alBottom
    TabOrder = 3
  end
  object pnInfo: TPanel
    Left = 0
    Top = 41
    Width = 992
    Height = 224
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 4
    object Splitter1: TSplitter
      Left = 697
      Top = 0
      Width = 8
      Height = 224
      Beveled = True
    end
    object SQLEingabe: TMemo
      Left = 0
      Top = 0
      Width = 697
      Height = 224
      Align = alLeft
      TabOrder = 0
    end
    object Tabellen: TMemo
      Left = 705
      Top = 0
      Width = 287
      Height = 224
      Align = alClient
      TabOrder = 1
      OnDblClick = TabellenDblClick
    end
  end
  object DataSource: TDataSource
    DataSet = ADOQuery
    Left = 632
    Top = 48
  end
  object ADOQuery: TADOQuery
    Connection = ADOConnection
    Parameters = <>
    Left = 560
    Top = 48
  end
  object ADOConnection: TADOConnection
    Left = 472
    Top = 48
  end
end

Im realen Leben sollte man allerdings nicht gänzlich auf jedwede Fehlerbehandlung verzichten.

[Asura]

Moin Moin,
nachdem ich erfolgreich nun mein Projekt mit Access beendet habe widme ich mich nun einem neuen Projekt.
Nun möchte ich aber nicht mehr mit Access arbeiten, sondern nun auf eine Datenbank zurückgreifen, die mit einem Server dann gehalten wird.

Ich bin nun auf der Suche nach Anbietern, die günstig Datenbankserver anbieten.
Bis ich einen gefunden habe, würde ich jedoch gerne schon mal beginnen. Welche Lösung wäre die Beste, um direkt eine Schnittstelle zu haben ohne groß im Programmcode was ändern zu müssen.
Eventuell in Richtung Homeserver?
Die Datenbankmodellierung habe ich bereits fertig, wenn man da noch mal rüber schauen könnte und eventuell Verbesserungsvorschläge

[Delphi.Narium]

Mein Vorgehen ist erstmal:

Connectionstring auf die neue Datenbank ändern und Programm starten.
Wenn's nicht geht (was äußerst selten ist) muss ich halt die Probleme beheben.

Wenn man sich bei den SQLs an den Standard hält, sind Probleme eher selten, ab und an werden Datentypen etwas anders gehandhabt, aber die Masse sollte einfach laufen.

[edit - etwas provokant]
Wenn man mit Delphi eine gute Datenbankapplikation geschrieben hat, ist es der egal, gegen welche Datenbank sie läuft, man ändert die Datenbankverbindung (gerne per Dialog) und das Programm läuft gegen eine andere Datenbank. Der Softwareentwickler muss die Datenbanken nicht mal alle kennen.

Klar: Auf Datenbankseite darf man dann nur das nutzen, was alle Datenbanken können. Dafür gibt es den Standard, der weitgehend eingehalten wird.

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.
[/edit]

[TigerLilly]

ad DB-Server:
Wir verwenden den MS SQL Express. Der ist kostenfrei, kann auch im Netz für Mehrbenutzer fungieren + ist mit den großen Editions gut skalierbar. Für uns funktioniert das sehr gut, egal ob Einbenutzer mit Laptop oder Multiuser mit Server.
Ähnliches gibt es auch von Oracle. Alternativ gibt es natürlich auch Firebird, Progress, mySQL.

ad Datenmodell formal:
- die Tabellennamen brauchen die Präfixe nicht. Entscheide dich, wie die Tabellen heißen sollen + aus.
- Die Feldnamen der Tabellen brauchen die Präfixe ebenfalls nicht. Das macht die Namen nur unübersichtlich.
- Die Namensgebung ist nicht einheitlich: bacc_usr_ID und sere_ID - sollte wohl book_sere_ID sein. Ähnliches für booT_ID.
- Die Schreibweise ist nicht einheitlich: Wenn du booT_ schreibst müsste es auch bAcc_ heißen.
- Entscheide dich, ob die nach dem _ groß oder klein weiterschreibst: sere_Name vs catg_name.
- Die Namen der Tabellen sollten entweder alle Einzahl (bevorzugt) oder Mehrzahl sein, nicht mischen (usr_users vs booT_bookingtype).


ad Datenmodell inhaltlich:
- In Zeiten von Password-Hacks würde ich keine Passwörter speichern, sondern nur ihre Hash-Äquivalente.
- Die Verwendung von englischen Bezeichnern bleibt jedem überlassen, ich persönlich finde, dass das kein Muss ist. Verständlichkeit hat Vorrang.
- Ob du mit den angeführten Attributen auskommst, musst du wissen, ich finde die Infos zur Bank und zum User sehr dürftig. Passwörter können ein Ablaufdatum haben, sollten ev. Nicht wiederverwendet werden. USer haben Klarnamen, ev E-Mail etc. Banken vielleicht eine Adresse?
- ob Buchungen wirklich nur eine Kategorie haben, musst auch du wissen, aber ev haben die Kategorien noch eine übergeordnete Kategorie. Bzw gehören zu Ein/Ausgängen.
- Senderreceiver kann ev auch weitere Infos vertragen.

HTH TigerLilly

[p80286]

Warum werden username und pw doppelt abgelegt?
Sollten mehrere User auf einen Bankaccount zugreifen müssen/können, sollte diese Relation über eine entsprechende Tabelle abgebildet werden.

Gruß
K-H

@Delphi.Natrium
Ganz so einfach ist es in der Praxis nicht, aber das Prinzip ist schon korrekt.

[jobo]

Zitat von Delphi.Narium:

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

[Delphi.Narium]

Zitat von jobo:

Zitat von Delphi.Narium:

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

@Jobo:

Du beschreibst eigentlich genau das, was ich meine:
entweder <-> oder.

Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.

Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.

Ein bisserl Logik in der Datenbank und die "Reste" in N Applikationen? NoGo

Wer sowas entwirft, empfiehlt ... gehört gehauen

[Asura]

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?


Dann Dankeschön für die kritische Bewertung!
Ich werde davon wohl so gut wie alles umsetzen.

Bezüglich der Hash-Ablage und warum ich zwei Passwörter verwende.
Das eine ist das Passwort für das Programm zum einloggen, dass andere sind die Benutzerdaten für den Bankaccount.
Mein Vorhaben sieht so aus, dass das Programm sich in den Bankaccount des jeweilen Users nach der Auswahl seiner Bank einloggt, die Umsätze herunterlädt und den Benutzer dann die Wahl der Kategorievergabe oblässt und dann diese statistisch darstellt und bewertet.
Deswegen kann ein User (Client) mehrere Bankaccounts haben.

Wegen der Passwortablage:
Ich bin mir nicht sicher, ob du das meinst was ich vorhabe:
Ich würde das Passwort über das Programm verschlüsseln und der verschlüsselte Inhalt wird dann auf die Datenbank abgelegt. Wenn man sich einloggt, entschlüsselt er den Wert und gleicht diesen dann ab.
Ich wollte auch eine Option des automatischen Logins einspeisen, habe das zurzeit zwar noch alles ohne Verschlüsselung aber er speichert die Logindaten in einer Ini-Datei ab. Hier würde ich dann auch das Passwort verschlüsseln und nur diesen Wert in die Ini schreiben und diesen wieder laden, entschlüsseln, vergleichen.

Möchte noch kurz anmerken: Das Programm zielt nicht ab kommerziell genutzt zu werden. Das wird nur unter ausgewählten Personen verteilt. Ich habe leider gar keine Rechte mit einer Student Version von RAD hier kommerziell zu werden. Also würde davon nur hauptsächlich Ich und ein paar gute Bekannte davon profitieren.


//EDIT:

Ich habe nun die Datenbankmodellierung angepasst.
Ich habe bei Senderreceiver ein "Usage" hinzugefügt, der soll dann ein Boolean Wert haben (Sender = 0, Receiver = 1).
Bei Bookings ist Bookingtype nun raus und soll nun die Oberkategorie (Einzahlung/Auszahlung) sein. Hier habe ich eine Frage. Da es ja nur die zwei Optionen gibt, würde es nicht reichen einfach nur eine Spalte bei Kategorien hinzuzufügen als Boolean mit 0 = Eingang, 1 = Ausgang. Aber es stimmt, dass dies eher eig. als Oberkategorie dienen soll. Also so wie ich das jetzt habe nur eventuell in der Tabelle Bookingtype statt Name den Boolean wert?
Man müsste dann später ja nur über die Kategorien gehen, um die Eingänge bzw. die Ausgänge darzustellen.

[Delphi.Narium]

Zitat von Asura:

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?

Doch genau das: Andere Datenbank, anderer Connectionstring und gut ist es.

Es wäre für meine Begriffe recht erbärmlich von Delphi, wenn ich je Datenbank andere Datenbankkomponenten nutzen müsste.

Habe im Laufe meines Lebens so einiges an Software schreiben müssen, bei dem ich zu Beginn der Entwicklung noch nicht wusste, gegen welches DBMS sie denn letztendlich laufen wird.

Das wäre ja mörderisch, wenn man dann die Software erstmal gegen die zur Entwicklung verfügbare Datenbank mit den passenden Komponenten entwickelt und wenn man dann irgendwann erfährt, dass beim Kunden eine andere Datenbank zum Einsatz kommt, macht man alles, mit anderen Datenbankkomponenten, neu?
Oder die Software kommt bei mehreren Kunden zum Einsatz, aber jeder hat sich für ein anderes DBMS entschieden? Dann gibt es entsprechend viele Varianten der Software, schön mit jeweils eigenen Komponenten?

Und was ist, wenn aus irgendeinem Grund mal die zuerst gewählte Datenbank wegfällt? Eine Neuentwicklung mit anderen Datenbankkomponenten?

Warum mag man wohl bei den ADO-Komponenten bei der Erstellung des Connectionstrings eine recht große Auswahl an unterschiedlichen Möglichkeiten zur Erstellung des Connectionstrings und eine (ggfls. systemabhängig) mehr oder weniger große Auswahl an unterschiedlichen DBMS bekommen? Nur um dann festzustellen, dass es nur gegen Access funktioniert?
In dem Fall würd' für meine Begriffe die sofortige Deinstallation dieser Komponenten das Einzige sein, was ich mit ihnen mache!

Es gibt diverse Möglichkeiten, um auf Datenbanken zuzugreifen, sei es FireDac, UniDac, dbgo, ADO, Zeos, (manche kennen noch die BDE ) und was weiß der Geier sonst noch.
Sicherlich sollte man am Anfang eine Entscheidung treffen, welche Variante man nutzt.
Aber egal welche man nutzt: Sobald man die Datenbank wechselt, muss man auch die Datenbankkomponeten wechseln?
Das hieße doch letztlich: Für jede Datenbank müsste es eine eigene Palette von entsprechenden Datenbankkomponenten geben. Das wäre ja dann fast schon absurd.
Wo blieben denn da die datenbankunabhängige Entwicklung von Datenbanksoftware?

Brauchen wir dann eventuell für jede Sprache ein eigenes TEdit, ein eigenes TMemo ...

Delphi ist hervorragend dazu geeignet, Datenbanksoftware zu schreiben und ist dabei nicht auf eine bestimmte Datenbank festgelegt. Dies kann nur gelingen, wenn es eben nicht erforderlich ist, beim Datenbankwechsel die gesamte Datenbankschnittstelle auszutauschen.

Probleme beim Datenbankwechsel kann es geben, wenn sehr datenbankspezifische SQLs genutzt werden. Die eine DB will halt top 10, die andere first 10, eine andere RowNum < 11, wieder eine andere Limit 10 und das auch noch an unterschiedlichen Stellen des SQLs, nur um an die ersten 10 Zeilen einer Ergebnismenge zu kommen. Das ist aber bei allen Datenbankkomponenten gleich.

Wenn Du mit dem Auto normalerweise über die Autobahn zur Uni/Arbeit/Oma/... fährst und nicht über die Landstraße, wirst Du doch nicht dann, wenn Du ausnahmsweise mal über die Landstraße fährst, vorher einen entsprechenden Motor einbauen? (ja, der Vergleich hinkt.)

Probleme beim Wechsel der Datenbank kann und wird es geben, aber nicht aufgrund der Komponenten, sondern Aufgrund der Unterschiedlichen Syntax im SQL, sobald man auch nur um Haaresbreite vom (weitgehend einheitlich unterstützten) SQL-Standard abweicht.

Man muss sich im realen Leben also Gedanken darüber machen, welche Änderungen am SQL notwendig sind, um mit unterschiedlichen Datenbanken zusammenarbeiten zu können. Und darüber, wie man das im Programm am besten gehändelt bekommt. Hierzu gibt es im Forum schon vielfältige, teils recht kontroverse, Diskussionen. Die solltest Du mal zu Rate ziehen.

ADO ist jetzt vielleicht nicht aus jedermanns Sicht die beste Datenbankschnittstelle, aber welche Datenbank man damit nutzt, sollte egal sein.

Mein konkretes Vorgehen in Deinem Fall wäre:

Connectionstring auf die neue Datenbank ändern, in der neuen Datenbank für das Vorhandensein des benötigten Datenmodells sorgen.
Programm starten und auf Herz und Nieren testen.
Und nur wenn Probleme auftreten nach einer Möglichkeit der Beseitigung suchen und diese (wenn irgend möglich) so wählen, dass das(die) bisher unterstützte(n) DBMS auch weiterhin genutzt werden kann(können). (Unterschiedliche Lösungsansätze findet man hier im Forum.)