Datos relacionales: enfoques de herencia de entidad. Mejor práctica

Question

Existen varios enfoques para almacenar jerarquía de entidades en la base de datos de relaciones

Por ejemplo, hay entidad de persona (20 atributos básicos), entidad de estudiante (la misma persona pero varios campos específicos nuevos están presentes), empleado (lo mismo que la persona, pero algunos campos nuevos están presentes), etc.

Cuando consejo a utilizar (y no utilizar) el siguiente modelo de datos se acerca:

• Una mesa grande con todas las posibles + personType campo marcador de campos (estudiante o empleado)
• Tabla herencia
• una tabla con el campo XML (o tal vez otro tipo de datos) para almacenar todos los campos personalizados
• algo más, pero también relacionales ...

¡Gracias de antemano!

Answer 1

Una base de datos modela hechos, no objetos, y cada tabla debe modelar un conjunto relativamente independiente de hechos. La consecuencia de esto es que las tablas deben ser algo como esto:

person { person_id PK, name, dob, ... } 
student { person_id PK FK(person.person_id), admission_id, year_started, ... } 
employee { person_id PK FK(person.person_id), salary_bracket, ... } 

Una consecuencia adicional es que un estudiante también puede ser un empleado, lo que probablemente modelos de la vida real más cerca que un gráfico de la herencia lo haría.

Answer 2

Eche un vistazo a hibernate inheritance mapping docs. Allí encontrará tres enfoques comunes y una lista de pros y contras de cada uno.

Answer 3

Si está utilizando un ORM para implementar sus clases, las herramientas ORM que está utilizando le proporcionarán opciones, generalmente dos opciones, una tabla de clase uno o una tabla de clase uno y cada tabla para cada clase secundaria. Estoy usando XPO de Devexpress.com, un marco ORM. Ofrece estas dos opciones.

Si usa ORM, me temo que no hay otras opciones genéricas.

Ying