Grundsätzliche Fragen zu Beginn der Planung:
Welche Rolle spielen die Kosten?
1) Kann ich Datensätze aus anderen Systemen einfach importieren,
ohne die Hälfte der Datensätze zu verlieren (auch sollten Grafik-Felder
übertragbar sein).
Im Zweifel ist das keine Sache, die mit 3 Klicks im Import Assistent erledigt. Hier ist m.E. mehr entscheidend, wie sauber die Ursprungsdaten verarbeitet und typisiert sind. Wenn ich die Möglichkeit habe, rechne ich initiale Importe im Rahmen einer Migration nach Aufwand ab. Hier lauern oft böse Überraschungen, nur als Beispielt: Datum als Text gespeichert.
Grafikfelder sind eher eine Frage des Verfahrens, mit dem sie in der Ursprungsdb abgelegt sind. Im Prinzip speichert man eine Binärdatei, egal ob Grafik, Video oder EXE in einer BLOB Spalte. Wenn das Speicher-Verfahren / Format bekannt ist, ist es auch exportierbar und steht für andere Systeme, Verfahren bereit.
2) Wie kann ich die Anzahl der Datensätze berechnen, die die Datenbank verarbeiten
kann (auch mit Grafikfeldern) ?
Das kannst Du Dir vermutlich sparen, solche Berechnungen sind relevant für die Dimensionierung des Systems, aber nicht so sehr für die Frage, welches System. Technisch gesehen geht das heute in den Peta Byte Bereich. Sollte reichen.
3) Ist das Speichervolumen begrenzt?
s.o.
4) Einfachheit des Systems (der Datenbank und der Installationsanleitung)
Eine
DB zu installieren ist idR immer recht einfach. Ich kenne nicht soviele Systeme, MS kann sowas idR gut, Oracle idR nicht so gut. Überrascht war ich vor einigen Wochen, als ich zum ersten mal Postgres installiert hab. Ein ziemliches Gerödel, man kann viele verschiedene Protokolle auf Serverebene in verschiedenen Richtungen freischalten. Netzweit, Systemweit, user-, protokollspezfisch. Für mich war das gewöhnungsbedürftig, bzw. nicht grad der anvisierte Schnellstart. Das war unter Ubuntu oder Debian, weiß nicht mehr genau.
Auch die Server- und Clientinstallation unter Windows war holprig, das war aber eher ein Installer Problem.
Allgemein wird es idR schwieriger, wenn mehrere
DB des gleichen Herstellers, evtl. noch unterschiedlicher Version / Lizenz installiert werden sollen. Z.B. Express Version neben Vollversion usw...
5) Sehr schnelle Einarbeitung in das System ?
Kommt auf die Verwendung an, eine
DB als Blackbox sollte kaum speziellen Einarbeitungsaufwand bedeuten. Erst wenn systemspezfisches
SQL oder
db Programmierung genutzt wird, hat man da Aufwand.
Administrativ sieht es natürlich noch etwas anders aus. Online-Backup, Rechte- und Rollen Konzepte und Umsetzung und anderes erfordern je nach Bedarf schon spezifische Einarbeitung.
6) Anwendung unbegrenzt erweiterbar ?
Was betrachtest Du als Anwendung? Willst Du wirklich eine Server Anwendung implementieren? Oder einen App Server in Mehrschicht Architektur? Im Client hast Du alle Freiheit, die man sich nur denken kann, egal welche
DB.
7) Auch für spezifische Anwendung zu empfehlen: z.B. wenn spezielle Formeln
zur Anwendung kommen wie bei Chemischen Formeln, wo spezielle Symbolik
zur Anwendung kommen (tiefgestellte Indices etc.)
Die Frage versteh ich nicht so ganz, ähnlich zur "Grafik-Frage". Du wirst in keiner
DB einen spezifischen Formeldialekt oder soetwas speichern. Bestenfalls vielleicht vielleicht
XML, RTF, opendocument Format oder sowas. Schlimmestenfalls proprietäre Binär-Dateien wie Grafik usw.
Das hat nichts mit der
DB zu tun.
Was würdet Ihr empfehlen?
Wenn Du noch etwas zum gedachten Einsatz schreibst, könnte man eine Empfehlung geben.
Ich hab fast eh nur (noch ) Oracle Erfahrung, eine ungefärbte Empfehlung wirst Du aber sowieso kaum bekommen.
Für's erste:
Wenn es tatsächlich um Leistungsstärke im Bereich "Anwendung" geht, sollte es eine
DB mit entsprechenden Fähigkeiten bei Storedprocs werden. Das wären m.E. MS
SQL, Oracle und Postgres. Etwas bescheidener auch
mySQL/Maria, ...
Anwendungsimplementierung kannst Du aber wie gesagt auch durch einen App Server erhalten, dann kommst Du mit einer
DB ohne Programmiermöglichkeit aus. Die
DB wird damit austauschbar, mit Hibernate, JPA usw. ist das ja oberstes Ziel und total angesagt. Das ist aber nicht so mein Ding, genau wie NoSQL. Auch hier, wie so oft, kommte es erheblich auf den Anwendungsfall an. Wenn ich mal was mit NoSQL mache, dann wahrscheinlich kein Buchungssystem.