Andere Sprachen als SQL in Postgres

StackOverflow https://stackoverflow.com/questions/39517

Frage

Ich benutze PostgreSQL in letzter Zeit ein wenig und eines der Dinge, die ich cool finde, ist, dass man für Skriptfunktionen und so weiter auch andere Sprachen als SQL verwenden kann.Doch wann ist das überhaupt sinnvoll?

In der Dokumentation heißt es zum Beispiel, dass PL/Perl vor allem darin verwendet wird, dass es ziemlich gut Text manipulieren kann.Aber ist das nicht eher etwas, das in die Anwendung einprogrammiert werden sollte?

Zweitens: Gibt es einen triftigen Grund, eine nicht vertrauenswürdige Sprache zu verwenden?Es scheint, dass es auf einem Produktionssystem keine gute Idee wäre, es so zu gestalten, dass jeder Benutzer jeden Vorgang ausführen kann.

PS.Bonuspunkte, wenn jemand machen kann PL/LOLCODE scheinen nützlich zu sein.

War es hilfreich?

Lösung

„Ist das [Textmanipulation] nicht eher etwas, das in die Anwendung programmiert werden sollte?“

Normalerweise ja.Die allgemein anerkannte „dreistufig„Beim Anwendungsdesign für Datenbanken sollte sich Ihre Logik in der mittleren Ebene befinden, zwischen dem Client und der Datenbank.Manchmal benötigen Sie jedoch Logik in einem Trigger oder müssen eine Funktion indizieren, sodass Code in die Datenbank eingefügt werden muss.In diesem Fall all die übliche "Welche Sprache soll ich verwenden?" Fragen auftauchen.

Wenn Sie nur ein wenig Logik benötigen, sollte wahrscheinlich die am besten portierbare Sprache verwendet werden (pl/pgSQL).Wenn Sie jedoch ernsthaft programmieren müssen, ist es möglicherweise besser, eine ausdrucksstärkere Sprache zu verwenden (vielleicht pl/ruby).Dies wird immer eine Entscheidung sein.

„Gibt es einen triftigen Grund, eine nicht vertrauenswürdige Sprache zu verwenden?“

Wie oben, ja.Auch hier ist es nach Möglichkeit am besten, den direkten Dateizugriff (z. B.) in Ihrer Mittelschicht einzurichten. Wenn Sie jedoch Dinge auf der Grundlage von Auslösern auslösen müssen (die möglicherweise Zugriff auf Daten erfordern, die Ihrer Mittelschicht nicht direkt zur Verfügung stehen), benötigen Sie eine nicht vertrauenswürdige Lösung Sprachen.Dies ist nicht ideal und sollte im Allgemeinen vermieden werden.Und Sie müssen den Zugang dazu unbedingt bewachen.

Andere Tipps

@Mike:Diese Art des Denkens macht mich nervös.Ich habe schon oft gehört: „Das sollte unendlich portierbar sein“, aber wenn die Frage gestellt wird:Rechnen Sie eigentlich damit, dass es zu einer Portierung kommen wird?die Antwort ist:NEIN.

Das Festhalten am kleinsten gemeinsamen Nenner kann die Leistung erheblich beeinträchtigen, ebenso wie die Einführung von Abstraktionsschichten (ORMs, PHP PDO usw.).Meiner Meinung nach:

  • Bewerten Sie realistisch, ob die Notwendigkeit besteht, mehrere RDBMS zu unterstützen.Wenn Sie beispielsweise eine Open-Source-Webanwendung schreiben, müssen Sie wahrscheinlich zumindest MySQL und PostgreSQL unterstützen (wenn nicht MSSQL und Oracle).
  • Nutzen Sie nach der Evaluierung die Plattform, für die Sie sich entschieden haben, optimal aus

Und übrigens:Sie mischen relationale mit nicht relationalen Datenbanken (CouchDB ist). nicht ein RDBMS, das beispielsweise mit Oracle vergleichbar ist), was ein weiteres Beispiel dafür ist, dass der wahrgenommene Bedarf an Portabilität oft stark überschätzt wird.

Heutzutage macht mich jedes „einzigartige“ oder „coole“ Feature in einem DBMS unglaublich nervös.Ich bekomme einen Ausschlag und muss die Arbeit unterbrechen, bis der Juckreiz nachlässt.

Ich hasse es einfach, unnötig an eine Plattform gebunden zu sein.Angenommen, Sie erstellen einen großen Teil Ihres Systems in PL/Perl innerhalb der Datenbank.Oder in C# in SQL Server oder PL/SQL in Oracle, es gibt viele Beispiele*.

Jetzt stellen Sie plötzlich fest, dass die von Ihnen gewählte Plattform nicht skalierbar ist.Oder ist nicht schnell genug.Oder so.Schlimmer noch, es gibt ein neues Kind im Datenbankblock (so etwas wie MonetDB, CouchDB, Cache, sagen wir, aber viel cooler), das alle Ihre Probleme lösen würde (auch wenn Ihr einziges Problem, wie meines, darin besteht, eine uncoole Datenbankplattform zu haben).Und Sie können nicht darauf umsteigen, ohne die Hälfte Ihrer Bewerbung neu zu kodieren.

(*Zugegebenermaßen zielen die kostenpflichtigen Produkte in gewisser Weise darauf ab, Sie an sich zu binden, indem sie Sie davon überzeugen, ihre einzigartigen Funktionen zu nutzen, was kein Vorwurf ist, der direkt den kostenlosen Anbietern vorgeworfen werden kann, aber der Effekt ist derselbe).

Das ist also eine Schimpftirade zum ersten Teil der Frage.Aber von Herzen.

Gibt es einen gültigen Grund, eine nicht vertrauenswürdige Sprache zu verwenden?Es scheint, als wäre es eine schlechte Idee, dass jeder Benutzer eine Operation ausführen kann

Meine Güte, ja, das tut es!Eine Art „Perl-Injection-Angriff“?Ich hätte gedacht, dass es sich fast lohnt, es zu tun, nur um zu sehen, was passiert.

Aus den oben genannten philosophischen Gründen denke ich, dass ich auf die PL/LOLCODE-Herausforderung verzichten werde.Allerdings war ich etwas erstaunt, als ich feststellte, dass es sich um einen Link zu etwas Existierendem handelte.

Aus meiner Sicht lautet die Antwort wohl: „Es kommt darauf an“.

Es wird argumentiert, dass die Manipulation der Daten in die Datenbankschicht gehört, sodass sich die Geschäftslogik nicht übermäßig darum kümmern muss, wie die Manipulation erfolgt, sondern nur weiß, dass dies der Fall ist.

Ein weiterer sehr guter Grund, Daten auf der Datenbankschicht zu verarbeiten, besteht darin, dass aufgrund der verarbeiteten Datenmenge die Netzwerkbandbreite zu einem Problem wird.Ich musste einmal sehr große Datenmengen kategorisieren.Die Verarbeitung dieser Daten in der Anwendungsschicht wurde durch die Zeit, die erforderlich war, um alle Daten zur Verarbeitung über das Netzwerk zu übertragen, stark eingeschränkt.

Ich habe dann einen Binning-Algorithmus in PL/pgSQL geschrieben und er hat viel schneller funktioniert.

Was nicht vertrauenswürdige Sprachen betrifft, habe ich einen Podcast von Josh Berkus (einem Postgres-Befürworter) gehört, der eine Anwendung von Postgresql besprach, die im Rahmen ihrer Verarbeitung Daten von MySQL einbrachte, sodass die Kommunikation selbst vom Postgres-Server abgewickelt wurde.Ich erinnere mich nicht an die vollständigen Details, ich glaube, es war am FLOSS Wöchentlicher Podcast Das ist eine recht interessante Diskussion über die Geschichte von PostGRESQL und einige der damit verbundenen Probleme.

Die nicht vertrauenswürdigen Versionen der prozeduralen Sprachen ermöglichen Ihnen den Zugriff auf E/A im System.Dies kann nützlich sein, wenn Sie einen Auslöser oder etwas anderes benötigen, um eine E-Mail zu senden oder eine Verbindung zu einem Socket-Server herzustellen, um eine Popup-Benachrichtigung zu senden.Es gibt unzählige Verwendungsmöglichkeiten für diese Art von Dingen, und aufgrund der Postgresql-Isolationsstufen können Sie solche Dinge sicher tun.Sie können Prüfpunkte in die Funktion einfügen, damit die E-Mail oder was auch immer nicht versendet wird, wenn die Transaktion fehlschlägt.Das Schöne daran ist, dass die Logik vom Client entfernt und auf dem Server abgelegt wird.

Ich denke, die meisten zusätzlichen Sprachen werden angeboten, sodass Sie sich beim Schreiben von Datenbankfunktionen, Triggern usw. wohl fühlen können, wenn Sie regelmäßig in dieser Sprache entwickeln.Der Nutzen dieser Funktionen besteht darin, eine möglichst datennahe Kontrolle über die Daten zu ermöglichen.

Ein Beispiel für eine nützliche gespeicherte Prozedur, die ich kürzlich in einer externen Sprache geschrieben habe und die in pl/sql nicht möglich gewesen wäre, ist eine Version von „df“, die es SQL-Tabellengeneratoren ermöglicht, einen Tabellenbereich mit dem meisten verfügbaren freien Speicherplatz zur Laufzeit auszuwählen.

Ich habe plperlu verwendet und es war relativ einfach, obwohl ich bei der Dateneingabe vorsichtig sein musste.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top