¿Es estúpido escribir un gran programa de procesamiento por lotes completamente en PL/SQL?

Question

Estoy empezando a trabajar en un programa que quizás se describa de forma más natural como un lote de cálculos en tablas de bases de datos y que se ejecutará una vez al mes.Todas las entradas están en las tablas de la base de datos de Oracle y todas las salidas estarán en las tablas de la base de datos de Oracle.El programa debería seguir siendo mantenible durante muchos años más.

Parece sencillo implementar esto como una serie de procedimientos almacenados, cada uno de los cuales realiza una transformación sensata, por ejemplo, distribuyendo costos entre departamentos de acuerdo con algunas reglas comerciales.Luego puedo escribir pruebas unitarias para verificar si el resultado de cada transformación es el que esperaba.

¿Es una mala idea hacer todo esto en PL/SQL?¿Preferiría realizar cálculos por lotes pesados ​​en un típico lenguaje de programación orientado a objetos, como C#?¿No es más expresivo utilizar un lenguaje de programación centrado en bases de datos como PL/SQL?

Answer 1

Normalmente digo que pongas la menor cantidad posible de PL/SQL (normalmente es mucho menos fácil de mantener). En uno de mis últimos trabajos, realmente vi lo complicado y difícil que podía llegar a ser trabajar con él.

Sin embargo, dado que se trata de un procesamiento por lotes, y dado que la entrada y la salida son tanto la base de datos, tiene sentido poner la lógica en PL/SQL, para minimizar las "partes móviles".Sin embargo, si se tratara de lógica empresarial, o de componentes utilizados por otras partes de su sistema, diría que no lo haga.

Answer 2

Usted describe los siguientes requisitos

a) debe ser capaz de implementar el procesamiento por lotes b) el resultado debe ser mantenible

Mi respuesta:

1. PL/SQL fue diseñado para lograr exactamente lo que usted describe.También es importante tener en cuenta que existen eficiencias en PL/SQL que no están disponibles en otras herramientas.Un lenguaje de procedimiento almacenado coloca el procesamiento junto a los datos, que es donde debería ubicarse el procesamiento por lotes.
2. Es bastante fácil escribir código de difícil mantenimiento en cualquier idioma.

Dicho lo anterior, su implementación dependerá de las habilidades disponibles, un diseño adecuado y el cumplimiento de procesos de buena calidad.

Para ser eficiente, su implementación debe procesar datos en lotes (seleccionar en lotes e insertar/actualizar en lotes).El peligro de un enfoque OO es que es fácil dejarse llevar hacia un diseño que procesa datos fila por fila.Este tipo de enfoque contiene gastos generales innecesarios y será significativamente menos eficiente que un diseño que procesa datos en lotes de filas.

Es posible utilizar ambos enfoques con éxito.

Mateo mayordomo

Answer 3

Algo que otros comentaristas deben tener en cuenta: la pregunta es sobre PL/SQL, no sobre SQL.Algunas de las respuestas obviamente han sido sobre SQL, no sobre PL/SQL.PL/SQL es un lenguaje de base de datos completamente funcional y también maduro.Hay algunas deficiencias, pero para el tipo de cosas que quiere hacer el cartel, está muy bien.

Answer 4

No, no es necesariamente una mala idea.Si la solución le parece sencilla y le permite probar y verificar cada proceso, parece que podría ser una buena idea.Las plataformas OO pueden ser (aunque no tienen por qué serlo) malas para grandes conjuntos de datos, ya que la creación de objetos y los gastos generales pueden afectar el rendimiento.

Oracle diseñó PL/SQL teniendo en cuenta problemas como el suyo; si hay suficiente conocimiento corporativo de la base de datos y PL/SQL, esta parece una solución razonable.Tenga en cuenta conjuntos de lotes grandes, ya que cada llamada de PL/SQL al motor SQL real es un cambio de contexto, por lo que los procesos de registro único deben agruparse por lotes siempre que sea posible para mejorar el rendimiento.

Answer 5

Solo asegúrese de registrar de alguna manera lo que sucede mientras está funcionando.De lo contrario tendrás una caja negra y si se queda atascada en algún lugar durante horas, te preguntarás si detenerla o dejarla funcionar 'un poquito más'.

Answer 6

PL/SQL es un lenguaje maduro que se integra bien con SQL.Con cada versión de Oracle se vuelve cada vez más poderoso.También a partir de Oracle 11, PL/SQL se compila en código de máquina de forma predeterminada.

Answer 7

Escribí una gran cantidad de programas de procesamiento por lotes y generación de informes tanto en PL/SQL como en Pro.C para un proyecto.En general, preferían que escribiera en PL/SQL, ya que sus propios desarrolladores que lo mantendrían en el futuro encontraron que era más fácil de entender que Pro.Código C.

Terminó siendo sólo el procesamiento o los informes realmente originales que terminaron escribiéndose en Pro*C.

No es necesario escribirlos como procedimientos almacenados como han aludido otras personas, pueden ser simplemente archivos de script que se ejecutan según sea necesario, algo así como un script de shell.También facilite muchísimo el control de revisión del código fuente y la migración entre sistemas de prueba y producción.

Answer 8

Siempre que los cálculos que necesita realizar puedan capturarse de manera adecuada Y legible en PL/SQL, entonces usar solo PL/SQL tendría más sentido.

El verdadero problema es la capacidad de mantenimiento: es muy fácil escribir SQL que no se puede mantener, aunque solo sea porque cada RDBMS tiene una sintaxis diferente y un conjunto de funciones diferente una vez que se sale del DML de SQL simple, y no hay estándares reales para el formato.comentando, etc

Answer 9

He creado programas por lotes usando C# y SQL.

Ventajas de C#:

Tienes la biblioteca completa de .NET y todo el poder de un lenguaje OO.

Contras de C#:

*El programa por lotes y la base de datos están separados: esto significa que tendrá que administrar su programa por lotes por separado de la base de datos.

*Necesitas escapar de todo ese maldito código SQL.

Ventajas de SQL:

*Se integra muy bien con el DBMS.Si este trabajo solo manipula la base de datos, tendría sentido incluirlo en la base de datos.Termina con una única base de datos y todos sus componentes en un solo paquete.

*No es necesario escapar del código SQL.

* manteniéndolo real: estás programando en el dominio de tu problema

Contras de SQL:

Es SQL y yo personalmente no lo conozco tan bien como SQL.

En general, seguiría usando SQL debido a las ventajas descritas anteriormente.

Answer 10

Esta es una pregunta cargada :) Hay un par de diseños de arquitectura de programación de bases de datos que debe conocer y cuáles son sus costos/beneficios.2 niveles generalmente significa que tiene un cliente que se conecta a una base de datos y emite llamadas SQL directas.3 niveles generalmente significa que tiene un "servidor de aplicaciones" que emite llamadas SQL directas a la base de datos, pero el cliente está hablando con el servidor de aplicaciones.Generalmente, esto permite una "ampliación gradual".Finalmente, tiene aplicaciones de 2 1/2 niveles que emplean un formato similar a 2 niveles, solo que el trabajo está compartimentado dentro de los procedimientos almacenados.

Su proceso suena como una especie de "back office", y los clientes/procesos solo necesitan resultados que se agreguen y almacenen en caché una vez al mes.Es decir, no hay ningún agente que se conecte, y se conecte seguido, y diga "haz estos cálculos".En lugar de eso, aludes a un proceso que ocurre de vez en cuando y puedes salirte con la tuya en tiempo no real.

Por lo tanto, dados esos requisitos, diría que, en general, será más rápido estar más cerca de los datos y dejar que el servidor SQL haga todos los cálculos.Creo que encontrará que la proximidad a los datos le será de gran utilidad.

Sin embargo, al realizar estos cálculos, es posible que algunos cálculos no sean compatibles con los servidores SQL.Tomemos, por ejemplo, el cálculo del interés acumulado de un bono o de cualquier instrumento de renta fija.No es muy bonito en SQL y mucho más adecuado para un lenguaje de programación más rico.Sin embargo, si solo tiene promedios simples y otros agregados relativamente sensatos, me limitaría a los procedimientos almacenados, en el lado de SQL.

Nuevamente, no hay suficiente información sobre la naturaleza de sus cálculos, o lo que su casa exige en términos de capacidades SQL de los desarrolladores para soporte, o lo que dice su jefe... pero como conozco SQL y me gusta Manténgase cerca de los datos, me quedaría con SQL puro/procedimientos almacenados para una tarea como esta.

YMMV :)

Answer 11

Por lo general, no es más expresivo porque la mayoría de los lenguajes de procedimientos almacenados apestan por diseño.Pero probablemente se ejecutará más rápido que en una aplicación externa.

Supongo que todo se reduce a qué tan familiarizado estás con PL/SQL, cuánto tiempo tienes para escribir esto, qué tan importante es el rendimiento y si puedes esperar razonablemente que los mantenedores estén lo suficientemente familiarizados con PL/SQL como para mantener un gran programa escrito en él.

Si la velocidad no es relevante y los mantenedores probablemente no sean competentes en PL/SQL, sería mejor que utilices un lenguaje "tradicional".

También podría usar un enfoque híbrido, donde usa PL/SQL para generar datos intermedios (por ejemplo, uniones de tablas y sumas o lo que sea) y una aplicación separada para controlar el flujo y verificar valores y errores.