Idiomas distintos de SQL en postgres

Question

He estado usando PostgreSQL un poco últimamente, y una de las cosas que creo que es interesante es que puedes usar otros lenguajes además de SQL para funciones de scripting y todo eso.Pero ¿cuándo es esto realmente útil?

Por ejemplo, la documentación dice que el uso principal de PL/Perl es que es bastante bueno en la manipulación de texto.¿Pero no es eso algo que debería programarse en la aplicación?

En segundo lugar, ¿existe alguna razón válida para utilizar un lenguaje que no sea de confianza?Parece que hacer que cualquier usuario pueda ejecutar cualquier operación sería una mala idea en un sistema de producción.

PD.Puntos de bonificación si alguien puede hacer PL/LOLCODE parece útil.

Answer 1

"¿No es eso [manipulación de texto] algo que debería programarse en la aplicación?"

Generalmente sí.El generalmente aceptado "tres niveles"El diseño de aplicaciones para bases de datos dice que su lógica debe estar en el nivel medio, entre el cliente y la base de datos.Sin embargo, a veces necesita algo de lógica en un disparador o necesita indexar una función, lo que requiere que se coloque algún código en la base de datos.En ese caso, todo lo habitual "¿Qué idioma debo usar?" surgen preguntas.

Si sólo necesita un poco de lógica, probablemente debería utilizar el lenguaje más portátil (pl/pgSQL).Sin embargo, si necesita hacer algo de programación seria, sería mejor que usara un lenguaje más expresivo (tal vez pl/ruby).Esto siempre será una cuestión de criterio.

"¿Existe alguna razón válida para utilizar un lenguaje que no sea de confianza?"

Como arriba, sí.Nuevamente, colocar acceso directo a archivos (por ejemplo) en su nivel medio es lo mejor cuando sea posible, pero si necesita activar cosas en función de activadores (que podrían necesitar acceso a datos que no están disponibles directamente en su nivel medio), entonces necesita que no sean de confianza. idiomas.No es lo ideal y, en general, debe evitarse.Y definitivamente necesitas proteger el acceso a él.

Answer 2

@Miguel:Este tipo de pensamiento me pone nervioso.He escuchado muchas veces "esto debería ser infinitamente portátil", pero cuando se hace la pregunta:¿Realmente prevés que habrá alguna portabilidad?la respuesta es:No.

Ceñirse al mínimo común denominador realmente puede perjudicar el rendimiento, al igual que la introducción de capas de abstracción (ORM, PHP PDO, etc.).Mi opinión es:

• Evalúe de manera realista si es necesario admitir múltiples RDBMS.Por ejemplo, si está escribiendo una aplicación web de código abierto, es probable que necesite admitir al menos MySQL y PostgreSQL (si no MSSQL y Oracle).
• Después de la evaluación, aprovecha al máximo la plataforma que elegiste

Y por cierto:está mezclando bases de datos relacionales con bases de datos no relacionales (CouchDB es no un RDBMS comparable con Oracle, por ejemplo), lo que ejemplifica aún más el hecho de que muchas veces se sobreestima en gran medida la necesidad percibida de portabilidad.

Answer 3

Hoy en día, cualquier característica "única" o "interesante" de un DBMS me pone increíblemente nervioso.Me sale un sarpullido y tengo que dejar de trabajar hasta que desaparezca la picazón.

Simplemente odio estar encerrado en una plataforma innecesariamente.Supongamos que construye una gran parte de su sistema en PL/Perl dentro de la base de datos.O en C# dentro de SQL Server, o PL/SQL dentro de Oracle, hay muchos ejemplos*.

Ahora, de repente, descubres que la plataforma que has elegido no escala.O no es lo suficientemente rápido.O algo.Peor aún, hay un nuevo chico en el bloque de bases de datos (algo como MonetDB, CouchDB, Cache, por ejemplo, pero mucho más interesante) que resolvería todos sus problemas (incluso si su único problema, como el mío, es tener una plataforma de base de datos poco interesante).Y no puedes cambiar a él sin grabar la mitad de tu aplicación.

(*Es cierto que los productos pagos buscan, hasta cierto punto, encerrarte persuadiéndote de que uses sus características únicas, lo cual no es una acusación que pueda dirigirse directamente a los proveedores gratuitos, pero el efecto es el mismo).

Entonces esa es una perorata sobre la primera parte de la pregunta.Sin embargo, de corazón.

¿Hay alguna razón válida para usar un lenguaje no confiable?Parece que hacerlo para que cualquier usuario pueda ejecutar cualquier operación sería una mala idea

¡Dios mío, sí lo hace!¿Una especie de "ataque de inyección de Perl"?Casi vale la pena hacerlo sólo para ver qué pasa, habría pensado.

Por razones filosóficas descritas anteriormente, creo que pasaré por alto el desafío PL/LOLCODE.Aunque me sorprendió un poco descubrir que era un vínculo con algo existente.

Answer 4

Desde mi perspectiva, supongo que la respuesta es "depende".

Existe el argumento de que la manipulación de los datos pertenece a la capa de la base de datos, por lo que la lógica empresarial no necesita preocuparse demasiado por cómo se produce la manipulación, simplemente sabe que así ha sido.

Otra muy buena razón para procesar datos en la capa de base de datos es si el volumen de datos que se procesa significa que el ancho de banda de la red se convertirá en un problema.Una vez tuve que categorizar cantidades muy grandes de datos.El procesamiento de esto en la capa de aplicación estuvo severamente restringido por el tiempo requerido para transferir todos los datos a través de la red para su procesamiento.

Luego escribí un algoritmo de agrupación en PL/pgSQL y funcionó mucho más rápido.

Con respecto a los lenguajes que no son de confianza, escuché un podcast de Josh Berkus (un defensor de Postgres) que hablaba de una aplicación de PostgreSQL que traía datos de MySQL como parte de su procesamiento, de modo que la comunicación en sí era manejada por el servidor de Postgres.No recuerdo todos los detalles, creo que estaba en el Podcast semanal de FLOSS lo cual es una discusión bastante interesante sobre la historia de PostGRESQL y algunos de los temas que aborda.

Answer 5

Las versiones no confiables de los lenguajes de procedimiento le permiten acceder a E/S en el sistema.Esto puede resultar útil si necesita un disparador o algo así, enviar un correo electrónico o conectarse a un servidor de socket para enviar una notificación emergente.Hay muchos usos para este tipo de cosas y, debido a los niveles de aislamiento de PostgreSQL, puedes hacer cosas como esta de forma segura.Puede poner puntos de control en la función para que, si la transacción falla, el correo electrónico o lo que sea no se envíe.Lo bueno de hacer esto es que elimina la lógica del cliente y la coloca en el servidor.

Answer 6

Creo que la mayoría de los lenguajes adicionales se ofrecen para que, si desarrollas ese lenguaje con regularidad, puedas sentirte cómodo escribiendo funciones de base de datos, activadores, etc.La utilidad de estas funciones es proporcionar un control sobre los datos lo más cercano posible a los datos.

Answer 7

Un ejemplo de un procedimiento almacenado útil que escribí recientemente en un lenguaje externo que no habría sido posible en pl/sql es una versión de 'df' que permitía a los generadores de tablas SQL elegir un espacio de tabla con la mayor cantidad de espacio libre disponible en tiempo de ejecución.

Utilicé plperlu y fue relativamente sencillo, aunque tuve que tener cuidado al escribir los datos.