¿Procedimientos almacenados o consultas en línea?

Question

En primer lugar, hay un pregunta parcial con respecto a esto, pero no es exactamente lo que estoy preguntando, así que tengan paciencia conmigo.

Mi pregunta es, después de ver lo que hace SubSonic y los excelentes videos de Rob Connery que necesito preguntar: ¿Usaremos una herramienta como esta y realizaremos consultas en línea o haremos las consultas utilizando una llamada al procedimiento almacenado?

No quiero minimizar ningún trabajo de Rob (lo que creo que es increíble), pero solo quiero tu opinión sobre esta causa. Necesito comenzar un nuevo proyecto y estoy en la mitad de la línea; ¿Debo usar SubSonic (u otra herramienta similar, como NHibernate) o simplemente continúo con mi método que siempre es un procedimiento almacenado, incluso si es tan simple como

Select this, that from myTable where myStuff = StackOverflow;

Answer 1

No necesita ser uno u otro. Si es una consulta simple, use la herramienta de consulta SubSonic. Si es más complejo, use un procedimiento almacenado y cargue una colección o cree un conjunto de datos a partir de los resultados.

Consulte aquí: ¿Cuáles son los pros y los contras de mantener SQL en Procesados ??almacenados versus código y aquí SubSonic y Procedimientos almacenados

Answer 2

Ver las respuestas aquí y aquí . Utilizo sprocs siempre que puedo, excepto cuando la burocracia significa que tarda una semana en ingresar a la base de datos.

Answer 3

Los procedimientos almacenados son dorados cuando tiene varias aplicaciones que dependen de la misma base de datos. Le permite definir y mantener la lógica de consulta una vez, en lugar de varios lugares.

Por otro lado, es bastante fácil que los procedimientos almacenados se conviertan en un gran desorden en la base de datos, ya que la mayoría de los sistemas no tienen un buen método para organizarlos de forma lógica. Y pueden ser más difíciles de versionar y rastrear cambios.

Answer 4

Yo personalmente no seguiría reglas rígidas. Ciertamente, durante las etapas de desarrollo, usted desea poder cambiar rápidamente sus consultas para que yo las incorpore.

Más adelante, me movería a los procedimientos almacenados porque ofrecen las siguientes dos ventajas. Estoy seguro de que hay más, pero estos dos me ganan.

1 / Los procedimientos almacenados agrupan los datos y el código para manipular / extraer esos datos en un punto. Esto hace que la vida de su DBA sea mucho más fácil (suponiendo que su aplicación sea lo suficientemente grande como para garantizar un DBA), ya que pueden optimizar en función de factores conocidos.

Uno de los grandes errores de un DBA son las consultas ad hoc (especialmente por los payasos que no saben qué es un escaneo de tabla completa). Los DBA prefieren tener consultas agradables y coherentes a las que puedan ajustar la base de datos.

2 / Los procedimientos almacenados pueden contener la lógica que es mejor dejar en la base de datos. He visto procs almacenados en DB2 / z con muchas docenas de líneas, pero todo lo que el cliente tiene que codificar es una sola línea como "dame esa lista".

Porque la lógica para " esa lista " se almacena en la base de datos, los DBA pueden modificar la forma en que se almacenan y extraen a voluntad sin comprometer o cambiar el código del cliente. Esto es similar a la encapsulación que hizo a los lenguajes orientados a objetos "más limpios" que lo que vino antes.

Answer 5

He hecho una mezcla de consultas en línea y procedimientos almacenados. Prefiero más del enfoque de vista / procedimiento almacenado, ya que gana un lugar agradable para que pueda realizar un cambio si es necesario. Cuando tiene consultas en línea, siempre tiene que ir y cambiar el código para cambiar una consulta en línea y luego volver a tirar la aplicación. También puede tener la consulta en línea en varios lugares, por lo que tendría que cambiar mucho más código que con un procedimiento almacenado.

Nuevamente, si tiene que agregar un parámetro a un procedimiento almacenado, de todos modos todavía está cambiando mucho código.

Otra nota es la frecuencia con la que los datos cambian detrás del procedimiento almacenado, donde trabajo, tenemos tablas de terceros que pueden dividirse en tablas normalizadas, o una tabla se vuelve obsoleta. En ese caso, un procedimiento / vista almacenado puede minimizar la exposición que tiene a ese cambio.

También he escrito una aplicación completa sin procedimientos almacenados. Tenía tres clases y 10 páginas, no valía nada. Creo que llega un momento en el que es excesivo o puede justificarse, pero también se reduce a su opinión y preferencia personal.

Answer 6

¿Solo accederás a tu base de datos desde esa única aplicación?

Si no es así, es probable que esté mejor utilizando los procedimientos almacenados para poder tener una interfaz consistente con su base de datos.

¿Hay algún costo significativo para distribuir su aplicación si necesita hacer un cambio?

Si es así, es probable que esté mejor utilizando los procedimientos almacenados que se pueden cambiar en el servidor y esos cambios no tendrán que ser distribuidos.

¿Está preocupado por la seguridad de su base de datos?

Si es así, es probable que desee utilizar procedimientos almacenados para no tener que otorgar acceso directo a las tablas a un usuario.

Si está escribiendo una aplicación pequeña, sin una amplia audiencia, para un sistema que no se usará o accederá fuera de su aplicación, entonces el SQL en línea podría estar bien.

Answer 7

Con Subsonic, utilizará procedimientos en línea, vistas y almacenados. Subsonic facilita el acceso a los datos, pero no puede hacer nada en una consulta subsónica. Aunque la última versión, 2.1 está mejorando.

Para las operaciones básicas de CRUD, el SQL en línea será sencillo. Para necesidades de datos más complejas, se deberá realizar una vista y luego se realizará una consulta subsónica en la vista.

Los procesos almacenados son buenos para los cálculos de datos más difíciles y la recuperación de datos. La recuperación basada en conjuntos suele ser siempre más rápida que el proceso procesal.

La aplicación actual Subsonic utiliza las tres opciones con excelentes resultados.

Answer 8

Prefiero inline sql a menos que el procedimiento almacenado tenga lógica real (variables, cursores, etc.) involucrada. He estado usando LINQ to SQL últimamente, y tomando las clases generadas y agregando clases parciales que tienen algunas consultas linq comunes y predefinidas. Siento que esto hace que el desarrollo sea más rápido.

Edit: Sé que me van a quedar mal por esto. Si alguna vez habla sobre claves externas o procedimientos almacenados, se modificará. Los DBA necesitan seguridad laboral, supongo ...

Answer 9

Las ventajas del procedimiento almacenado (en mi opinión)

1. El SQL está en un solo lugar
2. Puede obtener planes de consulta.
3. Puede modificar la estructura de la base de datos si es necesario para mejorar el rendimiento
4. Se compilan y, por lo tanto, esos planes de consulta no tienen que construirse sobre la marcha
5. Si usa permisos, puede estar seguro de las consultas que realizará la aplicación.

Answer 10

1. Los procedimientos almacenados agrupan los datos y el código para manipular / extraer esos datos en un punto. Esto hace que la vida de su DBA sea mucho más fácil (suponiendo que su aplicación sea lo suficientemente grande como para garantizar un DBA), ya que pueden optimizarse basándose en factores conocidos.

2. Los procedimientos almacenados pueden contener la lógica que es mejor dejar en la base de datos. He visto procs almacenados en DB2 / z con muchas docenas de líneas, pero todo lo que el cliente tiene que codificar es una sola línea como "dame esa lista".

3. la mejor ventaja de usar procs almacenados que encontré es que cuando queremos cambiar la lógica, en caso de una consulta en línea, necesitamos ir a cualquier lugar, cambiarlo y volver a tirar todas las aplicaciones, pero en el el caso del cambio de proceso almacenado se requiere solo en un lugar.

Entonces use las consultas en línea cuando tenga una lógica clara; de lo contrario preferiremos los procesos almacenados.