Ich würde auf jeden Fall Postgres empfehlen!
- Du bist Anfänger und willst einen Standard lernen
- Du willst Stabilität
- Du willst eine gute Community
- Du willst (vermutlich) keine Lizenzprobleme bekommen, wenn Deine Anwendungen mal steil gehen
- Du willst vermutlich keine Lizenkosten
plus, relevant aus Spaß oder wenn es Ernst wird (erfolgreiches Projekt mit echter Last und großen Datenmengen):
- Du willst vielleicht etwas mehr Funktion(s-Vielfalt), auch wenn es kein SQL Standard ist (kennt eh keiner)
- Du willst vielleicht andere, verwandte Systeme einsetzen, die letztlich von Postgres abgeleitet sind oder es halt als DB nutzen
- Du willst wenig "coden", sondern Datenverarbeitung auf dem Server "machen lassen"
- ..
Mit einem kleinsten gemeinsamen Nenner kannst Du sicher Postgres genau wie andere Systeme (Firebird, mySQL, Maria, Oracle, MSSQL, ..) mit Lazarus einsetzen. Da gibt es m.E. keine pros und cons die für oder gegen bestimmte Systeme sprechen.
Firebird oder SQLite (und MSDE, gibts das noch? ok, sogar access), eigenen sich gut für lokale Datenhaltung mit Lazarus/Delphi. Heute würde ich dafür wahrscheinlich einfach json nehmen, wenn die lokale Datenhaltung nicht sehr umfangreich ist.
SQLite hat in den letzen Jahren einigen Funktionszuwachs erhalten, der offenbar direkt von Postgres abgeleitet ist. Das zeigt die Qualität von PG (auch im Sinne von open source), SQLite würde ich dennoch nicht empfehlen, weil es einen sehr spezifischen Umgang mit Datentypen hat. Das ist gerade für Anfänger nicht ohne.
Fang mit Postgres an und folge dieser Idee:
Entwickele ein Programm, dass möglichst nahe am Standard (SQL) ist und lerne SQL.
Stelle "danach" (es ist eh nie fertig) Dein Programm auf andere Datenbanken um und schau Dir an, wo es Probleme bei der Kompatibilität gibt.
Wenn Du mit einem "abgespeckten" System mit wenig Funktionsumfang und viel proprietären Funktionen anfängst, hast Du am Ende sehr viel Aufwand, einen Umzug hinzubekommen und noch viel schlimmer:
Du baust dann für die neue DB in einem guten Datenbanksystem proprietäre Funktionen nach, die es gemäß Standard viel besser und komfortabler gibt, die überhaupt keinen Programm Code benötigen würden, sondern einfach in SQL abgearbeitet werden könnten.
Noch ein Hinweis:
Datenimport und Datenexport ist dabei ein besonderes Thema. Es ist wirklich sehr herstellerspezfisch. Aber auch hier muss sich Postgres nicht verstecken. Vereinheitlichung kommt da wahrscheinlich am ehesten über Lazaruskomponenten. Wenn es schnell sein soll, landest Du wieder, wie immer bei reinen Datenbankverfahren.
Und was das Thema Geschwindigkeit allgemein angeht noch ein Hinweis. Die Hardware ist heute idR so leistungsfähig und Speicher so billig und verfügbar, dass Performance eigentlich gar kein Problem ist, selbst bei schlechter Programmierung. Erst der Erfolg (viele User, viele Daten) bringt die Probleme. Dann spätestens muss man optmieren. Das soll nicht heißen, dass man darauf nicht achtet. Man kann sich aber schonmal mit dem Gedanken anfreunden, dass die ersten eigenen Ideen manchmal nicht lange halten. Falls das am Erfolg liegt, ist das ja sogar irgendwie cool.
