Agregando nuevos campos vs creando una tabla separada

Question

Estoy trabajando en un proyecto donde hay varios tipos de usuarios (estudiantes y profesores). Actualmente para almacenar la información del usuario, se usan dos tablas. La tabla users almacena la información que todos los usuarios tienen en común. La tabla teachers almacena información que solo los maestros tienen con una clave externa que la relaciona con la tabla users.

users mesa

• id
• nombre
• correo electrónico
• 34 otros campos

teachers mesa

• Identificación
• user_id
• sujetas otros
• 17 campos

En el resto de la base de datos, no hay referencias a teachers.id. Todas las demás tablas que necesitan relacionarse con un usuario usan users.id. Dado que un usuario solo tendrá una entrada correspondiente en la tabla de profesores, ¿debería mover los campos de la tabla de profesores a la tabla de usuarios y dejarlos en blanco para los usuarios que no son profesores?

p. Ej.

users

• id
• nombre
• correo electrónico
• sujetos
• 51 otros campos

Es esto demasiado muchos campos de una tabla? ¿Esto impedirá el rendimiento?

Answer 1

Creo que este diseño está muy bien, en el supuesto de que la mayoría del tiempo que solo necesita los datos user, y que sabe cuándo debe mostrar los campos específicos teacher.

Además, obtienes solo profesores simplemente haciendo un JOIN, que puede ser útil.

Mañana podría tener otro tipo de usuario que no sea un maestro, y le alegrará la separación.

Editado para agregar: sí, esto es un patrón de herencia, pero como él no dijo qué idioma estaba usando, no quería ensuciar las aguas ...

Answer 2

no será realmente duele el rendimiento, pero los otros programadores puede hacer daño si no se rediseño :) (55 mesas fielded ??)

Answer 3

En el resto de la base de datos, no hay referencias para teachers.id. Todas las demás tablas que necesitan relacionarse con un usuario usan users.id.

yo esperaría relativa a la teacher_id de clases/secciones ...

Dado que un usuario sólo tendrá una entrada correspondiente en la tabla maestros, debería simplemente mover los campos de la tabla maestros en la tabla de usuarios y dejarlos en blanco para los usuarios que no son profesores?

¿Está usted modelando un sistema para una escuela secundaria o postsecundaria? La razón por la que pregunto es porque en el nivel postsecundario, un usuario puede ser tanto un maestro como un estudiante ... en numerosas materias.

Answer 4

Lo consideraría correcto siempre que ni usted ni ninguna otra persona sucumban a la tentación de reutilizar columnas "vacías" para otros fines.

Con esto quiero decir, habrá en su nueva tabla columnas que solo están pobladas para maestros. Alguien puede decidir que hay otro valor que necesita almacenar para los que no son maestros, y usar una de las columnas del maestro para guardarlo, porque después de todo, nunca será necesario para este no docente, y de esa manera no lo hacemos necesita cambiar la tabla, y muy pronto su código se llena con cosas que prueban los tipos de fila para encontrar lo que contiene cada columna.

He visto esto en varios sistemas (por ejemplo, al prestar un libro de la biblioteca, si el préstamo es largo, la fecha de vencimiento es la fecha en que se espera el libro, pero si es un préstamo corto el vencimiento fecha tiene el tiempo esperado, y ¡ay de alguien que no lo sepa de alguna manera!).

Answer 5

No hay demasiados campos para una tabla (aunque sin ningún detalle parece sospechoso). Y preocuparse por el rendimiento en esta etapa es prematuro.

Probablemente se trate de muy pocas filas y una cantidad muy pequeña de datos. Sus preocupaciones deberían ser 1) hacer el trabajo 2) diseñarlo correctamente 3) rendimiento, en ese orden.

Realmente no es tan importante (en esta etapa/escala).

Answer 6

No rellenaría todos los campos en una tabla. La proporción de estudiantes por maestro es alta, por lo que para 100 maestros puede haber 10000 estudiantes con NULL en esos 17 campos. Por lo general, un modelo se vería cerca de esto:

que su caso, no hay campos específicos para los estudiantes, por lo que se puede omitir la tabla Student, por lo que el modelo se vería así

tenga en cuenta que para el modelado de la herencia, la tabla tiene TeacherUserID, igual que la tabla User; contraste eso con su ejemplo que tiene un Id para la tabla Teacher y luego un user_id por separado.