¿Cuándo dividir los modelos en varias tablas de bases de datos?

Question

Estoy trabajando con Ruby on Rails, pero esta pregunta creo que es más amplia y se aplica al diseño de bases de datos en general.

¿Cuándo es una buena idea dividir un solo modelo en varias tablas? Por ejemplo, supongamos que tengo un modelo de usuario, y la cantidad de campos en el modelo realmente está empezando a sumarse. Por ejemplo, el usuario puede ingresar a su sitio web, su fecha de nacimiento, su zona horaria, etc. etc.

¿Hay alguna ventaja o desventaja al dividir el modelo, tal vez que la tabla de usuarios solo tenga información básica como inicio de sesión y correo electrónico, y luego hay otra tabla que cada usuario tiene que es algo así como UserInfo, y otra que es UserPermissions, y otra que es UserPrivacySettings o algo así?

Editar: Para agregar brillo adicional en esto, la mayoría de los campos son raramente accesibles, excepto en páginas específicas para ellos. Por ejemplo, cosas como el cumpleaños solo se acceden si alguien hace clic en el perfil de un usuario. Además, algunos de los campos (a los que rara vez se accede) tienen el potencial de ser extremadamente grandes. La mayoría de los campos tienen el potencial de ser configurados en blanco o nulos.

Answer 1

Esta sería una situación para el análisis.

Cuando usted encuentra que muchos de los campos de una tabla de este tipo son NULL, y pueden agruparse (por ejemplo. UserContactInfo), es hora de mirar a la extracción de la información para su propia tabla.

Desea evitar tener una tabla con decenas/cientos de campos con solo datos escasamente ingresados.

Más bien intente agrupar los datos lógicamente y cree la tabla principal que contiene los campos que en su mayoría están llenos. Luego puede crear subconjuntos de datos, tal como los representaría en la interfaz de usuario (información de contacto, interés personal, información relacionada con el trabajo, etc.) en tablas separadas.

Answer 2

Recuperar una fila es más caro si tiene muchas columnas, especialmente si normalmente solo necesita algunos de los campos. Además, el alojamiento de cosas tales como los componentes de una dirección en una clase separada es un caso de DRY. Por otro lado, si necesita todos los campos de un objeto, lleva más tiempo ejecutar una consulta compuesta.

Normalmente no me molestaría en distribuir clases en varias tablas solo para hacer que el código sea más legible (es decir, sin partes realmente reutilizables como direcciones).

Answer 3

En general, es una buena idea poner las cosas que tienen una relación uno-a-uno en la misma tabla. A menos que su base de usuarios incluya a Queen o Paddington Bear, un usuario solo tiene un cumpleaños, por lo que debería ser un atributo de la tabla USERS. Las cosas que tienen una relación de uno a muchos deben estar en tablas separadas. Entonces, si un usuario puede tener múltiples configuraciones de privacidad, divídalas.

La división de una tabla en varias tablas puede hacer que las consultas sean más complicadas o más lentas si queremos recuperar toda la información del usuario a la vez. Por otro lado, si tenemos un conjunto de atributos que solo se consultan o actualizan de manera discreta, tener una tabla separada para contener esos datos es una buena idea.