Diseño de la base de datos: ¿se deben evitar las relaciones uno a uno?

Question

Duplicar posible:
Is there ever a time where using a database 1:1 relationship makes sense?

En aras de la simplicidad, voy a hacer la pregunta directamente: debe evitarse uno-a-uno relaciones en el diseño de base de datos o esto aceptable ?

Sé que todos los atributos de este "elemento" pueden estar alojados en UNA tabla, pero creo que al convertir el diseño de mi base de datos en objetos comerciales a través de un ORM, desordena la entidad con propiedades innecesarias.

A través de la interfaz de usuario, espero que esto le de una mejor imagen, tengo una forma principal con todos los atributos necesarios. Tendré un botón que permitirá al usuario hacer clic en él y aparecerá un nuevo formulario para adjuntar atributos adicionales. No más de 1 entrada puede estar afiliada a la forma principal (entidad), es decir, es una relación final de 0..1.

Cualquier consejo será apreciado.

Answer 1

No, una relación 1: 1 puede tener sentido.

Imagine una entidad que, opcionalmente, tiene un depósito lleno de atributos, algunas de sus entidades tienen esas, otras no.

Puede incluir todos esos atributos como columnas en su tabla de entidades, pero en ese caso, muchas columnas terminarían vacías para un número significativo de las entradas.

O: usted puede poner los "opcional" atributos en una tabla separada, establecer una relación 1: 1 (o mejor dicho: 0: 1) relación con la tabla de entidad de base, y sólo cosas de la tienda de allí si su la entidad en cuestión realmente tiene esos atributos.

Los principales criterios para decidir si se debe "externalizar" algunos atributos en una tabla separada serían:

• cuántos atributos va dirigido? Si solo es uno o dos, no haga todo lo posible para incluirlos en tablas separadas. Pero si estás hablando de 8, 10, 15, entonces considéralo

• ¿Cuántas de las entidades base pueden tener esos atributos opcionales? De nuevo: si el 95% de todas las entidades siempre tendrán todos esos atributos de todos modos, entonces no tiene sentido hacer este paso adicional.Si sólo la mitad o menos de sus entidades tendrán los atributos -> Sin duda alguna lo considere una tabla tales

Answer 2

Evitaría uno a uno. Si no hay una necesidad técnica para ello, no hay un punto. Solo está creando uniones adicionales para el db y tablas e índices adicionales para administrar. Además, el hecho de que su tabla tenga todos los campos no significa que su objeto tenga que hacerlo.

Answer 3

depende de los requisitos de aplicación

Por lo general, yo diría que uno-a-uno relaciones se modelan como columnas en la tabla, hay sin embargo circunstancias en las que esto es demasiado restrictiva:

1. el esquema cambia a menudo, y la aplicación se pueden personalizar los atributos de un objeto
2. rendimiento no es una preocupación y se está utilizando vistas a crear diseños de datos para el almacenamiento de back-end atributo abstracto

que he visto mesas donde 1-> 1 relaciones se divide en tablas en sharding verticales y bases de datos con el índice pesada requisitos.

Puede dividir y abstraer al punto que termina con algo similar a un Entity-attribute-value structure .. que no siempre es lo que quiere (complejidad añadida, rendimiento) a menos que su aplicación lo exija. Como dice marc_s, debes evitar esto cuando sea posible.

Answer 4

Si todos los artículos tendrán todos los atributos, tener una tabla generalmente tiene sentido.

Si algunos elementos solo tienen algunos de los atributos, tener varias tablas tiene sentido.

Para que el ORM sea más eficiente, algo como la recuperación de los atributos vagos puede ser útil. La cosa es que todavía es bastante raro; no se preocupe por la optimización a menos que realmente piense que será un problema. La optimización prematura no es un lugar eficiente para pasar su tiempo, por definición.

Answer 5

Hay dos escenarios en los que puede tener sentido:

• A trozo de atributos opcionales que pueden estar asociados con una entidad principal, que hace que sea un 1: [0-1] relación. Esto también se puede usar para representar campos de una subclase cuando se realiza un mapeo relacional/de objeto.
• A desnormalización del rendimiento, cuando se realiza como parte del diseño físico. Si los atributos adicionales rara vez se necesitan, se pueden derivar a una tabla separada que se puede unir si es necesario. Sin embargo, esta técnica probablemente no sea necesaria si su base de datos puede optimizar utilizando un covering index o un materialized view para crear una representación física del subconjunto de datos a los que se accede con frecuencia.