it-swarm.com.de

Eine Datenbank für mehrere Anwendungen?

Hat jemand in einer Umgebung gearbeitet, in der sich mehrere interne Anwendungen unter einer Datenbank befinden und jede Anwendung ein eigenes Schema in dieser einzelnen Datenbank hat? Ich meine nicht nur ein paar kleine, verwandte Anwendungen in einer Datenbank, sondern wie voll auf eigenständige Anwendungen, die mit anderen eigenständigen Anwendungen in eine Datenbank gestellt werden.

Ich habe es mit einer Architektur wie dieser zu tun, die lange vor mir eingerichtet wurde, und ich versuche zu argumentieren, dass eine neue eigenständige Anwendung in eine eigene separate Datenbank gestellt werden sollte, aber mir wird im Grunde gesagt, dass dies "alles in einer zusammenfasst" Datenbank "Architektur ist sinnvoller als eine separate Datenbank und ich bin irgendwie ratlos, was ich überhaupt sagen soll. Ich habe das Gefühl, dass ich im Internet nicht viele Informationen dazu finden kann, weil sonst niemand mehrere Anwendungen wie diese in eine Datenbank stellt, aber vielleicht irre ich mich völlig?

Ich arbeite mit Microsoft SQL Server- und .NET-Webanwendungen.

7
Kevin

Ja, ich habe in einer ähnlichen Umgebung gearbeitet.

Der Unterschied zwischen einem Schema und einer Datenbank ist aus Anwendungssicht nicht sehr groß. Schließlich werden alle Datenbanken auf einem Server auf demselben Server ausgeführt. Ich würde es nicht schwitzen.

Das Wichtigste ist, dass Sie eine Trennung zwischen den Tabellen beibehalten und nicht einen Satz auf einen anderen verweisen oder Abfragen haben, die sich über Domänen erstrecken.

Ich würde das DB-Setup den DBAs überlassen und nur sicherstellen, dass mein SQL gut ist.

7
Ewan

Zusamenfassend

Ich habe in beiden Umgebungen gearbeitet. Ich war ein bedingungsloser Befürworter des Shared-DB-Ansatzes. Ich habe einige Zeit gebraucht, um die Einschränkungen zu erkennen und zu überdenken: Stellen Sie es sich nur für eng verwandte Anwendungen vor, die im selben begrenzten Kontext arbeiten .

Im Allgemeinen funktioniert die Shared-DB sehr gut. Wie COBOL-Programme vor ihnen. Und wie sie lassen sie uns Daten immer noch als etwas Passives betrachten, das darauf wartet, von einer Software verarbeitet zu werden, die weiß, wie man damit umgeht (und das wird es richtig machen). Single-DBS haben den Vorteil, dass Anwendungen Unternehmensdaten gemeinsam nutzen können. Genau so, wie globale Daten von verschiedenen Modulen gemeinsam genutzt werden.

Die moderne Softwareentwicklung hat uns jedoch gelernt, Module zu kapseln, globale Daten zu vermeiden und den Weg zu gehen OO: Daten sind nur zusammen mit dem Code sinnvoll, der sie zuverlässig verarbeiten kann. Warum ignorieren wir sie weiterhin? diese Prinzipien auf Datenbankebene?

In langer Zeit

Das Graal der einzelnen Unternehmensdatenbank

Single-DB funktionieren sehr gut, weil in einem Unternehmen alle Aktivitäten irgendwie miteinander verbunden sind. Das ist das Prinzip vieler führender ERPs. Wenn Sie alles in einer Datenbank haben, können Sie verschiedene Anwendungen ganz einfach in Echtzeit integrieren.

Leistungen:

  • Reduzierte Betriebskosten
  • Möglichkeiten zur Neugestaltung von Prozessen: Alle Daten sind vorhanden; Sie können also die Funktionalität zwischen den Anwendungen neu verteilen.
  • Gelegenheit zur Rationalisierung des Datenbankdesigns: Ende der 80er Jahre Anfang der 90er Jahre habe ich einige Zentralisierungsprojekte mit einer beeindruckenden Reduzierung der Anzahl von Anwendungssoftware (insbesondere ETL-/Schnittstellenprogramme) erlebt.
  • Synergien: Verschiedene Teams teilen die gleichen Fähigkeiten und können Ideen austauschen, indem sie ihr DB-Schema kommunizieren.

Risiken und Nachteile:

  • Der Erfolg hängt von der Fähigkeit ab, das DB-Schema aus einer globalen Perspektive über die Domänen hinweg zu entwerfen. Wenn jeder weiterhin eine Sandburg in seinem eigenen Namespace baut, haben Sie die Unannehmlichkeiten der globalen DB ohne die meisten ihrer Vorteile.
  • Starke Kopplung der Komponenten: Sie können eine Anwendung nicht mehr in einem anderen Kontext (einer anderen Site, einem anderen Unternehmen) wiederverwenden, da Daten mit vielen anderen Apps verflochten sind.
  • Unbekannte Abhängigkeiten: Da alles in einer Datenbank verknüpft ist und der Zugriff auf eine Tabelle in einem anderen Schema/Namespace einfach ist, sind die Abhängigkeiten nicht klar. Dies hat natürlich Auswirkungen auf die Organisation von Entwicklungen: Sind Sie sicher, dass einige von Ihnen getestete DB-Tabellen nicht von einem Entwickler einer anderen App geändert wurden? Wie organisiere die DB-Evolution ?
  • Ein schlecht benommenes Programm kann zu Inkonsistenzen in der gesamten Datenbank führen
  • Die Skalierbarkeit wird letztendlich durch die Skalierbarkeit Ihrer DB-Engine eingeschränkt.
  • Verlangsamung der Innovation, teilweise aus Angst? Aufgrund der unbekannten Abhängigkeiten ziehen es SW-Ingenieure meistens vor, eine funktionierende Produktionsdatenbank nicht zu berühren.
  • Vendor Lock in?

Aber sind wir jetzt nicht in einer anderen Welt?

Heutzutage geht der Trend dahin, den Monolithen zu meiden und flexible, sich entwickelnde und skalierbare Architekturen zu konzipieren:

  • In unserer internetbewussten Welt kann die Anwendung über Webservices kommunizieren und benötigt keine gemeinsame Datenbank mehr, um in Echtzeit auszutauschen.
  • Microservice Architektur sogar anfällig für die Vermeidung einer gemeinsam genutzten Datenbank : Es wird erwartet, dass jeder (Mikro-) Service seine eigene private Datenbank hat =, um die Entkopplung zu erhöhen und den Einsatz neuer Entwicklungen zu beschleunigen.
  • Durch Cloud-Operationen können die Betriebskosten unter einem völlig anderen Gesichtspunkt überprüft werden. Sie kümmern sich nicht mehr darum, wie viele Datenbankserver Sie patchen, aktualisieren oder sichern müssen: Sie sind im Preis enthalten.
  • NoSQL hat den Weg zum Mainstream gefunden: Viele Anwendungen können perfekt mit einem RDBMS zusammenarbeiten. Es gibt jedoch spezielle Probleme, die mit unterschiedlicher Technologie besser gelöst werden können: Eine Diagramm-DB, eine dokumentenorientierte DB oder die Notwendigkeit einer geolokalisierten Sortierung können eine spezialisierte DB-Engine begünstigen. Eine DB-Richtlinie wäre ein Blocker.
  • Einige Anwendungen benötigen keine Datenbank. Beispielsweise verarbeiten Ereignisströme in Echtzeit große Datenmengen zwischen Anwendungen, ohne dass die Daten auf einer Datenbank gemeinsam genutzt werden müssen (das Datenbankäquivalent würde ineffiziente sich wiederholende Abfragen erfordern, um neue Daten zu erkennen).

Fazit

Der Schlüssel für eine gute Architektur besteht nicht mehr darin, die richtigen Tabellen in einer einzelnen Datenbank zu definieren, sondern die richtigen APIs zu definieren, damit die Dienste den Klebstoff zwischen den verschiedenen Apps herstellen können.

Lassen Sie uns nicht dogmatisch sein. Für eng verwandte Anwendungen, die im selben begrenzten Kontext arbeiten, ist eine gemeinsam genutzte Datenbank immer noch eine gültige Alternative .

6
Christophe

Ich war auch in Situationen, in denen sich verschiedene Apps in derselben Datenbank befanden. Ich verstehe Ihre Frustration, aber manchmal hängt "Best Practice" von "guten Geschäften" ab.

Wie Sie bereits betont haben, wäre es offensichtlich sinnvoller, die Apps in derselben Datenbank zu haben, wenn sie miteinander verbunden wären. Wenn es einen geschäftlichen Grund gibt (wie in der anderen Antwort und in den Kommentaren angegeben), können Sie diesen Grund akzeptieren oder versuchen, einen besseren geschäftlichen Grund für die Trennung zu finden. Zwei, die ich mir vorstellen kann, wären mögliche Sicherheitsbedenken und Skalierbarkeit. Heutzutage werden viele Apps virutalisiert und containerisiert. Es ist trivial, eine Datenbank in einen Docker-Container einzufügen, der neben Docker-Apps (oder einer von Ihnen verwendeten Container-App) bereitgestellt wird. Natürlich geht diese Linie davon aus, dass die Kosten für die Lizenzierung oder das Personal die Vorteile des Hinzufügens eines weiteren Containers nach Bedarf nicht überwiegen.

Zusammenfassend ist ihre Architektur also nicht ungewöhnlich, sie wird gemacht. Wenn Sie eine andere Richtung vorschlagen möchten, verstehen Sie, warum sie ihre Entscheidung getroffen haben (technisch oder geschäftlich), und versuchen Sie, ein Argument zu liefern, das diesen Bereich betrifft.

0
Jeff