¿Es bueno utilizar restricciones de comprobación para las reglas comerciales?

Question

Actualmente estamos utilizando restricciones de comprobación para la implementación de reglas comerciales, pero quiero saber si debemos implementar reglas comerciales en SQL o en la capa de lógica de negocios (C#). He buscado en la red y encontré que las restricciones de verificación son buenas para usar.

Háganme saber si alguien sabe más información detallada al respecto. Una cosa más es que los datos pueden ser bombeados a mi base de datos usando una aplicación móvil y también usando una aplicación web.

Answer 1

Sí, las restricciones de verificación son una herramienta válida para las reglas comerciales.

¿Pero está seguro de que necesita usar restricciones de verificación o utilizar una tabla de soporte con una relación de clave externa? Si se encuentra definiendo restricciones de verificación similares en varios lugares, la respuesta es sí, esto definitivamente debe ser una tabla de apoyo.

La integridad de los datos es la clave; no hay mucho valor para un sistema que le permita a una persona almacenar algo que no es por reglas comerciales si se elude la aplicación. También hace la vida mucho más fácil si la lógica está en la base de datos para situaciones donde la aplicación original está en C# y los superiores decidieron que el mercado necesita una versión de Java/Ruby/Python/etc.

Answer 2

¡Sí, es bueno!

Siempre debe verificar las reglas de su negocio tanto en el código de su aplicación (en la capa de negocios), como en su base de datos.

¿Por qué? Imagine que alguien logra enviar algunos datos a su base de datos sin usar su aplicación; si tiene sus cheques solo en la aplicación, esos cheques no se están aplicando.

Si también tiene sus verificaciones en la base de datos, puede asegurarse de que los datos en la base de datos se ajusten al menos a las comprobaciones simples que se pueden formular en SQL CHECK CONSTRAINTS.

¡Definitivamente utilícelos! Debe intentar mantener la calidad de sus datos lo más alta posible; agregar integridad referencial, restricciones de verificación y restricciones únicas, etc. en la base de datos le ayuda a hacerlo.

Do no ¡confíe solo en su aplicación!

Answer 3

Como más "inteligente" es su base de datos, más segura será la integridad de los datos que contiene. Entonces, sí, creo que esto es bueno e importante para implementarlo.

Esto ofrece muchas ventajas: puede garantizar que sus datos estarán seguros si hay más de una aplicación que modifique los datos (por ejemplo, aplicación C# + aplicación web + aplicación móvil ...) y le permiten hacer menos trabajo en esas aplicaciones "secundarias". Si la base de datos hace todo el trabajo, las aplicaciones son solo una interfaz para la base de datos.

Será más fácil en el futuro migrar las aplicaciones, pero será más difícil migrar la base de datos. Esta es una decisión importante.

Answer 4

Definitivamente debería usar restricciones CHECK siempre que sea posible, pero yo tampoco lo haría en exceso. Si no hay posibilidad de obtener datos en su base de datos sin usar sus aplicaciones, puede estar seguro con restricciones mínimas de CHEQUE y una fuerte validación comercial.

Puede ser bastante difícil definir reglas comerciales estrictas en SQL. Limítese a la validación de datos en la base de datos y a las reglas comerciales reales en su aplicación.

Además, intente organizar su esquema de forma que dificulte el ingreso de datos incorrectos con claves externas y similares.

Answer 5

depende de las limitaciones

1. Depende de las limitaciones
2. También debe tratar de evitar (si es posible) que tiene la misma restricción comprobado en 2 lugares - esto implicaría que hay duplican código en su sistema, lo que lleva a una complejidad innecesaria.

Existen algunas restricciones que pueden y deben aplicarse en la base de datos, por ejemplo, restricciones de clave externa y exclusividad. La base de datos podrá aplicar estos de forma rápida y eficiente.

Otras restricciones más complejas de "negocios" se aplican mejor en la capa de lógica de negocios. Ejemplos de esto podrían ser "el cliente debe tener una dirección de correo electrónico validada antes de permitir una compra". Sería complicado y oneroso aplicarlo en la base de datos: correría el riesgo de codificar su sistema en SQL, lo cual es una mala idea.

Answer 6

C#. Es mucho más fácil reutilizar la lógica en C# que SQL (en mi experiencia) y en general mantener.