¿Se deben aplicar las reglas comerciales tanto en el nivel de aplicación como en el de la base de datos, o solo en una de las dos?

Question

He estado aplicando reglas comerciales tanto en mi nivel de aplicación (modelos) como en mi nivel de base de datos (procedimientos almacenados que generan errores).

he estado duplicando mis validaciones en ambos lugares por varias razones:

1. Si las condiciones cambian entre cuando se comprueban en el código aplicación y cuando están comprobado en la base de datos, las comprobaciones de reglas comerciales en la base de datos guardarán el día. La base de datos también me permite bloquear varios registros de una manera más simple que en mi código de aplicación, por lo que parece natural hacerlo aquí.
2. Si tenemos hacer algunos datos del lote inserciones/actualizaciones de la base de datos directamente, si la ruta I todas estas operaciones a través de mis los procedimientos/funciones que están haciendo la regla de negocio validaciones, no hay ninguna posibilidad de que me poniendo datos erróneos a pesar de que carezco de las protecciones que obtendría si estuviera haciendo una sola entrada a través de la aplicación.
3. Mientras hacer cumplir estas cosas sólo en la base de datos de tendría el mismo efecto en los datos reales, parece inadecuada a tiro de datos en la base de datos antes de hacer primero una buena esfuerzo para validar que se ajusta a restricciones y reglas comerciales.

¿Cuál es el equilibrio correcto?

Answer 1

Debe aplicarlo en el nivel de datos para garantizar la integridad de los datos. Esa es su última línea de defensa, y ese es el trabajo de DB, para ayudar a hacer cumplir su visión del mundo de los datos.

Dicho esto, arrojar datos basura contra la base de datos para la validación es una técnica basta. Por lo general, los errores están diseñados para que sean legibles por el hombre en lugar de legibles por máquina, por lo que es ineficaz para que el programa procese el error del DB y lo destaque.

Los procedimientos almacenados son una cuestión diferente. En el pasado, los procedimientos almacenados eran la forma de manejar las reglas comerciales en los niveles de datos, etc.

Pero hoy, con los modernos entornos de servidores de aplicaciones, se han convertido, en general, en un mejor lugar para poner esta lógica. Ofrecen múltiples formas de acceder y exponer los datos (la web, los servicios web, los protocolos remotos, las API, etc.). Además, si sus reglas son pesadas en la CPU (posiblemente la mayoría no), es más fácil escalar los servidores de aplicaciones que los servidores de bases de datos.

La gran variedad de características dentro de los servidores de aplicaciones les da una flexibilidad más allá de lo que pueden hacer los servidores de DB, y así mucho de lo que una vez fue devuelto a los DBs se retira con los servidores DB relegados a " tonta persistencia ".

Dicho esto, sin duda hay ventajas de rendimiento al utilizar Stored Procs, pero ahora es una cuestión de ajuste donde la pregunta es "¿vale la pena perder la capacidad del servidor de aplicaciones por la ganancia que obtenemos al ponerlo en el servidor de base de datos? ".

Y por servidor de aplicaciones, no estoy hablando simplemente de Java, pero .NET e incluso PHP etc.

Answer 2

su lógica de negocio puede sentarse en uno u otro, pero no debe ser en ambos. La lógica NO debe duplicarse porque es fácil cometer un error al tratar de mantener ambos sincronizados. Si lo coloca en el modelo, querrá que todos los datos accedan a sus modelos, incluidas las actualizaciones por lotes.

Habrá compensaciones a ponerlo en la base de datos frente a los modelos de aplicación (aquí hay unos pocos de la parte superior de la cabeza):

• bases de datos pueden ser más difíciles de mantener y actualizar de aplicaciones
• es más fácil para distribuir la carga si es en el nivel de aplicación
• múltiples, DBS dispares pueden requerir reglas de negocio división (que puede no ser posible)

Answer 3

Si la regla debe ser impuesta en todo momento sin importar de dónde provienen los datos o cómo se actualizó, la base de datos está donde debe estar. Recuerde que las bases de datos se ven afectadas por las consultas directas para realizar cambios que afecten a muchos registros o para hacer algo que la aplicación normalmente no haría. Estas son cosas como arreglar un grupo de registros cuando un cliente es comprado por otro cliente y quieren cambiar todos los datos históricos, la aplicación de nuevas tasas impositivas a pedidos aún no procesados, la fijación de algunas entradas de datos malas. También se ven afectados a veces por otras aplicaciones que no usan su capa de datos. También pueden verse afectados por importaciones ejecutadas a través de programas ETL que tampoco pueden usar su capa de datos. Entonces, si la regla debe seguirse en todos los casos, debe estar en la base de datos.

Si la regla es solo para casos especiales sobre cómo funciona esta página de entrada en particular, entonces debe estar en la aplicación. Entonces, si un gerente de ventas solo tiene cosas específicas que puede hacer desde su interfaz de usuario, estas cosas se pueden especificar en la aplicación.

Somethings es útil hacer en ambos lugares. Por ejemplo, es una tontería permitir que un usuario ponga una fecha sin fecha en un cuadro de entrada que se relacione con un campo de fecha. El tipo de datos en la base de datos aún debe ser un tipo de datos de fecha y hora, pero es mejor verificar algunas de estas cosas antes de enviarlas.