Neue Datenbank

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

Zitat von Phoenix (Beitrag 1366246)

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]

Zitat:

Zitat von mkinzler (Beitrag 1366273)

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:

Zitat von MichaelT (Beitrag 1366274)

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. :stupid:

[mkinzler]

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

[bra]

Wichtig ist vielleicht auch noch, wie die Performance der Server aussieht. Wir haben verschiedene Kunden mit Firebird und MSSQL-Server im Einsatz und haben die Erfahrung gemacht, dass Firebird leider sehr festplattenlastig ist. Sprich, wenn der Server langsame Festplatten hat, bricht die Performance bei Firebird massiv ein. Bei MSSQL ist das nicht so der Fall, der krallt sich dafür mehrere GB RAM.

[jobo]

und SQLite ist zwar ziemlich billig aber nicht ziemlich schnell
(was man so hört, - ist mir noch nicht aufgefallen)
Wenig Funktionen macht wierderum nichts, wenn man sowieso eine schlaue Zwischenschicht einsetzt.

Mit einer 5D Matrix bekommt man vielleicht die wichtigsten Kriterien in den Griff. Oder der TE rückt noch mit einigen Vorgaben raus.

[Bernhard Geyer]

Zitat:

Zitat von bra (Beitrag 1366286)

... Bei MSSQL ist das nicht so der Fall, der krallt sich dafür mehrere GB RAM.

Und? Wenn man bei einer 150 GB Datenbank z.B. 30 GB RAM für den Server vorsieht. ist das in 2017 noch ein nennenswerter Kostenfaktor wenn dafür das DB-System gegenüber 8 GB RAM 100fache Leistung bietet da alle relevanten Indexe komplett im RAM vorgehalten werden könnne?

[Neutral General]

Zitat:

Zitat von jobo (Beitrag 1366287)

und SQLite ist zwar ziemlich billig aber nicht ziemlich schnell
(was man so hört, - ist mir noch nicht aufgefallen)
Wenig Funktionen macht wierderum nichts, wenn man sowieso eine schlaue Zwischenschicht einsetzt.

Umso mehr diese schlaue Zwischenschicht allerdings emulieren muss, desto langsamer wird das ganze nochmal.

[jobo]

Zitat:

Zitat von Neutral General (Beitrag 1366289)

Umso mehr diese schlaue Zwischenschicht allerdings emulieren muss, desto langsamer wird das ganze nochmal.

Also ich bin kein Freund von Zwischenschichten, ich mag klassische CS Welten.
Erfahrungsgemäß bekommt die Zwischenschicht einen Loadbalancer und dann wird halt soviel Hardware gekauft/gemietet, bis der Kunde nicht mehr meckert.
Und hinten dran schnelles NoSQL.
Wie auch immer, es gibt so viele Szenarien, ich glaube nicht, dass man das seriös alles gegeneinander stellen kann.