¿Dónde deberían estar las consultas de la base de datos en vivo?

¿Deberían las consultas vivir dentro de las clases que necesitan los datos? ¿Deben las consultas vivir en procedimientos almacenados en la base de datos para que sean reutilizables?¿Dónde deberían estar las consultas de la base de datos en vivo?

En la primera situación, cambiar sus consultas no afectará a otras personas (ya sea otro código o personas que generan informes, etc.). En el segundo, las consultas son reutilizables por muchos y solo existen en un solo lugar, pero si alguien las rompe, se rompen para todos.

Fuente

2009-10-01 Buns of Aluminum

Solía ser grande en la solución de proceso almacenado, pero he cambiado mi tono en el último año a medida que las bases de datos se han vuelto más rápidas y los ORM han ingresado a la transmisión principal. Sin duda hay un lugar para procs almacenados. Pero cuando se trata de CRUD sql simple: un liner insert/update/select/delete, usar un ORM para manejar esto es la solución más elegante en mi opinión, pero estoy seguro de que muchos discutirán de otra manera. Un ORM tomará la conexión de SQL y DB que construye la plomería fuera de su código y hará que la lógica de persistencia se integre de manera mucho más fluida con su aplicación.

Fuente

2009-10-01 23:08:05

+1. Las mejoras de ORM han hecho que el argumento del procedimiento almacenado por rendimiento sea menos relevante. Dejando a un lado las cuestiones de rendimiento, me gusta el código posicionado de la manera que mejor te permita actualizar y mantener en el futuro. – jro

Esto es excelente para CRUD, pero ¿qué pasa con las consultas más complejas que acceden a varias tablas? ¿Qué pasa con el acceso a las tablas que no tienen claves principales (y estás atrapado porque pertenecen a un proveedor externo)? –

Estás en lo correcto, Señor. Un ORM no se puede usar para cada escenario. En los casos que describes, los procesos almacenados pueden ser una mejor ruta. Sé que los ORM líderes proporcionan soporte para procs almacenados pero no tienen mucha experiencia en trabajar con ellos a través de un orm. –

Sugiero colocarlos como procedimientos almacenados en la base de datos. No solo tendrá la ventaja de reutilización, sino que también se asegurará de que la misma consulta (sea una selección, actualización, inserción, etc.) sea la misma porque está utilizando el mismo procedimiento almacenado. Si necesita cambiarlo, solo lo cambiará en un solo lugar. Además, aprovechará la capacidad de procesamiento del servidor de la base de datos en lugar del servidor/computadora donde reside su aplicación. Esa es mi sugerencia.

¡Buena suerte!

Fuente

2009-10-01 23:02:23

Acuerde con Matt sobre el uso de ORM si solo necesita tener CRUD simple. Sin embargo, si necesita usar procedimientos almacenados, déjelos en el servidor de la base de datos, ahí es donde pertenecen. –

Depende/es situacional. Hay argumentos muy fuertes a favor y en contra de cualquier opción. Personalmente, realmente no me gusta ver que la lógica de negocios se divida entre la base de datos (en procedimientos almacenados) y en el código, por lo que generalmente quiero todas las consultas en código en la mayor medida posible.

En el mundo de Microsoft, hay cosas como Reporting Services que pueden recuperar datos de clases/objetos en lugar de (y además de) una base de datos/procedimientos almacenados. Además, hay cosas como Linq que le dan consultas más fuertemente tipadas en el código. También hay ORM fuertes y maduros como NHibernate que permiten escribir prácticamente todo tipo de consultas desde el código.

Dicho esto, todavía hay momentos en los que está haciendo cosas de "conjunto de filas" con sus consultas que funcionan mucho mejor en un procedimiento almacenado que lo que funcionan desde el código.

En la mayoría de las situaciones, cualquiera/ambas opciones funcionan bien.

Fuente

2009-10-02 08:45:37

Desde mi punto de vista, creo que los procesos almacenados son el camino a seguir. En primer lugar, son más fáciles de mantener ya que un cambio rápido a uno significa simplemente ejecutar el script sin recompilar la aplicación. En segundo lugar, son mucho mejores para la seguridad. Puede establecer permisos en el nivel sp y no directamente en las tablas y vistas. Esto ayuda a evitar el fraude porque los usuarios no pueden hacer nada directamente a la base de datos que no esté especificado en un proceso almacenado. Son más fáciles de interpretar. Cuando utiliza procs almacenados, puede usar los metadatos de dependencia de la base de datos para ayudar a determinar el efecto de los cambios de la base de datos en la base de códigos. En muchos sistemas, no todas las operaciones de acceso a datos o incluso CRUD tendrán lugar a través de la aplicación, ya que el código allí me parece contraproducente. Si todo el acceso a los datos está en un solo lugar (una idea que yo apoyo), debería estar en la base de datos donde sea accesible para todas las aplicaciones o procesos que puedan necesitar usarlo.

He encontrado que los programadores de aplicaciones a menudo no consideran la mejor manera para que una base de datos procese información, ya que se centran en la aplicación y no en el servidor. Al colocar el código para la base de datos en la base de datos a la que pertenece, es más probable que los especialistas en bases de datos lo vean y revisen, quienes consideran la base de datos y su rendimiento.Apoyamos cientos de bases de datos y aplicaciones aquí. Puedo buscar en cualquier base de datos y encontrar el código que necesito encontrar cuando algo es lento. No tengo que cargar el código de la aplicación para cada una de las cientos de aplicaciones diferentes solo para ver la parte que necesito para hacer mi trabajo.

Fuente

2009-10-02 13:18:03 HLGEM

¿Dónde deberían estar las consultas de la base de datos en vivo?

Respuesta

Cuestiones relacionadas