Empfehlung für SQL-Datenbank

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

[TigerLilly]

Ich würde gern MSSQL Express ins Spiel bringen.
https://www.microsoft.com/de-de/down...aspx?id=104781

- Installiert in 99% der Fälle problemlos
- Verwaltungstool inkludiert
- hoch performant + skalierbar
- als Einzelplatz und als Server einsetzbar
- kostet nichts

Wir nutzen das seit vielen Jahren für unterschiedlichste Zielgruppen und hatten noch nie das Gefühl wechseln zu müssen.

[Phoenix]

Also der aktuelle "Industriestandard" ist meines erachtens PostgreSQL.

MySQL / MariaDB sehe ich schon seit vielen Jahren nicht mehr produktiv im Einsatz - bei keinem unserer Kunden. Der Grund ist, das MariaDB eher "leichtgewichtiger" ist. Eigentlich gut, aber bei größeren Datenbanken macht Maria dadurch dann irgendwann die Grätsche und bricht komplett ein. Also kleine DB: MariaDB, größere DB's: Was "richtiges".
Oracle ist Lizenztechnisch und handhabungsmäßig ne Vollkatastrophe.
Microsoft SQL Server ist gut und benutze ich auch gerne, aber die Express-Edition ist zu eingeschränkt und bei der richtigen Variante hast Du wieder das Lizenzkostenproblem. Zudem gibt es hier für ARM-Hardware (noch?) keine gescheiten Images.
Firebird ist halt eher eine Nischen-DB, die nahezu ausschließlich im Delphi-Umfeld genutzt wird.

Das ist per se natürlich nicht schlecht, aber daraus ergibt sich, dass die Community die Dir hier helfen kann leider sehr überschaubar ist. Postgres kennt da draussen nahezu jeder, der aktuell irgendwas mit hochperformanten Datenbanken machen muss. Dementsprechend gibt's dort für alle erdenklichen Situationen schon Artikel und fertige Lösungen.

Dazu kommt, das PostgreSQL auch neben dem primären Relationalen Modell auch (ggf. mit extensions) Support für Document-Store (no-sql), Graph-DB, Spatial DB's (Geo-Daten / Koordinaten), und auch Vektor-Storage hat (und das wird aktuell immer wichtiger für performante semantische Suchen).

Ich würde an Deiner Stelle einfach mal von allem was in die nähere Auswahl kommt eine DB in einem Docker Container hochfahren, deine Daten da reinschieben, und dann gucken wie sich das jeweils anfühlt und wie das performt.

[Lemmy]

Hi,

sorry, für die Zwischenfrage:

Zitat von Phoenix:

MySQL / MariaDB sehe ich schon seit vielen Jahren nicht mehr produktiv im Einsatz - bei keinem unserer Kunden. Der Grund ist, das MariaDB eher "leichtgewichtiger" ist. Eigentlich gut, aber bei größeren Datenbanken macht Maria dadurch dann irgendwann die Grätsche und bricht komplett ein. Also kleine DB: MariaDB, größere DB's: Was "richtiges".

das mit der Größe ist mir neu. Hast Du da Erfahrungswerte? Geht es dabei um die Gesamtgröße der Datenbank oder um die Datenmenge einzelner Tabellen? Hast Du da, wenn auch nur gefühlt, irgendwelche Größenangaben noch im Kopf?
Und wird die DB damit langsamer oder fährt die mit Fehlern gegen die Wand?

Grüße

[himitsu]

Nja, für "Größeres" lohnt es sich ja eh oft einen richtigen DB-Server aufzusetzen.

Da ginge dann auch PostgreSQL

[TigerLilly]

Zitat von Phoenix:

Microsoft SQL Server ist gut und benutze ich auch gerne, aber die Express-Edition ist zu eingeschränkt und bei der richtigen Variante hast Du wieder das Lizenzkostenproblem. Zudem gibt es hier für ARM-Hardware (noch?) keine gescheiten Images.

Naja, "eingeschränkt" muss man schon relativieren:
https://www.software-express.de/hers...nen-vergleich/
Wenn einem da etwas fehlt, ist man mit "überschaubare Kosten" eher falsch aufgestellt.

2019 und 2022 Express laufen auf ARM ohne Probleme, zumindest "within a Windows 11 on ARM installation in Parallels on Apple Silicon Macs".

[johndoe049]

Viele Kunden von uns fordern bei Datenbanken eine Vollverschlüsselung incl. Suchhfähigkeit innerhalb der Datenbank. Nicht nur in der Verbindung vom Client zur Datenbank.

Wir nehmen daher ElevateDB und bei einigen Kunden, die das so unbedingt haben wollen, auch mal SQL Anywhere.

[himitsu]

PS: https://db-engines.com/de/ranking

[Phoenix]

Zitat von Lemmy:

das mit der Größe ist mir neu. Hast Du da Erfahrungswerte? Geht es dabei um die Gesamtgröße der Datenbank oder um die Datenmenge einzelner Tabellen? Hast Du da, wenn auch nur gefühlt, irgendwelche Größenangaben noch im Kopf?
Und wird die DB damit langsamer oder fährt die mit Fehlern gegen die Wand?

MySQL / MariaDB hat gewisse Probleme mit dem Index-Management. Das macht das ganze dann leider immer langsamer bis hin zu absolut nicht mehr akzeptablen Query- und Insert-Zeiten.

Eine Tabelle > 1 Mio Rows braucht Aufmerksamkeit was die Indices angeht, aber das kann man noch irgendwie handeln.
Mehrere Tabellen mit jeweils > 1 Mio Rows wirst Du definitiv an der Performance merken, da kannst Du mit den Indices machen was Du willst. Selbst wenn die DB eigentlich komplett in-Memory passen dürfte.

Ab dann sollte man sich Gedanken machen, einen Plan B in der Tasche zu haben.
Das kann z.B. sein, alle älteren Datensätze einfach in Archiv-Tabellen zu schieben damit die Live-Tabellen nicht so viele Einträge halten müssen, aber das ist alles Aufwand der mit einer besseren DB nicht sein müsste.

[Lemmy]

Servus,

Zitat von Phoenix:

Zitat von Lemmy:

das mit der Größe ist mir neu. Hast Du da Erfahrungswerte? Geht es dabei um die Gesamtgröße der Datenbank oder um die Datenmenge einzelner Tabellen? Hast Du da, wenn auch nur gefühlt, irgendwelche Größenangaben noch im Kopf?
Und wird die DB damit langsamer oder fährt die mit Fehlern gegen die Wand?

MySQL / MariaDB hat gewisse Probleme mit dem Index-Management. Das macht das ganze dann leider immer langsamer bis hin zu absolut nicht mehr akzeptablen Query- und Insert-Zeiten.

Eine Tabelle > 1 Mio Rows braucht Aufmerksamkeit was die Indices angeht, aber das kann man noch irgendwie handeln.
Mehrere Tabellen mit jeweils > 1 Mio Rows wirst Du definitiv an der Performance merken, da kannst Du mit den Indices machen was Du willst. Selbst wenn die DB eigentlich komplett in-Memory passen dürfte.

Ab dann sollte man sich Gedanken machen, einen Plan B in der Tasche zu haben.
Das kann z.B. sein, alle älteren Datensätze einfach in Archiv-Tabellen zu schieben damit die Live-Tabellen nicht so viele Einträge halten müssen, aber das ist alles Aufwand der mit einer besseren DB nicht sein müsste.

Danke für die Info. Da habe ich dann was zu tun