Vereinheitlichung von Programmierung und Datenbankabfrage [geschlossen]

11

Stellen Sie sich ein allgemeines Tutorial für objektorientierte Programmiersprachen wie C ++ oder Java vor: Erstellen Sie ein einfaches Auftragsverarbeitungssystem mit Objekten, die Konten, Aufträge, Artikel usw. darstellen (oder etwas mehr oder weniger Äquivalentes). Macht vollkommen intuitiv Sinn, aber der Elefant am Esstisch ist, dass es nicht real ist, weil dies in Erinnerung bleibende Objekte sind; In einem realen System leben Konten, Bestellungen usw. nicht in erster Linie im Speicher , sondern in einer Datenbank, wobei die Speicherdarstellung nur ein kurzlebiger Spiegel davon ist.

Sie könnten selbst viel Code schreiben, um ihn aus der Datenbank zu lesen und zu schreiben, aber das ist so mühsam und fehleranfällig, dass es tatsächlich niemand tut.

Am Ende benutzt jeder ein ORM, aber diese sind für sich genommen so problematisch, dass eine berühmte Zeitung sie als "Vietnam unserer Branche" bezeichnet.

Ich denke nicht, dass dies eine Nichtübereinstimmung zwischen Objekt und Relational ist , sondern vielmehr eine Nichtübereinstimmung zwischen der Programmiersprache und der Datenbank, da es sich um separate Dinge handelt, die nichts voneinander wissen . Vermutung: Die Lösung besteht darin, eine einzige Sprache zu haben, die sowohl die Programmier- als auch die Datenbankabfragesprache ist. Dies würde wiederum erfordern, dass die Sprachlaufzeit auch die Datenbank und der JIT-Compiler auch das Abfrageoptimierungsprogramm ist.

Das ist also die Zusammenfassung der Probleme, die ich sehe. Meine Frage ist, hat noch jemand,

  1. Eigentlich ein solches einheitliches System gebaut

  2. Versuchte, aber es gelang ihm nicht, ein solches einheitliches System aufzubauen

  3. Hat etwas Wesentliches über das Thema geschrieben, wie Sie so etwas bauen würden oder warum oder warum nicht

  4. Einen alternativen Weg finden, um das Problem zu lösen?

rwallace
quelle
5
Sobald Sie eine Sprache haben, die Datenbank und Code vereint, müssen Sie eine Sprache erfinden, die Datenbank, Code und HTML vereint. Dann müssen Sie sich mit JSON vereinen. Dann müssen Sie sich auf eine intimere Weise als Perl mit Regexp vereinen. Dann müssen Sie sich mit einer hierarchischen Datenbank wie LDAP vereinen (z. B. Microsoft Active Directory, ja, es ist eine Datenbank). Dann müssen Sie sich mit Schlüsselwertdatenbanken wie Mongo oder Cassandra vereinen. Dann müssen Sie sich mit 3D-Rendering usw. usw. vereinen. Sie scheinen nach einem Hammer-Schraubenschlüssel-Kran-Schaufel-Schraubendreher-Lötlampe-Kombinationswerkzeug zu
fragen
1
Es sieht so aus, als könnten Anwendungen mit Ihrer vorgeschlagenen Lösung nicht auf eine entfernte Datenbank zugreifen, oder habe ich Sie falsch verstanden? Weil sowohl die Anwendung als auch die Datenbank dieselbe Instanz der Laufzeit verwenden.
Hör auf, Monica
2
Das hat nichts mit der Technologie zu tun, sondern eher mit dem Datensatz. Ich musste einmal einen Code optimieren, da die Ausführung von Regex 3 Minuten dauerte. Es stellte sich heraus, dass bei der Beantwortung von E-Mails ganze Nachrichten zitiert wurden und E-Mails manchmal auf 5 MB anwachsen können. Bei NUR 5 MB darf Regex ersticken. SQL ist also schnell genug. Wir müssen Regexp
Slebetman
2
Es ist auch erwähnenswert, dass das, was "optimieren" bedeutet, auch innerhalb eines RDBMS unterschiedlich ist, abhängig von den Zielen Ihrer Anwendung. Was indizieren Sie? Wann? Wie? Welche Felder nehmen Sie in den Index auf? Optimieren Sie für hohe Schreibgeschwindigkeit oder hohe Abfragegeschwindigkeit oder maximieren Sie die Transaktionsintegrität? Dieser Tradespace würde sich nicht ändern, wenn er Teil der Muttersprache wäre. Wenn überhaupt, wäre er komplexer und würde den Entwickler viel mehr über die Persistenzschicht verstehen lassen, als er jetzt benötigt (vorausgesetzt, Sie haben ein Team und nicht nur eine Person)
Paul
1
Ich denke, LINQ hier zu erwähnen , hängt zumindest mit 1 zusammen.
Casey Kuball

Antworten:

7

Das ist meine Meinung. Ich sehe zwar, woher Sie kommen, aber ich kann es aus gestalterischer Sicht einfach nicht sehen.

Datenpersistenz ist ein äußerst komplexes Thema. Und Programmiersprachen auch. Die Kombination der beiden würde zu einer Explosion der Komplexität führen. Es würde viel Mühe kosten, beide so gut zu machen, dass die Leute sie tatsächlich nutzen wollen. Ich denke, bereits erwähnte MUMPS sind ein gutes Beispiel. Sie können sich auch verschiedene SQL-Varianten ansehen, auf denen die vollständige Sprache angezeigt wird. Sie mögen brauchbar sein, aber ich glaube nicht, dass die Leute sie gerne benutzen würden.

Ihre Trennung ist also ein klarer Weg, um diese Komplexität zu lösen. Wenn Sie sie nicht zusammenbinden, können Sie sie im Laufe der Zeit ändern und weiterentwickeln. Zum Beispiel ist SQL alt und hat sich seit seiner Erstellung nicht viel geändert. Die zum Ausführen von Anwendungen verwendeten Sprachen haben sich jedoch im selben Zeitraum drastisch geändert. Und jetzt passiert das Gegenteil. Die Sprachen bleiben größtenteils gleich, während Datenbanken geändert und weiterentwickelt werden.

Die Laufzeitbereitstellung ist ein weiteres Problem. Die Kombination der beiden würde bedeuten, dass sowohl die Datenbank als auch die Anwendung oder der Webserver in demselben Prozess ausgeführt werden müssten. Dies ist sowohl aus Sicht der Wartung als auch hinsichtlich der Fähigkeit, sie auf separaten Computern oder in Eins-zu-Eins-Beziehungen auszuführen, äußerst einschränkend.

Die Aufteilung der beiden in separate Module mit einer klaren API zwischen ihnen ist der beste Weg, um die Komplexität gering zu halten und Ihnen Flexibilität bei den Technologien zu geben, die Sie verwenden möchten, und bei der Bereitstellung der endgültigen Teile.

Euphorisch
quelle
TL; DR "Keine gute Idee, weil die Vereinigung gegen die Trennung von Bedenken verstößt"
Ferit
5

Es scheint, als würden Sie einige wichtige Annahmen treffen. Sie gehen beispielsweise davon aus, dass jeder in relationale Datenbanken schreibt. Das ist einfach nicht der Fall, es gibt viele Beispiele für Datenbanken anderer Varianten (Objekt-Datenbank, Dokument-Datenbank usw.), die eine native Programmiersprache verwenden, um den gesamten Code zu schreiben und die Persistenz zu verwalten.

Zum Beispiel ist Db4O sowohl mit Java als auch mit C # kompatibel, ObjectDB in Java, VelocityDB in einer Vielzahl von Sprachen. Die Treiber von MongoDB führen dazu, dass Sie Inhalte in Ihrer Muttersprache schreiben (Bonus, wenn Sie JavaScript verwenden, da dies bedeutet, dass die Shell auch dieselbe Syntax verwendet) und so weiter.

An verschiedenen Stellen wird viel darüber diskutiert, welche DB-Engines in welchen Kontexten besser sind und warum, viel zu viel für den Umfang dieser Antwort, um eine geschlossene Frage auf dieser Site aufzunehmen. Das Ergebnis ist, dass sie jeweils für unterschiedliche Zwecke optimiert sind. Bis vor kurzem galt SQL als eine Art „kleinster gemeinsamer Nenner“ für Geschäftsanwendungen, da Sie in Bezug auf ACID und Leistung viel kostenlos erhalten (obwohl sich beide ändern vor kurzem, als sich Architekturen und Anforderungen ändern).

Es ist auch erwähnenswert, dass es zuvor tatsächlich viele "All-in-One" -Ansätze gab. In Mainframe-Sprachen war häufig eine eigene Persistenzlogik integriert, und es gibt Sprachen wie Smalltalk, die überhaupt nicht zwischen Code und Daten unterscheiden. Auch hier sind sie oft gut für einige Anwendungsfälle, aber nicht für alle.

Paul
quelle
5
  1. Ja (nicht ich). Es wurde MUMPS genannt .

  2. Nach dieser früheren SE.SE-Frage oder diesem Artikel waren MUMPs nicht sehr gut konzipiert. Aber es wurde tatsächlich in der Gesundheitsbranche verwendet (und ich denke, es gibt immer noch Systeme, die es verwenden), also kein Totalausfall.

  3. Sie werden sicherlich Informationen darüber finden, jetzt wissen Sie, wonach Sie suchen müssen. Beginnen Sie mit dem Wikipedia-Link oben.

  4. Suchen Sie nach objektorientierten Datenbanken, von denen viele sprachspezifisch sind. Sie versuchten, die objektrelationale Nichtübereinstimmung auf einfachere Weise als ORMs zu beheben.

Doc Brown
quelle
8
Datenbankzugriff in Mumps .... SK = 0 FSK = $ O (^ VA (200, K)) F: 'KW $ P (^ VA (200, K, 0), U, 1)! druckt Patientennamen aus einem bekannten Mumps-System. Problem gelöst? Nicht so viel.
Joshp
Ich habe einen Kollegen, der auf MUMPS schwört. Die späteren Versionen (Cache) hatten eine zugänglichere Syntax.
Alexey
2
@Alexey: Ich weiß nicht viel über MUMPs, aber es scheint, dass die größeren Probleme als die Syntax die fehleranfälligen Scoping-Regeln waren, die die Entwicklung und Wartung größerer Programme zu einem Albtraum machten.
Doc Brown
@ DocBrown Da hast du es genau. Scoping-Regeln ähneln der Assemblersprache. Es gibt so viele Probleme mit der Art und Weise, wie Mumps normalerweise geschrieben werden, dass es nur von OPs Frage ablenkt.
Joshp
5

Es gibt in der Tat mehrere Systeme, die Datenbank und Programmiersprache in einer einzigen Umgebung vereinen.

Smalltalk kommt dem, was Sie beschreiben, wahrscheinlich am nächsten. Objekte im Speicher bleiben in einem "Bild" erhalten, sodass die Sprachumgebung sofort als (Objekt-) Datenbank verwendet werden kann. Und die meisten modernen Sprachen verfügen über einen integrierten Persistenzmechanismus, der bedeutet, dass Objekte in der Sprachumgebung mithilfe der Sprache selbst beibehalten und abgefragt werden können.

Dies ist sehr praktisch für Einzelbenutzeranwendungen. Der Ansatz lässt sich jedoch nicht auf mehrere Benutzer skalieren, da diese denselben Speicherplatz gemeinsam nutzen müssen, wodurch die Anzahl der Benutzer offensichtlich begrenzt wird. Eine skalierbare Lösung erfordert einen separaten Datenbankserver, der die Parallelität verwaltet. Selbst dann gibt es mehrere NoSql-Datenbanken, die in eine bestimmte Sprachumgebung integriert sind und es Ihnen ermöglichen, Objekte in der Sprache selbst beizubehalten und abzufragen.

Von der relationalen Seite der Dinge haben wir Sprachen wie T-SQL, eine vollwertige Programmiersprache, die eine Obermenge von SQL darstellt, sodass Abfragen und DML mit beliebig komplexer prozeduraler Logik vermischt werden können. Komplexe Geschäftsanwendungen wurden mit T-SQL erstellt, so dass dies sicherlich machbar ist. Der aktuelle Trend geht jedoch dahin, Geschäftslogik außerhalb der Datenbank zu verarbeiten.

In diesen Fällen ist es in der Tat sehr elegant und bequem, die Datenbank in die Programmiersprache zu integrieren und die "Impedanzfehlanpassung" zu vermeiden. Warum verwenden die Benutzer immer noch relationale Datenbanken, die von der Programmierumgebung getrennt sind, und versuchen, eine Brücke mit einem ORM-Kludge zu schlagen?

Es stellt sich heraus, dass Daten und Abfragen unabhängig von einer bestimmten Programmiersprache und -umgebung eine Reihe von Vorteilen haben.

  • Datenunabhängigkeit. In den meisten Organisationen wird auf Daten tatsächlich von mehreren Anwendungen zugegriffen. Ein Shop verfügt möglicherweise über eine Datenbank, die vom Web-Frontend, von einem Kundensupport-Tool, einer Berichts-Engine usw. verwendet wird. Die Daten selbst sind oft langlebig, während Anwendungen kommen und gehen. Das Koppeln der Daten an eine bestimmte Programmierumgebung wäre an eine bestimmte Programmierumgebung gebunden. Aber Programmiersprachen kommen und gehen, während Daten für immer leben.
  • Ad-hoc-Abfrage. Es ist äußerst praktisch, eine Datenbankaufforderung öffnen und eine Abfrage schreiben zu können. Wenn die Abfrage eng an die Programmierumgebung gekoppelt wäre, wäre dies eine Programmieraufgabe, und nur Entwickler könnten dies tun.
  • Vermeiden Sie das Einrasten. Da SQL ein Standard ist, können mehrere Anbieter Datenbankverwaltungssysteme bereitstellen, die mehr oder weniger austauschbar sind. Dies vermeidet eine Lieferantenbindung und erleichtert den Vergleich von Produkten.
  • Lose Kopplung. Eine genau definierte Schnittstelle zwischen Anwendungsschicht und Datenbank ermöglicht es, die Datenbank unabhängig von der Anwendungslogik zu optimieren und zu optimieren.
  • Gemeinsame Schnittstelle. Da die Datenbankschnittstelle unabhängig von der Anwendungslogik ist, können Standardtools für die Profilerstellung, Replikation, Analyse usw. verwendet werden.
JacquesB
quelle
2

Es ist eine ziemlich gute Frage, die ich viele Male in meinem Kopf bearbeitet habe. Ein Beispiel für eine vorhandene Lösung zur Lösung Ihres Problems ist eine Diagrammdatenbank ArangoDB, in der Sie JavaScript (das auf einer internen Engine ausgeführt wird) verwenden, um Controller zu schreiben, die ganze Webseiten generieren können. Daten werden mit JSON an den / vom Speicher übergeben, sodass sie in JavaScript nativ zugänglich sind und Abfragen in einer eingebetteten Abfragesprache ausgeführt werden. Dieser Fall ist also ein Beispiel für die Erweiterung von JavaScript, das in der Datenbank ausgeführt werden soll.

In der Praxis sollten solche Controller aus Sicherheitsgründen nicht der Öffentlichkeit zugänglich gemacht werden, da ein Fehler in der Datenbankkonfiguration oder ein Fehler dazu führt, dass Ihre wertvollen Daten der Öffentlichkeit zugänglich gemacht werden.

Meiner persönlichen Meinung nach ist dies ein guter Ansatz und es wird überlegt, ob die Datenbank eine Art Map / Reduce-Funktion unterstützt, mit der aggregierte Daten- / Textindizes und andere häufig abgefragte Daten in Echtzeit aktualisiert werden und dazwischen eine dünne Sicherheitsschicht hinzugefügt wird (nennen Sie es Laden) balancer) würde eine funktionierende Anwendung in einer verteilten Datenbank ausführen.

auch
quelle
1
  1. Eigentlich ein solches einheitliches System gebaut

Ja, das habe ich in Sciter gemacht .

Das Skript von Sciter ist ein " JavaScript ++ " mit integrierter Persistenz:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Wo ndb.rootist normales Objekt in Bezug auf JS. Alle Eigenschaften und Unterobjekte, auf die von dort aus zugegriffen werden kann, sind dauerhaft - werden bei Bedarf in der Datenbank gespeichert und abgerufen - transparent für den Code:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Die Daten werden entweder im GC-Zyklus, wenn nicht genügend Speicher vorhanden ist, oder bei einem expliziten ndb.commit()Aufruf in der Datenbank gespeichert .

StorageKlasse wird von IndexKlasse begleitet - beständig geordnete Objektsammlungen mit eindeutigen / nicht eindeutigen Schlüsseln.

Der Funktionsumfang ähnelt MongoDB oder anderen NoSQL-Datenbanken, für die ID ist jedoch kein separater ORM erforderlich. Der Datenbankzugriff erfolgt ausschließlich über Skripte.

c-smile
quelle
0

Ich bin absolut dafür und ich habe keine Ahnung, wo ich anfangen soll. SQL kann brillant sein, und ich kann mir vorstellen, dass es großartig wäre, all diese Leistung und die Transaktionsgarantien direkt in Ihrer Allzweck-Programmiersprache zu haben (anstatt Abfragen als Sammlungen von Zeichenfolgen schreiben zu müssen oder, Gott bewahre, ein ORM zu verwenden).

Das einzige System, das sich Ihrer mir bekannten Idee nähert, heißt aquameta (Slogan: "Web-Post-Stack in PostgreSQL"; siehe https://github.com/aquametalabs/aquameta , http://aquameta.org ). Es gibt einige Intro-Videos, die nicht weniger verrückt sind als die Idee selbst (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg). und wenn ich verrückt sage, meine ich, dass sie ihren eigenen Editor und ihr eigenes Versionskontrollsystem in Postgres implementiert haben.

John Frazer
quelle
0

Ich denke, dies war genau der Grund für die Erfindung von LINQ durch Microsoft. Es wird seit mehreren Jahren in vollem Umfang in der Produktion eingesetzt, sodass es leicht ist, Literatur darüber und Reflexionen aus positiven und negativen Erfahrungen aus der realen Welt zu finden. (Die meisten .net-Entwicklungsgeschäfte befürworten dies.)

Ein guter Ausgangspunkt für linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/

Clay Fowler
quelle
Linq-to-SQL ist eine Komponente eines ORM, nach der das OP speziell nicht fragt.
JacquesB
Ich habe NICHT linq-to-sql gesagt. Ich habe nur über linq selbst gesprochen, das in die Programmiersprache integriert ist, unabhängig davon, welcher Datenspeicher dahinter steht, und genau darum hat das OP gebeten.
Clay Fowler