database - variable - procedimientos almacenados que devuelven un valor
¿Hay alguna alternativa a los procedimientos almacenados? (8)
Hibernate es un servicio de persistencia objeto / relación.
El procedimiento almacenado es una subrutina dentro de un sistema de base de datos relacional.
No es lo mismo.
Si quieres una alternativa a Hibernate, puedes buscar iBatis para Spring
¿Hay alguna alternativa a los procedimientos almacenados, seguros y rápidos, así como a los procesos almacenados? solo sé Hibernate. ¿Hay alguna otra tecnología así?
Puede hacer SQL dinámico tan seguro y rápido como lo pueden ser los procedimientos almacenados, simplemente requiere cierto trabajo. Por supuesto, lleva un poco de trabajo hacer que los procedimientos almacenados sean seguros y rápidos también.
Sí. puede usar sql dinámico, pero personalmente me gustan los procedimientos almacenados mejor.
1) Si está utilizando MS SQL Server, generará un plan de consulta que debería permitir que el procedimiento almacenado se ejecute más rápido que el simple sql dinámico.
2) Puede ser más fácil y más eficaz corregir un error en un procedimiento almacenado, especialmente si su aplicación llama a ese procedimiento en varios puntos.
3) Encuentro que es agradable encapsular la lógica de la base de datos en la base de datos en lugar de en un archivo sql o de configuración de aplicación incrustado.
4) La creación de un procedimiento almacenado en la base de datos permitirá al servidor sql hacer alguna sintaxis y verificaciones de validación en tiempo de diseño.
Los procedimientos almacenados son un lugar donde poner el código (SQL) que se ejecuta en la base de datos, así que entiendo que la pregunta sea
"¿Hay alguna otra forma de empaquetar el código que se ejecuta en la base de datos?"
Hay varias respuestas:
- No hay nada más que sea similar a un procedimiento almacenado, pero hay alternativas que podría considerar.
- Podrías escribir todos tus SQL como cadenas dentro de tu código de cliente (java o lo que sea)
- Esto tiene varios problemas (pérdida de encapsulación, acoplamiento ajustado -> mantenimiento más difícil), sin embargo, y no es una buena idea.
- Podría usar un ORM como NHibernate, que inserta una capa entre su lógica de cliente y la base de datos. El ORM genera SQL para ejecutar en la base de datos. Con un ORM, es más difícil expresar una lógica comercial compleja que en un procedimiento almacenado (generalización generalizada).
- Una especie de casa intermedia es definir su propia capa de acceso a datos (DAL) en java (o lo que sea que esté usando) y mantenerla separada del cuerpo principal del código del cliente (clases / espacios de nombres / etc.), para que su el cliente realiza llamadas al DAL, y el DAL las interpreta y envía SQL a la base de datos, devolviendo los resultados de la base de datos al cliente.
Hmm, me parece que la alternativa obvia a los procedimientos almacenados es escribir código de aplicación. En lugar de, por ejemplo, escribir un procedimiento de tienda para contabilizar un débito cada vez que se contabiliza un crédito, puede escribir el código de la aplicación que escribe ambos.
Tal vez estoy siendo demasiado simplista aquí o me falta el sentido de la pregunta.
Un procedimiento almacenado es una subrutina disponible para aplicaciones que acceden a un sistema de base de datos relacional. Los procedimientos almacenados (a veces llamados proc, sproc, StoPro o SP) se almacenan realmente en el diccionario de datos de la base de datos.
Los usos típicos para los procedimientos almacenados incluyen validación de datos (integrada en la base de datos) o mecanismos de control de acceso. Además, los procedimientos almacenados se utilizan para consolidar y centralizar la lógica que se implementó originalmente en las aplicaciones. El procesamiento grande o complejo que podría requerir la ejecución de varias sentencias SQL se traslada a procedimientos almacenados, y todas las aplicaciones llaman solo a los procedimientos.
Los procedimientos almacenados son similares a las funciones definidas por el usuario (UDF). La principal diferencia es que las UDF se pueden usar como cualquier otra expresión dentro de las sentencias de SQL, mientras que los procedimientos almacenados se deben invocar utilizando la sentencia CALL
..de Wikipedia
Creo que necesitas leer este artículo y replantear tu pregunta. Hibernate no tiene nada que ver con los procesos almacenados.
Ayudaría un poco más si dijeras por qué estás buscando alternativas, ¿qué pasa con los procesos almacenados que no te gustan?
Algunas bases de datos (por ejemplo, PostgreSQL) también le permiten escribir procedimientos almacenados en diferentes idiomas. Entonces, si realmente lo desea, puede escribirlos en Python o Java o similar, en lugar de SQL.
Creo que el OP significa que una alternativa a escribir todo su código de base de datos directamente en su código de aplicación es llamar procedimientos almacenados o introducir una capa de separación entre su código de aplicación y la base de datos usando un ORM como Hibernate, pero sí son muy cosas diferentes.
El uso de procedimientos almacenados le permite mantener su SQL en un lugar separado del código de su aplicación. El uso de Hibernate le permite evitar escribir SQL por completo y proporciona una representación de objetos de la base de datos relacional.
La forma de ir depende mucho de la aplicación y sus propias preferencias.