Neue Datenbank

[Phoenix]

Wenns billig sein muss: Gefühlt würde ich im Zweifel zu MariaDB greifen (Lizenzkostenfrei, ansonsten gleicher, zum teil größerer Funktionsumfang wie MySQL).
Postgres hatte ich jetzt schon etliche Male zwischen den Fingern, und das hat bei mir jedes mal vorne und hinten geklemmt, insbesondere Performancetechnisch.

Ansonsten bin ich ein Fan vom Microsoft SQL Server. Die Express Edition ist bis 10 GB Datenmenge auch Lizenzkostenfrei, und danach kann man entweder nach Usern/Geräten (Client Access License) oder nach Kernen des Servers (ab Enterprise Version) lizenzieren.

Ansonsten bin ich da voll bei Bernhard. Wenn Du eine gescheite Middleware reinziehst, dann bist Du von dem eigentlichen System unabhängig und kannst dann je nach Bedarf beim Kunden individuell entscheiden welche DB passt.

[jobo]

ISAM und Co ist eigentlich Yesterday oder?
Ich mein, an der Problematik konkurrierender Zugriffe hat sich ja seit Jahren nichts geändert.
Warum Postgres oder mySQL oder Maria ein Problem mit SP haben sollten, ist mir nicht klar.

Zitat von Phoenix:

Wenns billig sein muss: Gefühlt würde ich im Zweifel zu MariaDB greifen

Postgres hatte ich jetzt schon etliche Male zwischen den Fingern, und das hat bei mir jedes mal vorne und hinten geklemmt, insbesondere Performancetechnisch.

Ansonsten bin ich ein Fan vom Microsoft SQL Server. Die Express Edition ist bis 10 GB Datenmenge auch Lizenzkostenfrei, und danach kann man entweder nach Usern/Geräten (Client Access License) oder nach Kernen des Servers (ab Enterprise Version) lizenzieren.

Ansonsten bin ich da voll bei Bernhard... gescheite Middleware ..

Gibt es in Maria grundlegende Unterschiede zu dem "seltsamen" Verhalten, das p80286 schon angedeutet hat?
Welche Szenarios sind den ein Performance Problem für Postgres, wenn ich fragen darf?
Die "Lizenzkosten" und sonstigen Regularien für MS SQL Server Express sind offenbar weitgehend identisch. Gibt es so auch von Oracle, ebenfalls mit den Varianten für CPU Lizensierung und per User.

Eine Mittelschicht ist nebenbei zwar elegant, aber auch ein Aufwand und Kostenfaktor.

Zitat von p80286:

Zitat von jobo:

Oracle DB ist m.E. die Mutter aller DB

Sie und ihre Schwestern wollen gepflegt werden, da reicht ein Feierabendadmin nicht aus.
..

(Wenn ich so lese wie zickig sich MySQL anstellen kann, würde ich es nicht in Betracht ziehen

"Mutter" war durchaus historisch gemeint, aber auch funktional. XML oder JSON per SQL geht nicht in jedem anderen System nach Belieben. Pflege muss wohl überall sein, nicht unbedingt nur herstellerspezifisch, sondern eher abhängig von Volumen und Nutzungsintensität. Ein 24x7 Betrieb bspw. stellt andere Anforderungen als eine Mittelständler Buchhaltung.
Von mySQL halte ich auch nicht viel, zumal es nicht nur zickig ist, sondern mittlerweile Oracle als "Stiefmutter", um bei der Wortwahl zu bleiben. M.E. betreiben die das eher als Teaser für Ihr Kernprodukt und wollten sich etwas kostenfrei Konkurrenz (Grid) vom Hals schaffen.

[mkinzler]

Zitat:

Von mySQL halte ich auch nicht viel, zumal es nicht nur zickig ist, sondern mittlerweile Oracle als "Stiefmutter", um bei der Wortwahl zu bleiben. M.E. betreiben die das eher als Teaser für Ihr Kernprodukt und wollten sich etwas kostenfrei Konkurrenz (Grid) vom Hals schaffen.

Wobei viel restriktiver als die Konkurrenz. Bzw. eigentlich keine Alternative für nicht OS-Produkte ( Kosten wie OracleDB).

[jobo]

Zitat von mkinzler:

Zitat:

Von mySQL halte ich ..

Wobei viel restriktiver als die Konkurrenz. Bzw. eigentlich keine Alternative für nicht OS-Produkte ( Kosten wie OracleDB).

Tja, wofür soll man sich entscheiden. mySQL mit Support von Oracle oder kostenlos aus der Community?
Ich nutze es nie ernsthaft, deswegen kann ich nicht sagen, wie lebendig und kraftvoll der Community Aspekt hier noch greift. Wenn Geld ausgeben, dann nicht für Oracle mySQL oder?
Kommt man in den Cluster Bereich, sieht es vielleicht noch anders aus, da wird die Luft sowieso dünn. Hab ich aber keine Erfahrung.

Zitat von MichaelT:

Ich würde mir schon auch eine Schicht dazwischen gönnen.
..
Beziehungswissen auf einer Ebene oberhalb der Tabellen ist auch im Fall von OLTP kein Schaden. Dort stellt sich wieder eher die Frage, kann 'jede' zugelassene Technologie auf die Daten schreibend und ändernd hingreifen ohne dieses informelle Beziehungswissen auszuhebeln. Aber sonst ...

Weiß nicht, ob ich das richtig verstanden habe. Aber wenn ich eine DB kastriere und sie als dummen Datencontainer nutze, muss halt die Zwischenschicht das auffangen. Wenn sie es nicht kann, habe ich ein Problem oder ich lasse es halt drauf ankommen. Eigenes Risiko.

[p80286]

Nunja unter "Datawarehousing" wird ja einiges verkauft. das funktioniert auch mit inkonsistenten Datenbanken. So ähnlich wie der Autofokus bei einer Kamera, oder besser der Verwacklungsschutz, je nach dem welche Ansprüche Du hast passt es meistens gut.

(nicht das wir uns mißverstehen, ich habe da Tools gesehen, die sind Sahhhne, vor allem um Fehler zu finden!)


Gruß
K-H

[himitsu]

Wenn man in Richtung Cross-Platform denkt, könnte man auf eine SQLite kommen, da diese bereits im Android verfügbar ist.

Was hat denn iOS ode gar OSX an Board?


Problem ist hier nur: SQLite hat nicht wirklich viele Funktionen zu bieten, aber ist dafür billig.

[mkinzler]

FireBird, PostGreSQL und MariaDB sind zwar nicht so billig aber auch kostenlos.

[MichaelT]

Die Kritik ist mehr als berechtigt.

Ich halte von Applikationsdatenpersistenz in einer DB und nur zu diesem Zwecke schlicht gar nichts. Klar ist ein abgesichertes Informationsmodell besser und Normalisierung schadet schon gar nicht.

Sobald du aber Nachrichten empfängst und Cleansing betreibst schaut die Welt anders aus und beim Staging sowieso. Auch wenn Datawarehouses oder so an Datamart angelehnte Architekturen langsam verschwinden ziehen sich diese Bausteine eher wieder ins operative Umfeld rein. Sobald du Analyse in eine Anwendung(ssystem) einbaust wirst du nicht umhinkommen eine Art Datenkrake zu gebären.

Für mich ist eine Anwendung auch nichts anders als eine Weg auf ein Informationsmodell zuzugreifen. Das wäre eher die Oracle Philosophie.

Zitat von jobo:

Weiß nicht, ob ich das richtig verstanden habe. Aber wenn ich eine DB kastriere und sie als dummen Datencontainer nutze, muss halt die Zwischenschicht das auffangen. Wenn sie es nicht kann, habe ich ein Problem oder ich lasse es halt drauf ankommen. Eigenes Risiko.

[MichaelT]

Ich würde mir schon auch eine Schicht dazwischen gönnen. Das hat sich auf jeden Fall bewährt.

Das Umfeld Datawarehousing ist mehr ein Fan von pur, aber ich habe in der Regel nicht mal Foreigen Key Contraints. Die werden auch in einem Dictionary verwaltet. Im Datawarehousing werden auch NULLs im logischen Primärschlüssel erlaubt und später ergänzt. Wir sagen, vor der nächsten Übertragung müssen Schlüssel da sein.

Oder es werden die Datensätze geprüft und in 2 verschiedene Partitionen geschrieben usw..

Beziehungswissen auf einer Ebene oberhalb der Tabellen ist auch im Fall von OLTP kein Schaden. Dort stellt sich wieder eher die Frage, kann 'jede' zugelassene Technologie auf die Daten schreibend und ändernd hingreifen ohne dieses informelle Beziehungswissen auszuhebeln. Aber sonst ...

Zitat von Phoenix:

Ansonsten bin ich da voll bei Bernhard. Wenn Du eine gescheite Middleware reinziehst, dann bist Du von dem eigentlichen System unabhängig und kannst dann je nach Bedarf beim Kunden individuell entscheiden welche DB passt.