Diseño de base de datos: un arte o un dolor de cabeza (gestión de relaciones)

Question

He visto en mi experiencia que la mayoría de las personas no usan relaciones físicas en tablas y tratan de recordarlas y aplicarlas únicamente a través de la codificación.

Aquí 'relaciones físicas' se refieren a clave principal, clave externa, Restricciones de comprobación, etc.

bien el diseño de una base de datos, la gente trata de normalizar la base de datos en papel y mantener las cosas documentado. Por ejemplo, si tengo que crear una base de datos para una empresa de marketing, intentaré comprender sus requisitos. Por ejemplo, qué campos son obligatorios, qué campos contendrán únicamente (ao b o c) etc.

Cuando todo está claro, ¿por qué la mayoría de las personas teme las restricciones?

1. ¿No quieren administrar las cosas?
2. ¿Tienen una falta de conocimiento (que no creo que sea así)?
3. ¿No están seguros de los futuros problemas ?
4. ¿Es realmente un trabajo difícil gestionar todas estas entidades?

¿Cuál es el motivo en su opinión?

Answer 1

Bueno, es decir, todo el mundo tiene derecho a su propia opinión y el desarrollo de estrategias supongo, pero en mi humilde opinión, estas personas son casi ciertamente mal :)

La razón, sin embargo, alguien puede desear evitar restricciones es eficiencia No porque las restricciones sean lentas, sino porque el almacenamiento de datos redundantes (es decir, el almacenamiento en caché) es una forma muy efectiva de acelerar (bueno, evitar) un cálculo costoso. Este es un enfoque aceptable, cuando se implementa correctamente (es decir, el caché se actualiza a intervalos regulares/apropiados, generalmente lo hago con un desencadenador).

En cuanto a la motivación para no nosotros FKs sin una motivación de almacenamiento en caché, no puedo imaginarlo. Quizás apuntan a ser 'flexibles' en su estructura de DB. Si es así, está bien, pero luego no use una base de datos relacional, porque no tiene sentido. Los DB no relacionales (OO dbs) ciertamente tienen su lugar, e incluso podría decirse que son mejores (bastante discutibles, pero interesantes para discutir), pero es un error usar una base de datos relacional y no usar sus propiedades centrales.

Answer 2

Siempre hago que el DBMS haga cumplir las restricciones de la clave principal y de la clave externa; A menudo agrego restricciones de verificación también. En lo que a mí respecta, los datos son demasiado importantes para correr el riesgo de que se almacenen datos inexactos.

Si piensas en la base de datos como una serie de proposiciones lógicas verdaderas almacenadas, verás que si la base de datos contiene una proposición falsa, un error, entonces puedes argumentar cualquier conclusión que desees. Dada una premisa falsa, cualquier conclusión es verdadera.

¿Por qué otras personas no usan las restricciones PK y FK, etc.?

Algunos desconocen su importancia (por lo que la falta de conocimiento es definitivamente un factor, incluso un factor importante). Otros temen que les cueste demasiado rendimiento, olvidando que un error que debe corregirse puede agotar todo el tiempo que se ahorra al no hacer que el DBMS verifique por usted.Considero que si el DBMS actual no puede manejarlos bien, podría ser (probablemente) el momento de cambiar el DBMS.

Answer 3

Hay varias razones para no hacer cumplir las relaciones en orden decreciente de importancia: la gestión de errores

1. gente de usar. Su programa debe verificar las restricciones y enviar un mensaje inteligible al usuario. Por alguna razón la gente normal no tiene gusto "código de excepción de SQL -100.013 regla goble violó para la tabla gook'.

2. flexibilidad operativa. Usted no quieren realmente sus operadores tratando de averiguar qué orden se debe cargar las tablas a las 3 de la mañana, ni tampoco quiere sus probadores tirando de los pelos porque no pueden restablecer la base de datos de nuevo a su posición inicial.

3. eficiencia. limitaciones cheking no consumen IO y la CPU.

4. funcionalidad. su una forma barata de guardar los detalles para reco muy. Por ejemplo, en un sistema de pedidos en línea puede dejar las filas de elementos detallados en la tabla cuando los usuarios maten a un pedido principal, si más adelante restablece el pedido, los detalles vuelven a aparecer como por milagro: usted logra esta característica adicional mediante borrando líneas de código. (Por supuesto, necesita un proceso de limpieza, pero es trivial!)

Answer 4

Siempre definiría las restricciones PK y FK. especialmente cuando se usa un ORM. realmente hace la vida más fácil para todos permitir que el ORM haga ingeniería inversa de la base de datos en lugar de configurarlo manualmente para usar algunos PK y FK

Answer 5

Muchos desarrolladores verifican las restricciones en el código sobre la base de datos antes de que realmente vayan a realizar una operación . A veces, esto se debe a consideraciones de experiencia del usuario (no queremos presentar elecciones/opciones a los usuarios que no pueden guardarse en la base de datos). En otros casos, puede ser impulsado por el dolor asociado con la ejecución de una declaración, la determinación de por qué falló, y luego tomar medidas correctivas. La mayoría de las personas consideraría que el código es más fácil de mantener si hiciera el chequeo por adelantado, junto con otra lógica comercial que podría estar en juego, en lugar de tomar medidas correctivas a través de un manejador de excepciones. (No es que esta sea necesariamente una línea de pensamiento ideal, pero es frecuente.) En cualquier caso, si está haciendo el control antes de emitir la declaración, y no particularmente consciente del hecho de que la base de datos podría ser tocada por aplicaciones/usuarios que no ingresan a través de su código de integridad, entonces puede concluir que las restricciones de la base de datos son innecesarias, especialmente con el impacto en el rendimiento que podría derivarse de su uso. Además, si está comprobando la integridad en el código de la aplicación que se encuentra arriba de la base de datos, podría considerarse una violación de DRY (No repetir) para implementar comprobaciones lógicamente equivalentes en la base de datos. Las dos manifestaciones de las reglas de integridad (aquellas en las restricciones de la base de datos y aquellas en el código de la aplicación sobre la base de datos) podrían en principio volverse fuera de sincronización si no se gestionan cuidadosamente.

Además, no descontaría la opción 2, que muchos desarrolladores no saben mucho acerca de las limitaciones de bases de datos, con demasiada facilidad.

Answer 6

Como se consiguen las cosas se necesitan tablas y las relaciones más complejas y más en la base de datos, ¿cómo se puede garantizar el desarrollador de la base de datos para comprobar recuerda todos ellos? Cuando realiza un cambio en el esquema que agrega una nueva relación "informal", ¿cómo puede asegurarse de que se cambie todo el código de la aplicación que podría verse afectado?

De repente, podría estar eliminando registros que deberían permanecer porque tienen datos relacionados que el desarrollador olvidó comprobar al escribir el proceso de eliminación o porque ese proceso estaba en su lugar antes de que las últimas diez tablas relacionadas se agregaran al esquema.

Es extremadamente temerario no establecer formalmente relaciones PK/FK. Proceso datos recibidos de muchos proveedores y bases de datos diferentes. Puede decir cuáles tienen problemas de integridad de datos más probablemente causados ​​por una falla al definir explícitamente las relaciones por la mala calidad de sus datos.