Empfehlung für SQL-Datenbank

[udo888]

Hallo,
ich werde mich demnächst von meinem seit gefühlten 100 Jahren genutzten Btrieve trennen müssen. Problem ist die neue Preisliste von Actian, in welcher für die ZEN(PSQL)-Versionen gleich einmal das 3fache auf den Tisch geblättert werden soll.

Welches SQL würdet Ihr empfehlen? Ich schreibe hier einmal ein paar Punkte auf:

- sowohl als lokaler bzw. Netzwerkserver einsetzbar
- durchaus mal über 1 Mio Datensätze je Table

- einfacher SQL-Syntax reicht
- sollte sich fluffig in Delphi einfügen
- überschaubare Kosten
- einfache Installation (sind verdammt viele Anwender)

Ich bin da sicher etwas betriebsblind, hatte in Delphi noch keine richtige SQL-Berührung.
Was würdet Ihr empfehlen, bzw. mit was habt ihr gute Erfahrungen gemacht?

Udo

[blawen]

Pers. nutze ich meistens MySQL, bzw. MariaDB.
Wenn es kostengünstig und die Performance auch gut sein muss, bietet sich MariaDB an. In diesem Zusammenhang setze ich MyDAC von Devart ein und auch hier habe ich bisher nur gute Erfahrungen gemacht.

[Medium]

Ich kann blawen hier 100% beipflichten. Sehr zügig*, und eine frische Installation ist in maximal 5 Minuten fertig zum Einsatz - vorausgesetzt man hat keine exotischeren Anforderungen, die es nötig machen in der ini zu fummeln. Für bestimmt 95% aller Fälle ist die Standardinstallation passend denke ich. Zugriff via DevArt Komponenten ebenfalls großer Daumen hoch. Kostet zwar, allerdings überschaubar, vor allem wenn man nur MyDAC statt UniDAC nimmt, wenn man eh nur auf MySQL/MariaDB zugreifen möchte.

MariaDB ist ein Fork von MySQL, der gemacht wurde bevor MySQL an Oracle verkauft wurde, und einen Lizenzirrgarten daraus gemacht hat. Es stammt vom selben Entwickler, und wird nach wie vor aktiv weiterentwickelt. Der SQL-Dialekt ist, zumindest bei allem was ich bisher brauchte, identisch zu MySQL. (Lediglich ein paar Details in spezifischen Funktionen sind hier und da anders, meist sogar mächtiger.)

*) Mein Paradebeispiel ist ein Energie-Logging Tool, das Werte von knapp 500 Messstellen pro Minute, und ca. 400 Messstellen sekündlich aufzeichnet. Durchgehend, und die sekündlichen Werte werden immer 2 Jahre vorgehalten. Eine Tabelle pro Messstelle -> über 30 Mio. Einträge jeweils allein für die sekündlichen pro Jahr. Die gesamte Datenbank ist auf der Platte rund 3TB groß. Man kann jeden der Werte, oder auch eine Range, innerhalb von wenigen Millisekunden daraus selektieren.
Okay, "die Platte" ist ein RAID 6 Verbund von 6 einzelnen HDDs, und die Tabellen sind partitioniert (eine Partition pro Jahr), sowie die Indizes passend aufgebaut. Aber zumindest letzteres ist ja normale Praxis (und wohl auch der wichtigste Teil der Optimierung). Läuft aber nun auch schon seit Mitte 2016 ohne Hardwaretausch mit dieser Performance, und die minütlichen Daten werden dauerhaft gehalten. Denke das kann sich durchaus sehen lassen.

[omnibrain]

Wenn du praktisch nur Delphi nutzt, dann schau dir mal NexusDB an. Integriert sich perfekt in Delphi. Du kannst die DB wenn du ein Stand-Alone-Programm hast als "embedded DB" nutzen, sparst dir also den Server.
Oder du nutzt den mitgelieferten (oder nach Bedarf von dir angepasste/erweiterten) Serverprozess. Entweder als "einfaches" Programm das gestartet wird oder als Windows-Service und greifst entweder lokal auf dem gleichen Computer oder über das Netzwerk zu.
In der Pro-Fassung bekommst du den kompletten Source-Code also für die Client-Komponenten und auch für den Server. Lizensiert wird pro Entwickler.
https://www.nexusdb.com/support/index.php

Falls du nicht nur Delphi einsetzt gibt es von Nexus auch einen PHP- und .Net Connector und zusätzlich von Devart einen ODBC-Treiber. Jedoch würde ich dann (insbesondere wenn noch andere Technologien dazu kommen) eher auf PostgreSQL setzen und PgDAC oder gleich UniDAC nutzen.

[haentschman]

Moin...

@TE

Am Ende des Threads wirst du nicht schlauer sein...weil jeder seine Vorlieben herausstellt. Am Ende zählt: die Anwendungsanforderung, Kosten, Installation, Wartung, Delphi Komponente. Auch eine überdimensionierte Datenbank ist schlecht. (Oracle für eine Adressverwaltung )

[meine Meinung]
Ich bin Firebird Fan , obwohl ich beruflich MSSQL benutze. (wegen Replikation).

Vorteile Firebird:
* kostenlos für immer!
1. Setup klein (25MB) und schnell installiert https://firebirdsql.org/en/server-packages/
2. mehrere Server parallel betreibbar unter verschiedenen Ports (config)
3. die Datenbank ist nur EINE Datei (nicht wie NexusDB, MSSQL, MySQL, Paradox)
4. die Datenbank ist sowohl mit dem Server als auch Embedded nutzbar (der Treiber (Hosteinstellung) gibt die Verwendung vor)
5. die Datenbank ist einfach kopierbar z.B. auf USB Stick ( sollte man aber nicht im laufenden Berieb machen (verbunde User und deren Schreibvorgänge))
6. Backup / Restore ist einfach
7. Zugriff über FireDAC(ab Enterprise für Server, sonst nur lokal), UniDAC, IBDAC, ZEOS(kostenlos)
8. Datenbank Tool: https://dbeaver.io/
9. vernünftige Dokumentation https://firebirdsql.org/en/firebird-rdbms/

...viel Spaß beim Entscheiden.


Info MySQL Lizenz Falle:

Zitat:

Eine Commercial License von MySQL wird erst dann benötigt, wenn man seine Software an dritte Verkauft und
die eigene Software sich nicht auf die GPL Licencse gründet!

https://www.delphipraxis.net/83913-m...ne-lizenz.html

Zitat:

hatte in Delphi noch keine richtige SQL-Berührung

Tipp für SQL in Delphi:
1. Verteile die Queries nicht auf die Forms.
2. Querys, und die Connection, gehören auf ein Datenmodul oder dynamisch in eine Unit. (bei mehreren Datenbanken jeweils eins, Umschaltung über ggf. Interface oder Instanz)
3. evtl. die SQL Texte nicht in der Query sondern extern in einen Ordner speichern und dann entsprechend der Datenbank der Query zuweisen. Erleichert ggf. den Umstieg auf andere Zugriffskomponenten.

[jsheyer]

Ich bin auch bekennender Firebird Fan, ich arbeite auch mit vielen anderen Datenbank Systemen, aber Firebird ist und bleibt für mich unproblematischste Datenbank und das uuch unabhängig vom OS.
Der Firebird Server läuft bei uns unter Linux, womit dann auch das OS keine Probleme bereitet.
Und wir haben Datenbanken die teilweise knapp 1 TB groß sind mit Datenmengen im Milliarden Bereich.
Und sie ist einfach super performant.
In Delphi verwenden wir auch UniDAC seit Jahren und sind absolut glücklich damit.

[MichaelT]

Ein weiser Mann spricht weise Worte. Hast schon recht.

Der BTRIEVE ist ein guter alter Record Server und das war in den 1980ern und 1990ern ein Vorteil, da man den Record einfach in ein Objekt hat reinkopiert und über Properties die Ausgabe in Richtung Delphi IDE hat einfach gestalten können. Da braucht es allein ein wenig ein Datenbank Objekt und einen Schema Generator und man bekommt den Datenbestand 1:1 konsistent in die Applikation rein gemapped. Das Zeug war sauschnell, damals bis zu 50 mit einer Warenwirtschaft, KORE und FIBU den lieben langen Tag (intensiv inkl Reporting) arbeitenden Usern und kotzte in der Praxis kaum ab, ähnlich 4th Dimension.

Firebird ist in der Praxis die 'neue' teamfähige Personal Oracle, so wie früher mit der Ampel zu starten, plus Netzwerk. Darüber hinaus geht praktisch alles mittlerweile und in der Praxis komfortabler.

Ich habe bitte einen RAC mit einer Tabelle, sorry zwei,

create table neighbors(ID integer, CALLEM varchar2(255), FK_DOSOMETHING_ID integer) mit PK usw...

Dafür aber 6 Tools at Hand inkl. Plyxon (unter Linux), Oracle SQL Developer, SQL Detective, Clear SQL (für eine procedure ADAROCKS_HOWDY(pCALLEM varchar2 .... - schwer qualitätsgesichert, Clear DB für die Schemadokumentation, PL/SQL Developer usw...

Darin sind 4 Datensätze für Hippy, Hoppy, Julian the Wise OWL und ein Satz mit CALLEM für gängige Sonderzeichen.

Ich habe lange gesucht nach einer Ablöse und am Ende blieb ein wenig unerwartet mittlerweile der Firebird.

Dort gibt es die Häschen und die Eule mit Bildern - progress on steroids usw.. Scherzerl.

Beim Firebird war der Drive die letzten Jahre gewaltig.

Mittlerweile ist Firebird die würdige Nachfolge für solche Szenarien.
Elevate DB hat auch einen Lack und
NexusDB und
Interbase (jetzt wertfrei, wenn einer unbedingt glaubt).

Elevate DB ist einfach zu administrieren und hat eine brauchbare Verschlüsselung usw. NexusDB ist runder aber kann fast zu viel an dem Eck.

Nimmt man noch PHP dazu, dann wird es mühselig. Dann rücken wieder MySQL, MariaDB und Postgres in den Fokus, mal von NoSQL DBs abgesehen.

Ich würde mir auf jeden Fall die Community rund um PHP PDO module (Treiber), .net und Java Connectoren ansehen und ODBC Treiber.

Mimer, ist aber bestimmt nicht billig, wäre die Liga SQL Server and Beyond (mittlerweile vermutlich auch nicht mehr) und praktisch SQL Anywhere on Steroids. Wohl aber hat das Self Tuning schon vor 20 Jahren an sich klaglos, im Dauerbetrieb getestet, funktioniert.

Wenn man XBASE und nicht BTRIEVE migriert gibt es zumindest Alternativen bei denen der Datenbestand übernommen werden kann.

-

Vorteil ist heutzutage, dass die Kunden für die Verschlüsselung werden gerupft und nicht für 'neue Datenbankfeature' und deren Verbesserung. Seitdem funktioniert alles halbwegs zeitnah und klaglos. Apollo bspw.

Wer über Delphi klagt, dem sei einmal Harbour empfohlen , ist zwar geil, aber ernüchternd (Clipper Compiler auf GCC).

-

Schemaänderung im Betrieb auf großen Datenbeständen bist bei Oracle und diesbezüglich war diese Datenbank schon immer segensreich und auch was Networking angeht.

-

Aber als Ablöse für Szenarien, welche sich jetzt nicht auf die eine Tabelle beschränken, ich fahre den Oracle Cluster allein zur Gaudi hoch, deswegen bleib es bei einer Tabelle oder zwei, ist Firebird am Ende der verbliebene Kandidat. Ich kenne einige die mit dem Firebird sich schon mit 1.0 rumplagten, aber die haben seitdem ganz gut immer einen positiv Zugewinn erfahren und waren am Ende immer zufrieden und wurden immer zufriedener (Linux). Der Firebird kann was es braucht.

Mein Präferenz ist so lean wie nötig und so ausbaufähig wie möglich. In Österreich haben in Ermangelung anderer Alternativen Unternehmen einfach Oracle genommen, gut lief stabil, aber da die Oracle alle nahmen (der SQL Server hieß vermutlich noch Sybase also vor 6). Hernach waren die Ablöseorgien. Mit der Zeit kamen die Unternehmen drauf, dass Oracle für 'wahre Männer' ist und der Charme der DB wurde gekonnt versteckt, aber 'Smells like the IBM Host' war eben zur Zeit des Grunges schon nicht der Teen Spirit, sondern eine Notwendigkeit. Auch wenn ich sonst über eine Oracle nichts kommen lasse. Aber die Version auf 19 raufzufahren, damit mal einmal in der DB am CLI JSON Value Repräsentationen von Werten aus Tabellen bekommt, das war vor geraumer Zeit schon ernüchternd.

Die Nische in Österreich war Oracle auf Windows NT 4 mit 7 und die Trials mit dem Nag Screen gingen weg wie die warmen Semmeln oder die anderen CDs. Durchstarten war in der Regel selten der Fall.

--

Der Firebird war schon zu Zeiten 3 Alpha, bis auf ein paar Troubles mit rekursiven Abfragen (macht eine Elevate DB nicht) und dabei die Systemgrenzen zu sprengen, von einem Freund (Waschbär) von mir die Option schlechthin. 'Weg von Oracle' für überschaubare Szenarien war vor ca. 15 Jahren angesagt.

Mit embedded Szenarien usw. nimmt sich die Sache wieder anders aus und die Lizenzen pro Arbeitsplatz, die brauchen Hersteller, liegt auf der Hand, aber tut sich keiner an. Die relationalen Datenbanken und SQL waren nicht beleibt, da SQL so super war, sondern da Abteilung für Änderungen an den Anwendungen immer fette Beträge aus ihrem Budgets mussten abdrücken. Die Daten wurden reingeklopft in der DB2 auf Files oder direkt am Fielsystem von der IT Organisation verwaltet und raus kam nichts ohne Löhnemann.

Die bekamen auf dem Wege Zugriff auf 'ihre' Daten, sonst war außer mit dem Query Management Facility nicht viel (QMF).

Zitat von haentschman:

Moin...

@TE

Am Ende des Threads wirst du nicht schlauer sein...weil jeder seine Vorlieben herausstellt.