¿Hay que colocar los procedimientos almacenados y las llamadas bases de datos de ejecución de los programas de Java

Question

Estoy luchando para mantener el uso de procedimientos almacenados en nuestra empresa. Hay algunas personas que dicen que son malos y no hay que utilizarlos. Estamos utilizando DB2 en la serie i.

Por favor, ayuda en mi argumento para mantener viva procedimientos almacenados en mi empresa.

Answer 1

Aceptar que va a salir a favor de procedimientos almacenados.

En primer lugar si se utilizan de forma exclusiva, hacen refactorización la base de datos mucho más simple que puede utilizar las dependencias almacenados en la base de datos para averiguar lo que se verían afectados por un cambio (bien en SQL Server de todos modos, no se puede hablar de otra datbases).

En segundo lugar, si necesita cambiar simplemente la consulta, que son mucho más simple de implementar.

También son más fáciles de ajustar el rendimiento, ya que fácilmente se pueden llamar sin disparar la aplicación.

Si usted tiene una lógica compleja, entonces ahorrar algo de rendimiento al no tener que enviar todo lo que por la red al servidor de base de datos. No puede parecer una gran ganancia, pero si la consulta se ejecuta complejo miles de veces al día, que se puede sumar.

La seguridad también es extremadamente importante. Si usted no utiliza procedimientos de la tienda, debe establecer los derechos en el nivel de tabla o vista. Esto abre la base de datos para interno fraude. Sí, consultas con parámetros reducen el riesgo de inyección SQL, pero eso no es la única amenaza necesita cuidarse contra. Si tiene datos personales o financieros y no utiliza procedimientos almacenados (y queridos con NO SQL dinámico) y limitar a los usuarios que sólo ser capaz de hacer las cosas a través de los procs, a continuación, el sistema está en peligro extremo de los empleados internos que pueden robar de datos o controles internos de bypass para robar el dinero. Lea acerca de los controles internos en las normas de contabilidad para ver por qué esto es un problema.

ORM también tienden a escribir sólo francamente mal código SQL en especial si la consulta es compleja. Además, como la gente empieza a usar en lugar de procedimientos almacenados, he encontrado que las personas que nunca han usado procedimientos almacenados tienen una comprensión más pobre de cómo conseguir los datos de la base de datos y con frecuencia obtener los datos erróneos. El uso de un ORM es muy bien si usted ya entiende SQL y puede determinar el momento de reescribir el código autogenerado en algo que funcione mejor. Sin embargo, muchos usuarios no tienen la habilidad para escribir código complejo porque nunca aprendieron lo básico.

Por último, puesto que ya ha almacenado procs para su aplicación, deshacerse de ellos por completo es una forma de introducir nuevos errores robaba lo que tenía que generar un nuevo código.

Answer 2

No te va a gustar esto, y probablemente voy a quedar en el olvido downvoted, pero estoy con el resto de vuestra empresa.

Procedimientos almacenados utilizados para ofrecer muchos beneficios (seguridad, rendimiento, etc.), pero con consultas con parámetros y una mejor optimización de consultas, procedimientos almacenados realmente sólo tiene que añadir otra capa de cabeza a su solicitud y le dará otro lugar que necesita para actualizar / modificar código.

Yo prefiero mantener todo en un solo lugar, así que cuando tengo que editar código, puedo ir a un sitio y hacer mis cambios allí.

Si desea más detalles sobre los argumentos para alejarse de Prcoedures almacenados, echa un vistazo a este artículo codinghorror:

Coding Horror: ¿Quién necesita procedimientos almacenados todos modos ?

... y me acabo de dar cuenta de que el artículo es de 2004. Tengo que creer que las bases de datos han mejorado desde entonces, lo que significa que esto suene aún más cierto hoy que lo hizo entonces.

Answer 3

Hacer todo por medio de JDBC significa esencialmente que se va a insertar una capa de red entre el usuario y la base de datos. En suma, significa que los datos es más "a distancia" y vienen a ti más lento. Los procedimientos almacenados pueden trabajar directamente sobre los datos dentro de la base de datos, y la diferencia resultante en la velocidad a la que pueden asombrar.

Tenga en cuenta que usted puede escribir procedimientos almacenados en cualquier lenguaje IBM i incluyendo Java, en caso de que se trata de una cuestión de habilidades programaciones. Asimismo, se tiene acceso a la máquina completo, no sólo algunas partes internas de bases de datos. Aquí el AS / 400 es tan diferente de cualquier otro producto de base de datos, que las experiencias de otras bases de datos simplemente - en mi opinión -. No se aplica

Recomendaría las listas de correo de gama media, ya que tienen la mayor concentración del AS / 400 de conocimientos de programación no conozco.

Answer 4

Esta es una de esas cuestiones Marmite. si usted es principalmente un programador de base de datos que va a pensar que los procedimientos almacenados se deben utilizar ampliamente. Si usted es un programador de aplicaciones - por ejemplo una Java o .Net un codificador - lo más probable es que va a decir que deberían evitarse por completo.

No es que esto cumple con los programadores de aplicaciones quieren escribir sus propias sentencias SQL. No, en estos días que tienden a querer todo atrás abstracta servicios de ORM contorneados. Estos no son fáciles de entender que los procedimientos almacenados, pero están disponibles en el mismo IDE, por lo que requieren menos cambios de contexto.

Hay dos grandes cosas en favor de los procedimientos almacenados. La primera es que las personas que conocen PL / SQL es probable que estén familiarizados con las bases de datos Oracle (T-SQL y SQL Server, etc), y por lo tanto tienden a escribir mejores programas para esa base de datos (que se define como los programas que se aprovechan de la década de plataforma características y están montados en su funcionalidad) que las personas que no lo hacen.

La segunda cosa es que persiste datos. Los desarrolladores de aplicaciones son aficionados a hablar de la "independencia de la base de datos", pero lo que realmente importa es independencia aplicación . Front-end van y vienen pero los modelos de datos perdura para siempre. En los últimos años diez aplicaciones Java han sido escritos como applets, servlets, JSP, Azulejos y caras, con los complementos en JavaScript, Groovy, AJAX y JSON, la conexión a la base de datos a través de enrollado a mano JDBC, EJB (v1,2, 3), TopLink, Hibernate y iBatis ... perdóname si me he perdido algunos. Aplicaciones cuya interfaz de usuario es una piel sobre una capa de procedimientos almacenados son más fáciles de actualizar a la última y más grande de aplicaciones en las que la lógica de negocio tiene que ser re-escrito cada vez. Y que se obtienen mejores resultados también.

Sin embargo, en las aplicaciones de largo plazo, que interactúan directamente con la base de datos son probablemente va a morir de distancia. Todo va a hablar con el bus de servicio, y que decidirá de dónde obtener los datos. Por supuesto, tiendas donde la base de datos está expuesta a través de una API bien diseñado de procedimientos almacenados pueden encontrar más fácil para pasar a este nuevo mundo de esos lugares que van a tener que extraer todo fuera de su lógica ORM.

Answer 5

Son útiles cuando se tiene un conjunto de capas de aplicaciones. Por ejemplo, un solo DB núcleo con servicios web que ofrecen las operaciones atómicas (que pasan a ser almacenado procedimientos) y un ESB o un conjunto de aplicaciones que consumen los WSS. En un caso de una sola aplicación / single-db, la idea es mantener el código en un solo lugar como otros sugirieron.

Pero bueno, eso es sólo yo.

Answer 6

Soy un largo tiempo de Java desarrollador que recientemente ha llegado a través de varios proyectos que hacen un uso intensivo de los procedimientos almacenados que han puesto el uso de procedimientos almacenados en una muy mala luz para mí.

Una vez dicho esto, me resisto a hacer una declaración general de que los procedimientos almacenados son malos como una opción de diseño del sistema, porque realmente depende del proyecto en cuestión y cuáles son los procedimientos almacenados particulares están tratando de lograr.

Yo prefiero evitar cualquier tipo de procedimiento almacenado para operaciones simples CRUD (que puede sonar ridículo a algunos procedimientos que han almacenado manejan estas operaciones, pero me he encontrado con varios sistemas que estaban haciendo esto) - esto termina resultando en una gran cantidad de código que tiene que ser escrito (y probado y mantenido) en el lado de Java para gestionar estas llamadas a procedimientos de lo que he observado. Es mejor usar solo Hibernate (o algún otro ORM) para manejar este tipo de operaciones ... si por ninguna otra razón que tiende a reducir la cantidad de código que necesita ser mantenida. También puede causar problemas cuando se trata de refactor o hacer cambios significativos al sistema, ya que no es justo tener que preocuparse de los cambios de clase / de mesa, pero los procedimientos almacenados que operaciones CRUD mango también. Y esto puede ser exacerbado aún más si estás en una situación en la que los desarrolladores no pueden realizar cambios en la base de datos a sí mismos, o si hay algún proceso formal para coordinar los cambios entre las dos partes del sistema.

Por otro lado, tiene almacenado en procedimientos que requieren una interacción limitada con el código de Java (básicamente, que acaba de encender de una llamada a uno con un par de argumentos), y ejecutar de una manera semi-autónoma no es una cosa terrible, ya sea . Me he encontrado con algunas situaciones (en particular cuando nos migrar o importar datos en un sistema), donde mediante un procedimiento almacenado era mucho ruta mejor que escribir un montón de código Java para manejar la funcionalidad.

supongo que la respuesta real aquí sería que usted debe examinar lo que cada proceso de almacenamiento en el sistema está haciendo actualmente y a evaluar sobre una base de caso por caso para determinar si tal vez es más fácil de manejar la operación en Java o la base de datos. Algunos pueden muy bien trabajar mejor en Java (ya sea por ORM, o código real escrito a mano), otros no. En cualquier caso, el objetivo debe ser siempre para asegurarse de que el sistema es comprensible y fácil de mantener para todos, no sólo si los procedimientos almacenados son buenas o malas en sí mismas.