Aufteilung über mehrere Datenbanken

Moin Moin,

neu Angemeldet und schon eine Frage.

Wir sind dabei ein etwas größeres Internetprojekt mit PHP und PostgreSQL zu erstellen.
Meine Aufgabe bei diesem Projekt ist die Administration und Bereithaltung der Systeme. Also kein Entwickler.

Unsere Vorgabe, die wir uns gestellt hatten, ein System mit 3 Datenbanken auf unterschiedlicher Hardware.
1.) Kundendatenbank mit sensiblen Kundendaten.
2.) Verkaufsdatenbank mit Material und Informationen.
3.) Videodatenbank mit Streams über Anwendung des Materials.

Nun verlangt einer der Entwickler, dass die 3 Datenbanken zu einer zusammengeführt werden sollen.
Die Begründung:
[font=&quot]- Constraints funktionieren nicht über Datenbanken hinweg[/font][font=&quot][/font]
[font=&quot]- Trigger funktionieren nicht über Datenbanken hinweg[/font]
[font=&quot]- Joins (Verbund von Tabellen bei Datenbankabfragen) funktionieren nicht über Datenbanken hinweg[/font][font=&quot][/font]
[font=&quot]- Transaktionen über Datenbanken hinweg nicht möglich[/font]


Ich, für mich persönlich habe dort ein paar Einwende:

  • Eine Kundendatenbank mit sensiblen Daten möchte ich nicht auf einem Webserver liegen haben.
  • Durch die Videostreams wird die Datenbank zu groß (ich rede hier nicht von 3 oder 4 Streams, sondern täglich ca. 10 neuen Streams).
  • Die Materialdatenbank wächst auch, es werden keine Daten eliminiert.
    Da ich kein Datenbankentwickler bin, kann ich die Begründungen des Entwicklers nicht einschätzen.
    Kann von Euch jemand sagen ob die Gründe vom Entwickler zutreffen?


    BB
    nescius
    [font=&quot][/font][font=&quot][/font]

[font=&quot][/font][font=&quot][/font]

Ja.

Andreas

Ja sagt der DB-Hilfsadmin

NJain sagt der Software-Architekt:

  1. andere hatten das problem auch
    1.1. haben das problem geloest

[font=&quot]- Constraints funktionieren nicht über Datenbanken hinweg[/font]
das ist erstmal eine korrekte aussage - aber nicht mehr wert als eine kontext-freie information … es gibt dann halt einen anwendungsfall bei dem ich auf bequeme Constraints verzichten muss …

**[font=&quot]- Trigger funktionieren nicht über Datenbanken hinweg
[/font]**das eher unrichtig - man kann v.a. in PG durchaus in trigger-funktionen auf anderen DB operieren … (kommt auf die verwendete sprache an die man in trigger-funktionen verwendet - und hier ist man ja vgl.weise frei in der wahl)
[font=&quot]
[/font]
**[font=&quot]- Joins (Verbund von Tabellen bei Datenbankabfragen) funktionieren nicht über Datenbanken hinweg
[/font]**dieses argument spielt hierbei keine rolle … du willst diesen Fall ja gerade NICHT …

anders ists bei OLAP geschichten … für statistiken … denn hier kann man sich dann ueberlegen die Daten vom Web-server in sichere Gefilde zu importieren … da darf ja dann ne wilde-sau umgebung vorhanden sein
[font=&quot]
[/font]
[font=&quot]- Transaktionen über Datenbanken hinweg nicht möglich[/font]
dein entwickler soll sich nicht so an der technischen Transaktion festbeisen … damit hat er aber auch nur teilweise recht - denn man kann z.B. ueber trigger-fkt die in fremde DBMS operieren ein gewisses mass an transaktionssicherheit erreichen … wenn das ueberhaupt in eurem speziellen anwendungsfall nötig ist

ihr solltet euch ruhig mal gedanken machen welche sachen unbedingt auf dem web-server sein muessen - welche es schoen waere dort auch zu haben (kritische daten - unter welchen bedinungen → anonymisierung ist ja auch ne moeglichkeit)

OLAP-anforderungen definieren … muss ich wirklich zu jedem zeitpunkt immer alles wissen? reicht taeglich, wöchentliche aktualisierung ? oder ist aktualisierung meiner OLAP-DB auf knopfdruck performant und elegant genug ?



sicher ist aber auch - trennen ist deutlich teurer …

Was du hier machst ist euren Entwickler übergehen.

Er hat Gründe angeführt, die offensichtlich wichtig für ihn sind und die das Zusammenführen der Daten in eine Datenbank rechtfertigen. Du hast Gründe angeführt die dagegen sprechen. Jetzt steht bei euch Notwendigkeit gegen Vorgabe.

Wie wäre es, wenn ihr euch zusammen an einen Tisch setzt und erst mal herausfindet, was ihr effektiv von den Vorgaben braucht? Wen ihr damit fertig seid, können wir wieder weiterhelfen und schauen, wie man die dann auftretenden Probleme lösen kann.

Hallo ads,

wieso übergehe ich den Entwickler???

Um ein Gespräch führen zu können, benötigt man Informationen.
Ansonsten kann ich mich auch an den Tisch setzen und Wackeldackel spielen.
Ich misstraue dem Entwickler auch nicht, ich würde nur gerne aus einer anderen Quelle erfahren ob seine Behauptungen plausible sind.
Was mich stutzig macht, das Projekt läuft schon seit 1,5 Jahren.
Jetzt wo es in die heiße Phase geht, wird das besprochene Konzept über den Haufen geworfen.
Da stellt sich mir die Frage: Warum ist diese wichtige Information nicht früher auf den Tisch gekommen?


BB
nescius

Das sind alles Fragen, die ich an deiner Stelle dem Entwickler stellen würde.

Entweder er kann sie vernünftig beantworten oder ihr habt sowieso ein Problem in dem Projekt.

Bis jetzt hören sich die Argumente nach Standardargumenten an. Allerdings sind das auch nicht umsonst Standardargumente: man geht normalerweise so vor, daher ist das auch zum Standard geworden. Aus diesen Aussagen und ohne ein genaueres Wissen zum Projekt kann man an dieser Stelle wohl nicht sagen welche Aussagen nun wirklich notwendig sind.

Was dein Entwickler sagt ist richtig, was du sagst aber auch. Ihr schaut beide aus verschiedenen Blickwinkeln auf die gleich Sache. Die Argumente, die dein Entwickler bringt sind sicher hinderlich für seine Arbeit. Was er will, macht ihm das Leben leichter und das Gesamtkonstrukt konsitenter. Das sind aber normalerweise nicht die einzigen Argumente. Eine Kundendatenbank mit sensiblen Daten würde ich auch nicht auf den Webserver stellen (ich hab hier demnächst ein ähnlich gelagertes Problem). Auf jeden Fall solltet ihr beide euch an einen Tisch setzen und das ganze genau abklopfen. Aber das scheint ja in eurem Projekt schon länger nicht geschehen zu sein, wenn das schon 1,5 Jahre so geht ist noch was anderes faul (wo weder du noch der Entwickler was dafür können :wink: )

CU Uwe

Eindeutige Antwort: Mieses Projektmanagement

Man darf zwar von Entwicklern erwarten, dass sie auf Anforderungen eingehen - aber man muss auch wissen, dass Durchschnitts-Entwickler diese auch gern ignorieren … wie Gisman schon sagte - weils ja mit Arbeit verbunden wäre - oder aber auch (das meine ich) man damit Überfordert ist. “Überfordert” nichtmal technischer Natur - sondern einfach, weil der Entwickler mit wichtigen Entscheidungen allein gelassen wird - oder ihm die nötigen Informationen einfach verweigert werden → z.B. was darfs denn kosten.

Wenn irgendwie 1,5 Jahre ins Land gegangen sind, und solch - wie du blicken lässt - essenzielle Randbedingungen auf der Strecke blieben, dann ist “Der Entwickler” sicherlich NICHT der Erste den man rügen sollte.

das schoene an vielen involvierten - bei solchen projekten - ist, dass am ende ja niemand was dafuer kann :slight_smile: besonders wenn zwischendrin die primär verantwortlichen (strippenzieher) mehrfach zum stuehlerücken antraten …

das bloede bei dieser geschichte hier ist, dass die beschriebenen rahmenbedingungen von essenzieller bedeutung fuer die gesamtarchitektur sind. Die zieht man nicht eben mal einfach nach - die wahrheit heisst da wahrscheinlich “neu bauen” oder “akzeptieren das es nicht so ist” …

noch ein paar andere Fakten - zu deinen konkreten Punkten - die vielleicht wieder andere Ansichten ermöglichen

\

  • Eine Kundendatenbank mit sensiblen Daten möchte ich nicht auf einem Webserver liegen haben.

Ein Web-Portal, welches ermöglicht, dass Kunden sich registrieren, anmelden, Vorgänge auslösen können - hält IMMER kundendaten in einer Kundendatenbank vor -> “auf” dem Webserver / vom Webserver erreichbar.

  • Durch die Videostreams wird die Datenbank zu groß (ich rede hier nicht von 3 oder 4 Streams, sondern täglich ca. 10 neuen Streams).

Ein Webserver ist erstmal eine Logische Instanz … also ein Stück Software … “Gross” und “Klein” sind in der Sofwarewelt relativ. Wenn du von 10 Streams täglich ausgehst, dann ist das eine Hochrechnung, die in eine Anforderung an die Infrastruktur münden sollte (Plattenkapazität / Bandbreite), und als zweites an den Entwickler (Optimierung->Performance->Leistungstests / Skalierung). Auch diese Streams müssen vom Web-Server erreichbar sein.

  • Die Materialdatenbank wächst auch, es werden keine Daten eliminiert.

Auch hier gilt das gleiche wie bei den Streams … du musst wissen, wofür die geschichte Ausgelegt ist und wie sie skalieren soll.

Entweder man ist sich zu Anfang des Projektes über die Grenzen im Klaren - oder man erlaubt es sich, darüber nicht im Klaren zu sein, dann sollte man sich aber den Luxus gönnen und dafür sorgen, dass die Lösung gute Skalierungseigenschaften hat - also auch “mit ein paar Kunden mehr” gut zurecht kommt. (oder mehr “Material” was immer du damit auch meinst)

Es ist ja nicht so das wir beide alleine an einem Tisch sitzen,
immerhin sind noch 2 weitere Entwickler dabei.
Wobei ausgerechnet der, der die Datenbank erstellt und einrichtet,
sich nicht zu Wort meldet.
Der Entwickler, der die Einwände hat, schreibt die PHP Skripte.
Bei den bis jetzt im Forum gegebenen Antworten, sieht man auch das es Probleme bei mehreren Datenbanken geben kann.
Die Entscheidung über eine einzelne Datenbank oder nicht, fälle ich sowieso nicht. Jetzt ist bei mir nur die Akzeptanz für eine einzelne Datenbank weitaus höher.

BB
nescius

Beruhend auf welchen Argumenten?

Den muss die potentielle Verteilung ja auch nicht installieren - wenn ihr ihm sagt erstelle 3 Datenbanken mit den Modellen 1, 2 und 3 - dann macht der das.

Der Entwickler, der die Einwände hat, schreibt die PHP Skripte.

Verständlich, der ist ja auch “der Arsch” der die Probleme der Verteilung lösen muss. Und so wie sich das anhoert ist er auch der, welcher die Datenstrukturen umsetzen muss (Modell) … die Admin-arbeit oben ist zwar auch nicht zu unterschaetzen aber bei weitem nicht derart Komplex.

Wahrscheinlich muss der “arme” PHP-Typ sich auch noch mit dem Streaming beschaeftigen :slight_smile:

Moin,

Also ich habe lange Zeit mit diversen Datenbanken
(nicht nur mit Postgres) zu tun gehabt und kenne mich
auch in der Materie in der Du Dich bewegst etwas aus
(vom Entwicklerstandpunkt).

Von daher rate ich Dir ab so ein Projekt mit Postgres
zu versuchen. Der Grund ist folgender:Postgres ist eine
hervorragende Transaktionsdatenbank die auch bei
grösseren Textmengen nicht schlapp macht. Bei
extrem grossen Binaries in oder um die Datenbank
herrum oder sogar mehrere gesplittete Datenbanken
die im Grund zu einer Applikation gehören, die im
Nachhinnein, also quasi im laufenden Betrieb wartbar,
optimierbar und ergänzbar sowie Partitionierbar bleiben
soll empfehle ich Dir ganz klar die ORACLE Enterprise
Edition.

Klar kostest die Lizenz einiges, aber diese Datenbank
ist genau für solche Einsatzzwecke vorgesehen:

-Riesige Terrabyte und Exobyte Mischdatenmengen.
-Hochverfügbarkeit und Wartbar/Erweiterbar im Betrieb
-Integrierter Web-DB-Streamingserver (Video/Audio)
-Unterstützt riesige grosse Binärobjekte innerhalb der DB
-Datenbanken können netzverteilt angelegt werden.
-Online Permamentbackup via GUI-Operationsmanager
-Auf vielen Betriebssystemen verfügbar (SUN empfohlen)
-Skaliert sehr gut auf Bigiron Hardware bei vielen CPU’s

Natürlich kann man das auch alles mit Postgres machen,
nur musst Du dann beim Design des Gesammtsystens
viele wichtige Dinge beachten (gerade im Bereich der Skalierbarkeit). Besonders beim OS und vielen großen Dateiobjekten ausserhalb der Datenbank, die jedoch
in Kreuzbeziehung zu Tabelleninhalten stehen ist besondere Vorsicht geboten. Hier kann schon das
genutzte Dateisystem des OS ein Problem werden.
Wirf mal einen Blick auf Sun’s ZFS, sieht sehr vielversprechend aus und harmoniert recht gut
mit Postgres, besonders bei großen Datenmengen,
RAID und Plattenplatzerweiterung im laufenden Betrieb.