ich spiele momentan mit dem Gedanken eine bestehende relationale DB von uns neu aufzusetzen. Denn die Technologie dahinter ist zu alt (langsam/kein Support etc.) und erfüllt die Anforderungen nur mangelhaft.
Es muss zwingend so aufgebaut werden, das mehrere Leute an der DB zeitgleich verschiedene Datensets bearbeiten können.
(optional) Es wäre auch gut, wenn möglich, wenn man die DB Technolgie möglichst abgekapselt bekommt. So das man relativ leicht die Datenbanken-Technologie austauschen kann, ohne das es die Clients mitbekommen.
Die Frage die sich mir stellt, gibt es dafür bereits gute Lösungen auf dem Markt, oder wird das darauf hinaus laufen, dass man sich einen eigenen Server bastelt?
das können die meisten RDBMS, Ausnahme sind IME sog. „in-memory DBs“, aber auch da gibt es Ausnahmen
Ja ne is klar, das ist Aufwand, Flexibilität bringt Komplexität.
IMO PostgresSQL nehmen und gut ist, jeder Wechsel ist Aufwand, wenn man von Anfang an Aufwand will (wegen der Flexibilität), braucht man eben eine Abstraktionsschicht
Das ist natürlich Aufwand, aber durch eine geeignete Architektur ist der Aufwand stark reduziert. Hexagonale Architektur hilft hier z.B.
Wobei nach „Austauschbarkeit“ immer gerufen, aber selten wirklich genutzt wird.
Empfehlung von mir wäre auch eine PostgreSQL. Die ist schnell und auch als Dienst bei AWS (und anderen) kaufbar.
Dokumenten-DBs würde ich nur empfehlen, wenn der Bedarf nach schemalosen Strukturen besteht. Migration ist da immer sehr individuell.
Ich kann @anon2594669 und @maki da nur zustimmen. Die Austauschbarkeit bekommt man nicht geschenkt, sondern muss einen Abstraktionslayer einplanen. Eine hexagonale oder Onionarchitektur unter Verwendung von Repositories sorgt schon einmal für Austauschbarkeit. Allerdings auch nur dann, wenn man komplett von der Persistenz abstrahiert. Es verbietet sich dann, JPA-Entities innerhalb des Domain-Layer zu verwenden (würde ich auch dringend empfehlen. Gefühlt geht gerade sowieso ein Trend weg von JPA hin zu leichtgewichtigeren Lösungen wie jOOQ oder frameworkgestütztem JDBC-Datenbankzugriff).
Wenn man sich auf JPA festlegt, kann man mittels hibernate oder einer anderen JPA-Implementierung recht einfach die Datenbanktechnologie wechseln. Das passiert, wie aber schon erwähnt, eher selten und zumeist aus lizenzrechtlichen / preislichen oder firmenpolitischen Gründen. Und das geht auch nur dann ohne Zusatzaufwand, wenn man auf jegliche Extra-Features verzichtet, die ein spezielles RDBMS anbietet, welche ggf. die Anwendung entlasten würden.
Auch mein Vorschlag wäre eine PostgreSQL. Die hat ein sehr schönes Featureset, ist kostenfrei und skaliert sehr gut.
Insgesamt wäre der bereits vorhandene Techstack natürlich für die Einordnung noch interessant.
Wie auch von Martin erwähnt, was wird denn aktuell benutzt?
Auf Austauschbarkeit würde ich scheißen, wenn es nicht explizit ein erwartbarer Punkt wird. Weil bis auf kleine Anpassungen im Code (native Queries) werden die meisten Sachen bei allen relationalen Datenbanken laufen.
In meinen Augen gibts da auch die große Frage, was darfst du einsetzen? Oftmals gibts dort auch vorgaben und sonst würde ich hier der Mehrheit zustimmen und Postgres nutzen.
Edit: ach „langsam“ wenn ihr nicht gerade eine extrem krude DB benutzt wage ich zu behaupten dass es an eurem DB Design liegt und nicht an der Software
Der Grund für die (optionale) Austauschbarkeit ergab sich darin, dass die jetzige Datenbank damals einfach von vorgestern auf gestern keinen Support mehr bekommen hatte und kein aktuelles OS wird heute offiziell noch unterstützt. Das ist problematisch, weil darauf viele Programme operieren die angepasst werden müssen wenn man die DB ändert und das wird Auswirkungen haben. Wenn das nicht so einfach geht, dann verfällt der Punkt auch.
Das es langsam ist ergibt sich neben dem alter auch schon alleine daran, das es ziemlich dämlich ist jedes mal direkt auf die DB über das Netzwerk zuzugreifen. Hier braucht es dringend einen Server der die Anfragen lokal verarbeitet und eine Art User Management übernehmen kann so dass mehrere Programme und Nutzer gleichzeitig darauf lesen und editieren können. Mit editieren meine ich nicht ein Lock pro Tabelle sondern pro Reihe bzw. eigentlich sogar ein bisschen komplizierter als das.
Das ist doch schon mal ein fantastischer Vorschlag. Dadurch das es OpenSource ist, halte ich es auch für schwierig vorstellbar das ein Unternehmen von heute auf morgen den Support kündigt.
Es handelt sich momentan um eine relationale DB. Wobei die Überlegung der Sinnhaftigkeit schon da ist, nicht doch auf eine OO DB zu wechseln, da die Datenstruktur am Ende sowieso OO ist. Wobei ich schon sehr viele Stimmen gehört habe die davon abraten und lieber zum Zusatzaufwand raten das händisch zu übersetzen.
Ich kenne mich nicht genügend mit dem Thema aus. Aber wenn ich jetzt eine DB habe in der ein 100.000 Personen gespeichert sind, und ich möchte eine Liste mit dem Vornamen aller Personen, wird eine relationale DB schon besser sein, oder was können OO DBs so?
Eine Art SQL DB. Programmiersprachen: Alle. Frameworks: Keine.
Das bedeutet, dass es nicht nur die eine Anwendung gibt, der die Datenbank exklusiv gehört, sondern mehrere Klienten?
Für die Postgres kann man von diversen Anbietern Support kaufen, falls das relevant sein sollte. Die Postgres wird auch in den nächsten Jahren nicht sterben, weil die Nutzerbasis und auch die Community mit viel zu groß sind.
Ja, vor allem Postgres ist sehr weit verbreitet, nicht nur Doku im Netz, gibt auch spezialisierte Profis für die als Consultants kommen und analysieren/beraten/optimieren, aber nicht mit PowerPoint
Vor- und Nachteile vom Locking sind ja bekannt, weiss jetzt nicht was Postgres da unterstützt auf Record Ebene bzw. „drunter“.
Dass das Code-Modell ein Objektmodell ist, sollte nicht der ausschlaggebende Punkt sein, eine Objekt- oder Dokumentendatenbank zu verwenden.
Wenn Du ein festes Schema hast, dann ist eine relationale Datenbank der richtige Weg. Ein Schema kannst Du dann einfach mit Flyway oder ähnlichen Tools anpassen. Das geht bei einer Objekt- oder Dokumentendatenbank nicht so einfach. Ändert sich also irgendwie ein Feld, dann musst Du Dir einige Gedanken machen, wie Du die Datenbank oder Deinen Code anpasst.
Ich habe mir ein paar der hier genannten Optionen durchgelesen. Was mich etwas irritiert, ist dass das User Management bei allen immer auf SQL Ebene umgesetzt wird (Locks), on Disk, und dass sich der Client um die Synchronisation kümmern muss (da schaudert es mir). Da wir keine volle Kontrolle über alle Clients haben, sehe ich das als großes Problem um irreversiblen Schaden durch schlechte Qualitätskontrolle anzurichten.
Um so mehr irritiert mich das ganze, weil z.B. PostgreSQL durchaus einzelne User und Usergruppen unterscheiden kann und theoretisch sich auch auf der Ebene darum kümmern könnte.
Ich vermute es führt damit kein Weg daran vorbei, den DBMS Server selbst wiederum zu wrappen um ein gescheites Multi User Management zu garantieren.
Ich hab nur „Lese“ Erfahrung mit SQL DBs. Also nicht viel. Vielleicht übersehe ich gerade auch etwas nur.
MongoDB fand ich eigentlich sogar sehr interessant was ich so gelesen habe. Da die Einträge in der DB über mehrere Tabellen verteilt sein werden (Objekte enthalten one-to-many Objekte) stelle ich mir das leichter vor zu locken in einem Dokumentenbasierten System.
Leider ist die MongoDB nicht mehr OpenSource, und wir wollen auch keine DBMS in der Cloud kaufen, sondern intern für uns. Das ist halt das Problem, wir sind kein echter Kunde für DB Anbieter in einer Welt der Webservices.
User in der DB haben nix mit deinen Usern zu tun!!!
Das kannst du so betrachten, du legst ja auch nicht für jeden User der deinen Webservice nutzt einen User aufm System (OS) an
Ich lehne mich mal weit ausm Fenster und behaupte deine User und deine Art und Weise der Datenzugriffe interessieren die DB gar nicht und haben sie auch wenig zu interessieren. Das muss alles deine Anwendung machen
Ich hatte es oben schon angedeutet und sehe mich in diesem Beitrag noch einmal bestätigt. Es ist also so gedacht, dass mehrere Anwendungen sich die Datenbank teilen. Das ist das problematischste aller Szenarien und wird „heutzutage“ auch vermieden, wo es geht. Stand der Technik ist es, die Datenbank einem Service exklusiv zur Verfügung zu stellen und alle Zugriffe auf die Datenbank durch diesen Service zu leiten.
Nichtsdestotrotz kann Postgres (und auch die meisten anderen RDBMS) Berechtigungen auf Inhalte sehr feingranular reglementieren. Man kann so weit gehen, dass sogar Tabellenzeilen nur durch bestimmte Nutzer gelesen werden können (abhängig von darin stehenden Werten), Spalten ausgeblendet werden oder aber auch ganze Tabellen und Namespaces reglementiert werden. Rechtemanagement ist in mindestens den Dimensionen Lese-, Schreib- und Löschzugriff möglich, hört dort aber nicht auf, sondern geht weiter über Berechtigungen zur Schemaveränderung und auch spezielle Berechtigungen zum Ausführen von stored procedures etc. pp…
Dieses Szenario erfordert einen guten DBA. Der größte Nachteil daran ist, dass man sein Datenbankschema „auf ewig“ festlegt, weil man keine Abstraktionsschicht mehr hat, die Schemaveränderungen zulassen würden. Eine Schemaveränderung würde nämlich alle Drittanwendungen brechen lassen, sofern man die Kompatibilität nicht wahrt. Vermutlich ist dieses Argument auch das, weshalb man heutzutage nur noch in seltenen Ausnahmen direkten Zugriff auf die Datenbank erlaubt (notwendige Legacyanwendungen).
Dann gibt es noch den Berechtigungslayer, der innerhalb der Anwendung greift. Den meintest du vermutlich mit „man muss sich selbst um die Synchronisation kümmern“. Das ist Anwendungslogik und die kann einem die Datenbank nicht abnehmen. Und eine Anwendung kann unsicher implementiert sein und sich nicht an Standards halten. Das kann man nur vermeiden, indem man den Zugriff auf die Daten durch eine eigene Anwendung reglementiert.
Für 5 User wirds schon reichen.
