Idiomas que no sean SQL en postgres

Question

He estado utilizando PostgreSQL un poco últimamente, y una de las cosas que creo que es genial es que puedes usar lenguajes distintos de SQL para funciones de escritura y otras cosas. ¿Pero cuándo es esto realmente útil?

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

En segundo lugar, ¿hay algún motivo válido para utilizar un idioma 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.

PS. Puntos de bonificación si alguien puede hacer que PL/LOLCODE parezca útil.

Answer 1

"¿no es eso [manipulación de texto] más de algo que debería ser programado en la aplicación?"

Normalmente, sí. El diseño de aplicación generalmente aceptado "three-tier" 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 desencadenante o necesita indexar en una función, lo que requiere que algún código se coloque en la base de datos. En ese caso, todo el "¿qué idioma debería usar?" surgen preguntas.

Si solo necesita un poco de lógica, probablemente se deba usar el lenguaje más portable (pl/pgSQL). Sin embargo, si necesita realizar una programación seria, es mejor que use un lenguaje más expresivo (tal vez, pl/ruby). Esto siempre será una llamada de juicio.

"¿hay alguna razón válida para usar un idioma que no sea de confianza?"

Como arriba, sí. Nuevamente, poner acceso directo a archivos (por ejemplo) en su nivel medio es lo mejor cuando es posible, pero si necesita disparar en función de desencadenadores (que pueden necesitar acceso a datos que no están disponibles directamente en su nivel medio), entonces no necesita confianza idiomas. No es ideal, y generalmente debe evitarse. Y definitivamente necesitas proteger el acceso a ella.

Answer 2

En estos días, cualquier característica "única" o "genial" en un DBMS me pone increíblemente nervioso. Salgo con sarpullido y tengo que dejar de trabajar hasta que la picazón desaparece.

Odio estar encerrado en una plataforma innecesariamente. Supongamos que construyes una gran parte de tu 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, descubre que la plataforma elegida no tiene escala. O no es lo suficientemente rápido O algo. Peor aún, hay un nuevo chico en el bloque de la base de datos (algo como MonetDB, CouchDB, Cache, por ejemplo, pero mucho más genial) que resolvería todos tus problemas (incluso si tu único problema, como el mío, es tener una plataforma de databse poco atractiva). Y no puedes cambiar sin la recodificación de la mitad de tu aplicación.

(* Es cierto que los productos pagados están intentando, en cierta medida, encerrarte persuadiéndote para que uses sus características únicas, lo cual no es una acusación que pueda ser directamente dirigida a los proveedores gratuitos, pero el efecto es lo mismo).

Así que eso es una diatriba en la primera parte de la pregunta. Corazón enamorado, sin embargo.

¿hay alguna razón válida para usar un idioma no confiable ? Parece que por lo que es por lo que cualquier usuario puede ejecutar cualquier operación sería una mala idea

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

Por razones filosóficas mencionadas anteriormente creo que voy a pasar el desafío PL/LOLCODE. Aunque me sorprendió descubrir que era un enlace a algo existente.

Answer 3

@Mike: este tipo de pensamiento me pone nervioso. Muchas veces me he enterado de que "esto debería ser infinitamente portátil", pero cuando se formula la pregunta, ¿prevén que habrá algún cambio? la respuesta es no.

Seguir el 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:

• Evaluar de forma realista si existe la necesidad de admitir varios RDBMS. Por ejemplo, si está escribiendo una aplicación web de código abierto, es probable que necesite soportar MySQL y PostgreSQL al menos (si no es MSSQL y Oracle)
• Después de la evaluación, aproveche al máximo la plataforma que decidió

Y BTW: está mezclando bases de datos relacionales con sin relación (CouchDB es no un RDBMS comparable con Oracle, por ejemplo), ejemplificando aún más el hecho de que la necesidad percibida de portabilidad muchas veces está sobreestimada.

Answer 4

Desde mi punto de vista, supongo que la respuesta es 'depende'.

Existe un argumento de que la manipulación de los datos pertenece a la capa de la base de datos, por lo que la lógica de negocios no necesita preocuparse demasiado sobre cómo ocurre la manipulación, simplemente sabe que sí.

Otra muy buena razón para procesar datos en la capa db 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 grandes cantidades de datos. Procesar esto en la capa de aplicación fue 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 agrupamiento en PL/pgSQL y funcionó mucho más rápido.

En cuanto a idiomas no confiables, escuché un podcast de Josh Berkus (un defensor de postgres) que discutió una aplicación de postgresql que traía datos de MySQL como parte de su procesamiento, por lo que la comunicación fue manejada por el servidor postgres. No recuerdo todos los detalles, creo que fue en el FLOSS Weekly podcast, que es una discusión bastante interesante sobre la historia de PostGRESQL y algunos de los problemas a los que se enfrenta.

Answer 5

Creo que se ofrecen la mayoría de los idiomas adicionales, de modo que si se desarrolla en ese idioma de forma regular, puede sentirse cómodo escribiendo funciones de db, desencadenantes, etc. La utilidad de estas funciones es proporcionar un control de datos tan cerca a los datos como sea posible.

Answer 6

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

Answer 7

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

Utilicé plperlu, y era relativamente simple, aunque tenía que tener cuidado con la escritura de datos.