database-design - los - tipos de procedimientos almacenados
Trabajando sin procedimientos almacenados o disparadores (10)
¿Cómo recuperas datos de la base de datos? ¿Construyes SQL Strings y las ejecutas? Si es así, ¿cómo se validan las entradas que no van a destruir la base de datos? Los procesos almacenados ayudan a reducir el riesgo de esto en gran medida solo en virtud del hecho de que el texto es manejado por el servidor como texto y no como un comando.
Los procedimientos almacenados normalmente funcionan mucho más rápido que la ejecución de SQL Strings en la base de datos, también significa que no tiene que escribir diferentes selecciones para diferentes grupos de información, ya que todo puede ser realizado por el proceso almacenado. La capacidad de abstraer la base de datos del programa también es un beneficio que se ha planteado algunas veces.
Por último, realmente solo he usado desencadenadores para la auditoría de bases de datos (antes de SQL2005 no había una funcionalidad de auditoría integrada) que actualizaran las tablas con los valores previos y nuevos de cada cambio.
La normalización y la optimización no tienen nada que ver con procesos almacenados o desencadenadores, la normalización y la optimización pueden afectar la cantidad que necesita para abstraer su base de datos, pero tener que refactorizar su código cada vez que hace un cambio en la base de datos sería mucho peor que usar procesos almacenados
Hemos estado trabajando en una base de datos compleja y una interfaz de cliente durante los últimos 18 meses. Regularmente agregamos nuevas funcionalidades a esta aplicación, y ahora es utilizada por decenas de usuarios diariamente en todas nuestras oficinas, incluidos los sitios y en el extranjero. Esto es solo para decirte que es una aplicación REAL con una base de datos REAL.
Hasta ahora, todavía no teníamos que escribir ningún procedimiento almacenado, excepto temporalmente para resolver problemas menores entre las versiones de cliente y el modelo de base de datos actualizado (donde la versión anterior del cliente no actualizaba correctamente el campo recién creado, hasta que todo el mundo instalara el más nuevo versión).
De la misma manera, todavía no necesitamos ningún disparador. De hecho, los únicos SP y desencadenantes son los del sistema o los que se agregan para fines de replicación.
Tengo la extraña sensación de que los SP y Triggers se utilizan principalmente para compensar las fallas en el diseño de la base de datos y / o intentos de eludir las reglas de diseño de la base de datos cuando los desarrolladores consideran que la optimización de la base de datos tiene que oponerse a la normalización de la base de datos.
El problema es que estas herramientas consumen mucho tiempo (tanto para el desarrollo como para el mantenimiento). Cada desarrollador debe ser muy cuidadoso al usarlos, teniendo en cuenta que son los elementos más "caros" para mantener en una base de datos.
¿Podríamos considerar que tener ninguno o pocos procedimientos / desencadenantes almacenados en una base de datos es una buena indicación de su nivel de normalización y / o el costo de mantenimiento del código?
EDITAR:
Algunos de ustedes han proporcionado argumentos justos para el uso de desencadenantes y SP. Pero sigo pensando que la mayoría de las veces estas herramientas se utilizan de manera inapropiada o excesiva. ¿Cuántos desencadenadores están configurados para realizar algunas actualizaciones extravagantes entre campos de tabla, o para recalcular totales u otros datos agregados? ¿Cuántos SP se utilizan para crear tablas temporales para informar problemas? Estas son dos de las muchas situaciones en las que los desarrolladores usan estas herramientas, y creo que esto generalmente ilustra los defectos de diseño / normalización de la base de datos.
Algunos otros admiten que el uso de SP y disparadores debe controlarse estrictamente. Me parece necesario también.
Debo confesar que estoy tratando de encontrar algunos argumentos de defensa, donde todos estos frikis de SQL que trabajan en nuestras otras bases de datos nos miran, diciéndoles a sus amigos: "¿Saben qué? ¡Ni siquiera usan SP y Triggers! ¡Jaja!"
En cuanto a los procesos almacenados, no olvidemos los problemas de seguridad. Permitir que una aplicación ejecute SQL en línea significa que su cuenta de usuario necesita acceso directo de lectura, inserción, actualización y eliminación a todas las tablas. Si alguna vez hay una brecha, su base de datos queda expuesta.
Los desencadenantes tienen su lugar. Especialmente en un entorno donde hay muchos desarrolladores de bases de datos que pueden o no saber (por ejemplo) los requisitos de SOX que mantenemos un historial de cambios en la información del presupuesto.
Los procedimientos almacenados y los desencadenantes son herramientas : herramientas muy específicas para su uso dentro de un sistema de gestión de bases de datos.
Los desencadenantes tienen varios usos, desde simplificar enormemente el mantenimiento de las tablas de historial (donde cada fila representa un período pasado en el tiempo para la tabla principal) hasta las solicitudes de colas para ETL a un depósito de datos (depende del RDBMS específico)
Los procedimientos almacenados también tienen su lugar, ya sea que se invoquen desde la aplicación o desde las herramientas de línea de comandos de SQL.
La inclusión de procedimientos almacenados o desencadenantes realmente no influye en la normalización ni en los "valores predeterminados de diseño de la base de datos". Su uso en aplicaciones a menudo se relaciona directamente con otros requisitos de la aplicación, los de escalabilidad, confiabilidad, replicación u otros requisitos que pueden cumplirse de manera más efectiva mediante el uso de estas herramientas .
Si no los necesitas, no los uses. Sin embargo, no asuma que la presencia de desencadenantes o procedimientos almacenados indica un diseño deficiente.
No hay nada que odie más que encontrar un gran grupo de SQL en línea en el código que tiene un error. Al menos con un proceso almacenado puede verificar la sintaxis, o incluso ejecutarlo para ver dónde puede estar el problema. Sin mencionar que sería más rápido que solo generar consultas en el DB mientras se guarda el plan de ejecución. Durante mucho tiempo he sido de la opinión de que el código DB pertenece al DB, pero esa es solo mi opinión.
Y los desencadenantes tienen sus usos. No siempre son lo mejor, pero ciertamente están ahí por una razón.
No. Los procedimientos almacenados y desencadenantes se usan de muchas maneras diferentes. Depende de las circunstancias, los desarrolladores, etc. Por ejemplo, los procedimientos almacenados a menudo se usan como un mecanismo de seguridad.
El único lugar que he visto apto para usar un activador es cuando se refactoriza la base de datos. Entonces tal vez estás en algo con ese punto. Pero otras personas podrían usarlos de otras maneras.
Aquí hay un ejemplo donde los SP son ABSOLUTAMENTE necesarios: la interfaz de usuario es solo una pequeña parte de la aplicación completa. Y cuando todo el proceso ocurre independientemente de los usuarios. Por ejemplo, trabajo en un proyecto que implica una gran cantidad de procesamiento de datos, de muchas fuentes diferentes. Entonces, recibimos esos archivos, luego solo ejecutamos un Script Shell que simplemente lanzará un SP para importar todos los datos de los archivos, controlarlos, manipularlos, etc. ... ¿Y adivinen qué? este mismo SP puede ser utilizado TAMBIÉN por el usuario, desde la interfaz de usuario, ¡sin necesidad de volver a escribir las consultas de procesamiento de datos de nuevo!
Por supuesto, si esas consultas de procesamiento fueran simplemente SELECCIONAR, entonces podría discutir sobre la necesidad de SP, pero cuando necesita ACTUALIZAR docenas de tablas, calcular campos, depurar datos, limpiar datos, entonces los SP son bendecidos. Y no significa que nuestra base de datos carece de normalización, pero cuando procesa miles de millones de datos todos los días, no todo puede ser simple.
Tenemos un programa en el que estoy trabajando que creo que es un buen caso para los factores desencadenantes, ya que ahora hay más de 8 versiones diferentes flotando (una API y muchas versiones de interfaces y back-end). Si quiero hacer un cambio en la forma en que procesa algo, hubiera sido mucho más fácil si estuviese en un desencadenante en lugar de tener que hacer ese mismo cambio exacto en más de 8 bases de códigos diferentes (con niveles variables de codificación de espagueti) y variables mal nombradas).
¿Podríamos considerar que tener ninguno o pocos procedimientos / desencadenantes almacenados en una base de datos es una buena indicación de su nivel de normalización y / o el costo de mantenimiento del código?
No, no puedes.
La normalización y los procedimientos almacenados están completamente separados el uno del otro.
Mi opinión sobre los SP es una capa de abstracción entre la base de datos y las personas que la usan.
Obligar a las personas a utilizar el SP en lugar de las operaciones CRUD directas hará que sea más fácil cambiar el diseño de las tablas sin romperlas.
Si tiene siete aplicaciones diferentes todas hablando con la base de datos de usuarios, ¿no tendría más sentido tener un proceso almacenado llamado "createUser" en lugar de siete aplicaciones diferentes que compilan esa declaración INSERT por sí mismas?
Y ahora, una nueva aplicación, tiene que agregar usuarios a esta base de datos, pero tiene un nuevo requisito y un nuevo campo que debe agregarse, es decir, el valor predeterminado se rellena desde un valor almacenado en una base de datos de una aplicación completamente diferente.
Ahora, cambie las siete aplicaciones, más la nueva, para hablar con la aplicación de terceros y obtener el valor, mientras crea la instrucción INSERT.
O bien, puede modificar el proceso createUser de la base de datos de usuarios para buscar los datos de la base de datos de terceros como un valor predeterminado, por lo que ninguno de sus otros programas debe cambiarse y redistribuirse, ya que realmente no les importa ese valor ... todavía.
O bien, puede agregar un activador a la base de datos de los usuarios cuando se actualice la tabla de usuarios, para obtener ese valor de la base de datos de terceros.
Los procedimientos almacenados también tienen el beneficio de ser compilados y, por lo tanto, más rápidos que una declaración regular.
Los procedimientos almacenados también pueden dividir una sola instrucción sql compleja en varias declaraciones más simples para aumentar la velocidad a la que se ejecuta la consulta.
Cuando cambian los requisitos de datos, es mucho más simple modificar un proceso almacenado, que actualizar miles de instalaciones de una aplicación.
Mi $ .02
PD. No he escrito una línea de sql en una aplicación en años. Todo va en procedimientos almacenados. Ya sea una simple selección, inserción, actualización, un informe complejo o una actualización que efectivamente es un solo objeto en la aplicación, pero almacenado en 7 tablas diferentes en la base de datos.
"¿Cuántos desencadenadores están configurados para realizar algunas actualizaciones extravagantes entre campos de tabla, o para recalcular totales u otros datos agregados?"
Usar un disparador para hacer actualizaciones complejas basadas en reglas comerciales no es un defecto. Es el método preferido. Todas las reglas comerciales deben aplicarse a nivel de la base de datos si desea mantener la integridad de los datos. Hay otras maneras, además de la interfaz de usuario, para afectar los datos en la base de datos y las reglas comerciales deberían aplicarse sin importar el método utilizado. De esta forma, los datos importados tendrán que seguir las reglas, la nueva funcionalidad tendrá que seguir las reglas (en lugar de tener que recordar que hay reglas y encontrar la funcionalidad que construiste para aplicarla), personas actualizando datos a granel desde la herramienta de consulta ( piense en subir todos los precios en un 10%) tendrá que seguir las reglas, etc.
La actualización de los totales tiende a hacerse para acelerar la generación de informes si no tiene una base de datos de informes separada. ¿Desea ralentizar o bloquear toda la base de datos cuando las finanzas ejecutan sus informes trimestrales que tardan horas en ejecutarse porque tienen que calcular totales contra millones de registros? ¿O prefieres que cada cambio en los datos tome un segundo más? En general, este es un método que solo se usa cuando una base de datos se agranda y antes de que sea lo suficientemente grande como para justificar el costo de tener una base de datos de informes separada. Como tal, sí, es un recurso temporal, pero puede ser bastante necesario para mantener el negocio en funcionamiento a medida que pasa del diseño original al nuevo (se necesita bastante tiempo y un conjunto diferente de habilidades para construir un OLAP base de datos).