"Die Eine oder Viele"
Nun, der TE will ja scheinbar eine
DB auswählen oder muss diese Entscheidung treffen.
Erstmal nur "eine" zu nehmen, ist ja auch kein unumstößliche Entscheidung, hat wahrscheinlich primär Kostengründe.
Für mich ist die Entscheidung eine/viele dann am Ende nicht so spannend, solange es um
SQL Dialekt geht. Ein bisschen
SQL Code verdrehen kann man ja tatsächlich auf der "letzten Meile".
Viel entscheidender ist für mich die Frage der
DB Fähigkeiten jenseits von
ANSI SQL.
Also
Geodatentypen und andere, z.B. eigene
Volltext Suche
Index Varianten
JSON /
XML embedded
Connectivity / Remote
DB / Linked Server
Partitionierung
Replikation
um mal ein paar zu nennen
Dann gibt es noch Dinge, die eine
DB kann und außerhalb meines Interesses liegen.
Nutze ich spezifische Datenbankfunktionen, dann ist das natürlich eine starke Bindung an dieses Produkt. Aber:
Summa Sumarum kann ich für bestimmte Eigenprodukte sagen, Oracle oder Postgres ist mir egal, obwohl es um CS Systeme geht, die intensiven Gebrauch machen von spezifischer Datenbankfunktionalität, bspw. SEPA File Erzeugung oder Verarbeitung per
SQL.
Damit kann ich dann beliebige heterogene Anwendungs-Landschaften für mein Produkt bedienen und die
DB bleibt von alleine sauber.
Alternativ kann ich daraus auch ne Art Premium Marketing machen.
- Das Produkt gibt es in der Community Edition oder LowCost mit SQLite, dafür kann es bestimmte Dinge dann nicht
- Für KMU biete ich eine kostengünstige, leistungsfähigere Version mit PG oder Firebird mit einigen Zusatzfunktionen
- Und Enterprise dann mit ERP Funktion und Schnickschnack gegen MSSQL oder Oracle.