Langages autres que SQL dans Postgres

Question

J'utilise PostgreSQL un peu ces derniers temps, et l'une des choses que je trouve cool est que vous pouvez utiliser des langages autres que SQL pour les fonctions de script et ainsi de suite.Mais quand est-ce réellement utile ?

Par exemple, la documentation indique que la principale utilisation de PL/Perl est qu'il est plutôt bon en manipulation de texte.Mais n’est-ce pas plutôt quelque chose qui devrait être programmé dans l’application ?

Deuxièmement, existe-t-il une raison valable d’utiliser un langage non fiable ?Il semble que faire en sorte que n'importe quel utilisateur puisse exécuter n'importe quelle opération serait une mauvaise idée sur un système de production.

PS.Points bonus si quelqu'un peut gagner PL/LOLCODE semblent utiles.

Answer 1

"N'est-ce pas [la manipulation de texte] plutôt quelque chose qui devrait être programmé dans l'application ?"

Habituellement, oui.Le "généralement accepté"à trois niveaux" La conception d'applications pour bases de données indique que votre logique doit se situer au niveau intermédiaire, entre le client et la base de données.Cependant, vous avez parfois besoin d'une certaine logique dans un déclencheur ou d'indexer une fonction, ce qui nécessite qu'une partie du code soit placée dans la base de données.Dans ce cas, tous les "quel langage devrais-je utiliser?" Les questions se posent.

Si vous n'avez besoin que d'un peu de logique, le langage le plus portable devrait probablement être utilisé (pl/pgSQL).Si vous avez besoin de faire de la programmation sérieuse, vous feriez peut-être mieux d'utiliser un langage plus expressif (peut-être pl/ruby).Ce sera toujours une question de jugement.

"Y a-t-il une raison valable d'utiliser un langage non fiable ?"

Comme ci-dessus, oui.Encore une fois, il est préférable de mettre l'accès direct aux fichiers (par exemple) dans votre niveau intermédiaire lorsque cela est possible, mais si vous devez déclencher des choses en fonction de déclencheurs (qui peuvent nécessiter un accès à des données non disponibles directement à votre niveau intermédiaire), alors vous avez besoin d'un accès non fiable. langues.Ce n’est pas idéal et devrait généralement être évité.Et vous devez absolument en garder l’accès.

Answer 2

@Mike:ce genre de réflexion me rend nerveux.J'ai entendu à plusieurs reprises "cela devrait être infiniment portable", mais quand la question est posée :prévoyez-vous réellement qu'il y aura un portage ?la réponse est:Non.

S'en tenir au plus petit dénominateur commun peut vraiment nuire aux performances, tout comme l'introduction de couches d'abstraction (ORM, PHP PDO, etc.).Mon avis est:

• Évaluez de manière réaliste s'il est nécessaire de prendre en charge plusieurs SGBDR.Par exemple, si vous écrivez une application Web open source, il est probable que vous deviez au moins prendre en charge MySQL et PostgreSQL (sinon MSSQL et Oracle).
• Après l’évaluation, profitez au maximum de la plateforme que vous avez choisie

Et d'ailleurs :vous mélangez des bases de données relationnelles avec des bases de données non relationnelles (CouchDB est pas un SGBDR comparable à Oracle par exemple), illustrant encore davantage le fait que le besoin perçu de portabilité est souvent largement surestimé.

Answer 3

De nos jours, toute fonctionnalité « unique » ou « cool » dans un SGBD me rend incroyablement nerveux.J'ai une éruption cutanée et je dois arrêter de travailler jusqu'à ce que les démangeaisons disparaissent.

Je déteste simplement être enfermé inutilement sur une plate-forme.Supposons que vous construisiez une grande partie de votre système en PL/Perl dans la base de données.Ou en C# dans SQL Server, ou en PL/SQL dans Oracle, il existe de nombreux exemples*.

Maintenant, vous découvrez soudainement que la plateforme que vous avez choisie n'est pas évolutive.Ou ce n'est pas assez rapide.Ou quelque chose.Pire encore, il y a un nouveau venu dans le bloc de base de données (quelque chose comme MonetDB, CouchDB, Cache, disons, mais en beaucoup plus cool) qui résoudrait tous vos problèmes (même si votre seul problème, comme le mien, est d'avoir une plate-forme de base de données peu cool).Et vous ne pouvez pas y accéder sans recoder la moitié de votre application.

(*Certes, les produits payants cherchent dans une certaine mesure à vous enfermer en vous persuadant d'utiliser leurs fonctionnalités uniques, ce qui n'est pas une accusation directement adressée aux fournisseurs gratuits, mais l'effet est le même).

C'est donc une diatribe sur la première partie de la question.Du cœur, cependant.

Y a-t-il une raison valable d'utiliser une langue non fiable?Il semble que tout utilisateur puisse exécuter n'importe quelle opération serait une mauvaise idée

Mon Dieu, oui !Une sorte d'« attaque par injection Perl » ?Cela valait presque la peine de le faire juste pour voir ce qui se passe, aurais-je pensé.

Pour les raisons philosophiques évoquées ci-dessus, je pense que je vais laisser de côté le défi PL/LOLCODE.Même si j’ai été quelque peu étonné de découvrir qu’il s’agissait d’un lien vers quelque chose d’existant.

Answer 4

De mon point de vue, je suppose que la réponse est « ça dépend ».

Il existe un argument selon lequel la manipulation des données appartient à la couche de base de données, de sorte que la logique métier n'a pas besoin de se soucier outre mesure de la manière dont la manipulation se produit, elle sait simplement que c'est le cas.

Une autre très bonne raison de traiter les données sur la couche base de données est que le volume de données traitées signifie que la bande passante du réseau deviendra un problème.Une fois, j'ai dû catégoriser de très grandes quantités de données.Le traitement de ces informations dans la couche application était considérablement limité par le temps nécessaire au transfert de toutes les données sur le réseau pour traitement.

J'ai ensuite écrit un algorithme de binning en PL/pgSQL et cela a fonctionné beaucoup plus rapidement.

Concernant les langages non fiables, j'ai entendu un podcast de Josh Berkus (un défenseur de Postgres) qui parlait d'une application de postgresql qui apportait des données de MySQL dans le cadre de son traitement, de sorte que la communication elle-même était gérée par le serveur Postgres.Je ne me souviens pas de tous les détails, je pense que c'était sur le Podcast hebdomadaire FLOSS ce qui est une discussion assez intéressante sur l'histoire de PostGRESQL et certains des problèmes auxquels il est confronté.

Answer 5

Les versions non fiables des langages procéduraux vous permettent d'accéder aux E/S sur le système.Cela peut s'avérer utile si vous avez besoin d'un déclencheur ou de quelque chose pour envoyer un e-mail ou vous connecter à un serveur socket pour envoyer une notification contextuelle.Il existe des tonnes d'utilisations pour ce type de chose, et grâce aux niveaux d'isolation postgresql, vous pouvez faire des choses comme celle-ci en toute sécurité.Vous pouvez mettre des points de contrôle dans la fonction afin que si la transaction échoue, l'e-mail ou quoi que ce soit ne soit pas envoyé.L'avantage de cette méthode est que cela supprime la logique du client et la place sur le serveur.

Answer 6

Je pense que la plupart des langages supplémentaires sont proposés afin que si vous développez régulièrement dans ce langage, vous puissiez vous sentir à l'aise pour écrire des fonctions de base de données, des déclencheurs, etc.L’utilité de ces fonctionnalités est de fournir un contrôle des données au plus près des données.

Answer 7

Un exemple de procédure stockée utile que j'ai récemment écrite dans un langage externe qui n'aurait pas été possible en pl/sql est une version de « df » qui permettait aux générateurs de tables SQL de choisir un espace de table avec le plus d'espace libre disponible au moment de l'exécution.

J'ai utilisé plperlu, et c'était relativement simple, même si je devais faire attention à la saisie des données.