procedimientos - Idiomas distintos de SQL en postgres
manual de postgresql 10 en español pdf (7)
"¿no es eso [manipulación del texto] más de algo que debería ser programado en la aplicación?"
Por lo general, sí. El diseño de aplicación de " tres niveles " generalmente aceptado 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.
He estado usando PostgreSQL un poco últimamente, y una de las cosas que creo que es genial es que puedes usar lenguajes que no sean SQL para funciones de guiones 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 alguna razón válida para usar 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.
PD. Puntos de bonificación si alguien puede hacer que PL / LOLCODE parezca útil.
@ 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.
Mantener 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 manera 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 por cierto: está mezclando bases de datos relacionales con sin relación (CouchDB no es 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.
Creo que la mayoría de los idiomas adicionales se ofrecen de manera que si desarrollas en ese idioma de forma regular, puedes sentirte cómodo escribiendo funciones de db, disparadores, etc. La utilidad de estas características es proporcionar un control sobre los datos tan cerca de los datos como posible.
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 no es necesario que la lógica empresarial se preocupe demasiado por cómo se produce la manipulación, simplemente sabe que sí lo ha hecho.
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 binning en PL / pgSQL y funcionó mucho más rápido.
En cuanto a los idiomas que no son de confianza, escuché un podcast de Josh Berkus (un defensor postgres) que discutió una aplicación de postgresql que traía datos de MySQL como parte de su procesamiento, de modo que la comunicación en sí misma era manejada por el servidor postgres. No recuerdo todos los detalles, creo que fue en el podcast semanal de FLOSS, que es una discusión bastante interesante sobre la historia de PostGRESQL y algunos de los problemas que se plantea.
En estos días, cualquier función "ú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, descubres 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, en cierta medida, intentan 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 el mismo).
Entonces 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 que no sea de confianza? Parece que hacer 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 Perl"? Casi vale la pena hacerlo solo para ver qué pasa, habría pensado.
Por razones filosóficas resumidas anteriormente, creo que aprobaré el desafío PL / LOLCODE. Aunque me sorprendió descubrir que era un enlace a algo existente.
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.
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 permitió a los generadores de tabla SQL elegir un espacio de tabla con el mayor espacio libre disponible en tiempo de ejecución.
Usé plperlu, y era relativamente simple, aunque tenía que tener cuidado con la escritura de datos.