sql >> Base de Datos >  >> RDS >> Mysql

Diseño de base de datos:¿tabla de miembros separada o todo en una tabla?

Depende mucho de cuáles sean esos "otros" detalles. Esta es una pregunta común e interesante, y no hay una respuesta "dura y rápida" a primera vista. Pero si pensamos en el problema de manera más abstracta, sobre la relación real entre los atributos ("detalles") de cualquier cosa en particular que desee representar, podemos encontrar algo de claridad.

En su pregunta, afirma que los amigos tienen detalles "mínimos" y "otros". En lugar de clasificar estos detalles como "mínimos" u "otros", clasifiquémoslos según si algún detalle individual ("atómico") puede determinarse por completo o no por lo que hace que un amigo sea único.

Supongo que hay alguna clave principal (PK), como FriendID o dirección de correo electrónico o algo así. Teniendo en cuenta este identificador único, pregúntese:"Si me dan exactamente un FriendID (o correo electrónico o lo que sea que esté usando como PK), ¿de qué detalles de ese amigo estoy absolutamente seguro? Por ejemplo, dado FriendID=2112, estoy absolutamente sé el nombre, el apellido y la fecha de nacimiento de ese amigo, pero yo no sé absolutamente el número de teléfono de ese amigo porque hay más de uno.

Agrupa en una tabla todos los detalles que conoces sin ambigüedades dado el PK. Coloque los detalles para los que necesita más datos (como "casa" o "trabajo" en el caso de los números de teléfono) en tablas "secundarias", con clave externa de vuelta a la tabla "principal" en el PK. (Nota:es muy probable que la PK de la tabla secundaria sea compuesta, es decir, compuesta por la PK de la tabla principal y el factor de diferenciación (como "casa" o "trabajo" en este ejemplo). Claves compuestas para el lado muchos Las relaciones del 1-M son muy buenas.)

Los expertos en bases de datos llaman a esta descomposición basada en dependencias funcionales .