Datenbankwahl

[OrgFreak]

Guten Abend

Bin ein Anfänger in FireBird und MySQL.
Kann mir jemand helfen, wenn ich eine Datenbank neu plane ?

Grundsätzliche Fragen zu Beginn der Planung:

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).

2) Wie kann ich die Anzahl der Datensätze berechnen, die die Datenbank verarbeiten
kann (auch mit Grafikfeldern) ?

3) Ist das Speichervolumen begrenzt?

4) Einfachheit des Systems (der Datenbank und der Installationsanleitung)

5) Sehr schnelle Einarbeitung in das System ?

6) Anwendung unbegrenzt erweiterbar ?

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.)


Was würdet Ihr empfehlen ?

Für Eure Antworten bin ich Euch im voraus dankbar (bitte nur konstruktive
Beiträge).


Gruss

OrgFreak

[Phoenix]

1.) Mit den richtigen Tools ja.

2.) Nein. Das Problem ist auch im Normalfall nicht die Datenmenge, sondern das, was die Software auf der Datenbank mit diesen Daten anfängt.
Im Normalfall ist aber nahezu jede Datenbank geeignet. Und jede Datenbank hat irgendwo ihre Schwächen und dann muss man anfangen zu optimieren.

3.) Kommt auf die Datenbank drauf an. Die kostenlose Version des SQL Servers (die Express Edition) speichert z.B. maximal 10 GB pro Datenbank. Die kostenpflichtige steigt dann erst bei hunderten Petabyte aus. Heutzutage ist eher das unterliegende Dateisystem der begrenzende Faktor.

4.) Ist auch wieder Individualsache. ich persönlich komme z.B. super mit MySQL bzw. ja jetzt HeidiSQL und dem Microsoft SQL Server zurecht. Postgres, Interbase/Firebird gehen grad noch so. Oracle ist für mich der Horror. Andere lieben hingegen Postgres und wollen Heidi nicht anfassen.

5.) Schlag Dir das aus dem Kopf. Die meisten Datenbanken (ausser Oracle) haben eine sehr einfache Einstiegshürde. Ab irgendeinem Punkt geht es aber in den Details, und ab dann wird die Lernkurve sehr steil. Meist ist der Punkt erreicht, wenn man aber grad ein schwieriges Produktionsproblem hat. Man sollte sich also idealerweise vorher das System im Detail angucken. Und damit sind alle Systeme auch wieder in etwa gleich komplex.

6.) Das ist kein System.

7.) Das wirst Du nur durch Einzelfallanalyse mit unterschiedlichen System herausfinden.

Grundsätzlich: Heutzutage ist eher die Frage, ob Du tatsächlich eine relationale Datebank brauchst oder ob Du mit einer NoSQL- / Dokumentenorientierten Datenbank besser bedient bist. Auch das ist eher eine Frage des Anwendungsfalls.

Es wird Dir hier niemand eine valide Empfehlung für ein konkretes System aussprechen können, ohne nicht einige Tage mit Deinen konkreten Use-Cases eine Analyse gefahren zu haben die die verschiedenen Problemstellungen einigermassen akkurat nachstellt.

Aus Erfahrung kann ich jedoch sagen, das es keine ganz schlechte Idee ist, wenn man auf ein System setzt, für das im eigenen Organistionsbereich bereits das größte Know-How vorhanden ist. Das Erspart einem nämlich jede Menge Fehler mit einem neuen System, und die werden hinten raus immer teuer / aufwändig zu beheben.

[jobo]

Zitat von OrgFreak:

Grundsätzliche Fragen zu Beginn der Planung:

Welche Rolle spielen die Kosten?

Zitat von OrgFreak:

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.

Zitat von OrgFreak:

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.

Zitat von OrgFreak:

3) Ist das Speichervolumen begrenzt?

s.o.

Zitat von OrgFreak:

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...

Zitat von OrgFreak:

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.

Zitat von OrgFreak:

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.

Zitat von OrgFreak:

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.

Zitat von OrgFreak:

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.

[OrgFreak]

Guten Tag

Habt Dank fuer Eure guten Antworten.
Ich muss mir zuerst noch mehr Gedanken zu meiner DB-Anwendung machen,
komme dann eventuell später darauf zurück.

Also bei Chemischen Formeln hab ich in Delphi eine DBChemFormel-Unit gefunden,
damit kann man Chemische Abkürzungen wie z.B. H20 (Ziffer 2 natürlich tiefgestellt),
C2H5OH (Ethyl-Alkohol), etc. in der BDE anwenden.
Sonst hab ich mir den Umweg über eine JPEG- oder anderes Bildformat vorgestellt
(für Chemische Strukturformeln).
Beispiel im Anhang.

Also ich melde mich dann wieder, habt erst mal Dank für die Beantwortung meiner Fragen.


Gruss

OrgFreak

[OrgFreak]

Guten Tag

Hab zur einfachen Illustration ein kleines Beispiel einer einfachen und nicht zu
komplexen Anwendung einer Datenbank im Chemie-Bereich. Es ist wirklich eine sehr
einfache und nicht sehr umfangreiche Datenbank. Das Beispiel zeigt die Anwendung
meiner "Chemie-Zusatz-Komponenten". Die Tief-Stellung der Indices ist in der Table
nicht möglich, jedoch mit den korrespondierenden Chemie-Komponenten (Edit-Feld, und
DBEdit-Feld, spezifisch)darstellbar (siehe angefügtes Beispiel im Anhang).

Ich wollte Euch (Unerfahrene Chemie-Fachleute (nicht beleidigend gemeint)) nur die
Problematik ein wenig näher bringen.

Liebe Grüsse sendet Euch

OrgFreak

[OrgFreak]

Guten Tag zusammen

Hab noch ein Zusatz zu Daten-Bank-Konvertierung:


Hatte eine Datenbank mit der BDE erstellt (mit BLOB-Feldern für Grafiken).
Wollte diese dann in andere Formate umwandeln. Ging gut, aber mit den Grafik-
Feldern bekam ich Probleme. Diese wurden beim "Export", respektive beim "Import"
abgeschnitten und gingen teilweise, oder ganz verloren.
Also, wenn man an der Kapazitätsgrenze angelangt ist, bekommt man so oder so
immense Probleme.

Gruss

OrgFreak

[Perlsau]

Zitat von OrgFreak:

[COLOR="Wheat"]Hatte eine Datenbank mit der BDE erstellt (mit BLOB-Feldern für Grafiken).
Wollte diese dann in andere Formate umwandeln. Ging gut, aber mit den Grafik-
Feldern bekam ich Probleme. Diese wurden beim "Export", respektive beim "Import"
abgeschnitten und gingen teilweise, oder ganz verloren.

In welchem Datenbank-Format liegen denn die ursprünglichen Grafiken vor? (BDE ist keine Datenbank, sondern lediglich eine DB-Engine, die verschiedene DBMS ansteuern kann.) Wenn du mit einer alten Anwendung auf die BDE-Datenbank zugreifen kannst, dann kannst du sicher auch die Grafiken dort auslesen. Somit bastelst du dir in deiner neuen Anwendung einfach eine Methode, die sich mit beiden Datenbanken (der neuen und der alten) verbindet und die Grafik-Daten "rüberschaufelt".

p.s.: Die Farben, die du in deinen Postings wählst, sind nur schwer lesbar, weil sie kontrastarm sind und deshalb den Augen weh tun ...

[mkinzler]

Blobs werden wohl von jedem einigermassen aktuellen Datenbanksystem unterstützt. Es besteht dann auch kein "Kapazitäts"-Problem, da diese Felder beliebig groß werden dürfen. Die Blobfelder werden im Allgemeien auch getrennt von den restlichen Daten gespeichert.
In Interbase/Firebird geschieht dies z.B. dynamisch ( bei wenig Inhalt in der Tabelle, sonsz nur Verwis8Blobpointer und Speicherung gesondert.

P.S: Wir sehen Pushen nicht gern. Du kannst deien Beiträge 24 Stunden lang bearbeiten und das solltest du auch tun, wenn dir noch etwas einf#ällt und bisher noch keiner geantwortet hat.

[OrgFreak]

Guten Tag

Die Daten liegen ursprünglich im Paradox-Format vor (mit BLOB-Grafik-Feldern)

Gruss

OrgFreak