|
Datenbank: ? • Version: ? • Zugriff über: ?
Datenbankwahl
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 |
AW: Datenbankwahl
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. |
AW: Datenbankwahl
Zitat:
Zitat:
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:
Zitat:
Zitat:
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:
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:
Zitat:
Das hat nichts mit der DB zu tun. Zitat:
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. |
AW: Datenbankwahl
Liste der Anhänge anzeigen (Anzahl: 1)
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 |
AW: Datenbankwahl
Liste der Anhänge anzeigen (Anzahl: 2)
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 |
AW: Datenbankwahl
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 |
AW: Datenbankwahl
Zitat:
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 ... |
AW: Datenbankwahl
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. |
AW: Datenbankwahl
Guten Tag
Die Daten liegen ursprünglich im Paradox-Format vor (mit BLOB-Grafik-Feldern) Gruss OrgFreak |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 01:52 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz