Implementierung von Funktionen/Code direkt im Datenbanksystem

Question

RDBMS-Pakete bieten heute eine enorme Menge an Funktionen, die über die standardmäßige Speicherung und Abfrage von Daten hinausgehen. SQL Server kann beispielsweise E-Mails versenden, Web-Service-Methoden bereitstellen und CLR-Code ausführen, um nur einige Beispiele zu nennen. Ich habe jedoch immer versucht, den Umfang der Verarbeitung meines Datenbankservers so weit wie möglich auf die Speicherung und den Abruf von Daten zu beschränken, und zwar aus den folgenden Gründen

• Ein Datenbankserver ist schwieriger zu skalieren als ein Webserver
• In vielen Projekten, an denen ich gearbeitet habe, ist der DB-Server viel stärker ausgelastet als die Webserver und hat daher weniger freie Kapazitäten.
• Ihr Datenbankserver ist potenziell einem Sicherheitsangriff ausgesetzt (z. B. Webdienste).

Meine Frage lautet: Wie entscheiden Sie, wie viel Funktionalität oder Code direkt auf Ihrem Datenbankserver im Vergleich zu anderen Servern in Ihrer Architektur implementiert werden sollte? Welche Empfehlungen haben Sie für Leute, die neue Projekte beginnen?

Answer 1

Ich weiß, dass Microsoft SQL Server und Oracle die Verwendung von gespeicherten Prozeduren für alles vorantreiben, was dazu beiträgt, die relationale Architektur zu kapseln und eine eher prozedurale Schnittstelle für die Softwareentwickler zu schaffen, die in der Regel nicht so leicht SQL-Abfragen schreiben können.

Aber die Hälfte der Anwendungslogik wird in PL/SQL (oder T-SQL oder was auch immer) geschrieben und die andere Hälfte in Ihrer Anwendungssprache, Java oder PHP oder C#, usw. Der DBA ist in der Regel für die Programmierung der Prozeduren zuständig, während die Entwickler für alles andere verantwortlich sind. Niemand hat Einblick und Zugriff auf die gesamte Anwendungslogik. Dies verlangsamt die Entwicklung, das Testen und künftige Überarbeitungen des Projekts.

Auch die Softwareentwicklungswerkzeuge sind für gespeicherte Prozeduren eher schlecht geeignet. Werkzeuge und bewährte Verfahren für Debugging, Quellcodekontrolle und Tests scheinen alle etwa 10-15 Jahre hinter dem Stand der Technik für Anwendungssprachen zurückzubleiben.

Daher tendiere ich dazu, gespeicherte Prozeduren und Trigger nach Möglichkeit zu meiden. Außer in bestimmten Fällen, in denen eine gut platzierte gespeicherte Prozedur eine komplexe SQL-Operation vollständig im Server ablaufen lassen kann, anstatt Daten hin und her zu schieben. Dies kann sehr effektiv bei der Beseitigung von Leistungsengpässen sein.

Es ist auch möglich, zu weit in die andere Richtung zu gehen. Leute, die es vorziehen, dass die Anwendung die Daten und nicht die Metadaten verwaltet, und die Entwürfe wie Entity-Attribute-Value oder polymorphe Assoziationen verwenden, bringen sich selbst in Schwierigkeiten. Lassen Sie das die Datenbank erledigen. Verwenden Sie referentielle Integritätsbeschränkungen (Fremdschlüssel). Verwenden Sie Transaktionen.

Answer 2

Die Anbieter haben eine Reihe von Best Practices. Sie äußern jedoch Bedenken in dieser Hinsicht.

Vor Jahren unterstützte ich eine Wichtigstes Software-Produkt . Major.

Sie sagten: "Die Datenbank ist ein relationaler Speicher. Mehr nicht." Auf jeder Benutzerkonferenz fragten die Leute nach gespeicherten Prozeduren, Triggern und all diesem Quatsch.

Ihr Architekt war fest entschlossen. Sobald man von einfachem, altem SQL abweicht, hat man einen Support- und Wartungsalptraum. Sie haben ein objektrelationales Mapping von der DB in ihr Produkt gemacht, und alles andere war in ihrem Produkt.

Das lässt sich gut skalieren. Mehrere Anwendungsserver können sich problemlos einen einzigen Datenbankserver teilen.