¿Son necesarias restricciones únicas en el DB?

Question

Me he estado preguntando últimamente. Digamos que estamos haciendo una aplicación web con JSF + Spring + JPA/Hibernate (o cualquier otra tecnología) y digamos que tenemos una entidad de "Usuario". Queremos que el Usuario tenga un inicio de sesión único. Si queremos hacerlo, podemos poner @UniqueConstraint en la columna "Iniciar sesión", pero nuestra aplicación debe verificar durante el registro del usuario si la entrada del usuario es válida (única) o no, sin eso y solo con la restricción DB. simplemente obtendremos un error. Esto me hizo pensar, ¿son realmente necesarias/útiles las limitaciones de DB? Las dos únicas veces que puedo pensar cuando nos darían algún beneficio sería cuando alguien intenta piratearnos (pero supongo que nuestra aplicación debe ser a prueba de inyección SQL) o intentamos cambiar el contenido de la base de datos manualmente (lo que no debería realmente sucede). En realidad, ahora que lo pienso, ¿son las limitaciones de DB en general necesarias/buenas prácticas? Al igual que la longitud de una cadena etc.

Answer 1

Para mí, categóricamente sí, ver Database as a Fotress por Dan Chak de 97 piensa Cada arquitecto de software debe saber. Él lo dice mucho mejor que yo.

Answer 2

Sí, lo son. Imponen la integridad de los datos en el nivel más bajo.

Es posible que desee cambiar el contenido DB manualmente (es decir, las actualizaciones a nuevas versiones)

Es posible que se olvide de comprobar algunos restringen en su código.

Puede ver esto como la validación cliente/servidor. Tu programa es cliente, db es servidor. En su mayoría, la validación del cliente es suficiente, pero debe tener la validación del servidor en caso de que algo salga mal.

Answer 3

Creo que una persona de datos diría que ambas son absolutamente necesarias. Su pregunta asume que su código de aplicación de nivel medio estará delante de esa base de datos ahora y para siempre.

Lo cierto es que las aplicaciones de nivel medio aparecen y desaparecen, pero la información permanece para siempre.

No hay forma de alejarse de la longitud de las columnas en el diseño del esquema. Creo que estás preguntando si es una buena práctica para el nivel medio hacerlos valer. Quizás no, pero son clave para la base de datos.

Answer 4

A menudo, cuando declara que un conjunto de columnas es único, es algo por lo que querrá consultar, por lo que lo más probable es que esté indexado.

Sí, su aplicación debería hacer la comprobación adecuada, pero ¿qué ocurre si se produce un error? Si su base de datos sabe que algo debe ser único, al menos sabe que no almacenará datos no válidos (o datos inválidos "incorrectos", como duplicados de datos destinados a ser únicos). En cualquier caso, podría hacer la pregunta opuesta: ¿cuánto le cuesta?

Answer 5

Las restricciones, tanto únicas como extranjeras, no solo imponen la integridad de los datos, sino que también tienen implicaciones de rendimiento. Sin el conocimiento de estas constantes "informales", los optimizadores de bases de datos van a tomar decisiones impredecibles sobre cómo ejecutar sus declaraciones.

Answer 6

Si desea tener datos incorrectos, elimine las restricciones exclusivas de la base de datos. He trabajado en bases de datos desde la década de 1970 y he consultado o importado datos almacenados en cientos de bases de datos. Nunca he visto buenos datos en las bases de datos donde las restricciones se establecen incorrectamente en el nivel de la aplicación. Muchas cosas, además de la aplicación, llegan a la base de datos (importaciones de otros sistemas, una actualización rápida para pinchar datos para solucionar un problema de datos que se ejecuta desde la ventana de consulta, otras aplicaciones, etc.). Muchas veces la aplicación se reemplaza y las restricciones se pierden.

Answer 7

pero todavía tiene nuestra aplicación para comprobar durante el registro de usuario si la entrada usuario es válido (único) o no, sin que y sólo con la restricción DB simplemente obtendrá un error .

Eso es lo más divertido que he leído en mi vida. ¿Simplemente obtienes un error? Eso es todo lo que necesitas, ¿verdad? ¿Has oído hablar de trampas de errores? Intenta llamar a Catch ring campanas?

En realidad, es muy contraproducente para su aplicación "verificar". La base de datos comprobará de todos modos la restricción, entonces, ¿por qué hacerlo dos veces? La aplicación solo debe insertar la fila como si estuviera bien. El DB verificará la exclusividad y generará un error en caso de falla ... Su aplicación debería RECOGER ese error y hacer lo que esté haciendo en su cheque existente.

Answer 8

Sí. Simplemente capte el error de violación de clave y la restricción de clave habrá hecho el trabajo por usted sin tener que incurrir primero en una sobrecarga adicional de un cheque adicional.