with tutorial para framework español djangoproject con applications database database-design class-table-inheritance

database - para - tutorial django



Técnicas para la herencia de la base de datos (3)

¿Cuáles son los consejos / técnicas cuando necesita persistir las clases con herencia a la base de datos relacional que no admite la herencia?

Digamos que tengo este clásico ejemplo:

Person -> Employee -> Manager -> Team lead -> Developer -> Customer -> PrivilegedCustomer -> EnterpriseCustomer

¿Cuáles son las técnicas disponibles para diseñar la base de datos? Pros y contras de cada uno?

ps. He buscado y he encontrado varias preguntas sobre la herencia de la base de datos, pero la mayoría se trata de cambiar a un motor de base de datos que lo soporte de forma nativa. Pero digamos que estoy atrapado con SQL Server 2005 ... ¿cuáles son mis opciones?



Tenga cuidado con la herencia de la base de datos en determinadas situaciones: la implementamos en nuestra aplicación para nuestra estrategia de auditoría y terminamos con un cuello de botella de rendimiento / pesadilla.

El problema era que la tabla base que utilizamos era solo de inserción y cambiaba rápidamente, por lo que terminamos con bloqueos por todas partes. Actualmente estamos planeando dividirlos en sus propias tablas porque el dolor de cabeza de tener las mismas columnas en 15 tablas diferentes en comparación con una pesadilla de rendimiento bien vale la pena. Esto también se vio agravado por el hecho de que el marco de la entidad no maneja necesariamente la herencia de manera eficiente (este es un problema conocido de Microsoft).

De todos modos, solo pensé en compartir algunos conocimientos ya que hemos pasado por el escurridor sobre este tema.


Tres estrategias comunes:

  1. Cree una tabla para cada clase en la jerarquía que contenga las propiedades definidas para cada clase y una clave foránea de vuelta a la tabla de superclase de nivel superior. Por lo tanto, es posible que tenga una mesa de vehicle con otras mesas como car y airplane que tengan una columna vehicle_id . La desventaja aquí es que puede necesitar realizar muchas combinaciones solo para obtener un tipo de clase.

  2. Cree una tabla para cada clase en la jerarquía que contenga todas las propiedades. Esto puede ser complicado ya que no es fácil mantener una ID común en todas las tablas a menos que esté utilizando algo así como una secuencia. Una consulta para un tipo de superclase requeriría uniones contra todas las tablas en cuestión.

  3. Crea una tabla para toda la jerarquía de clases. Esto elimina uniones y uniones pero requiere que todas las columnas para todas las propiedades de clase estén en una tabla. Probablemente deba dejar la mayoría de las columnas nulables, ya que algunas columnas no se aplicarán a los registros de un tipo diferente. Por ejemplo, la tabla del vehicle puede contener una columna llamada wingspan que corresponde al tipo de Airplane . Si hace que esta columna NO sea NULA, cualquier instancia de un Car insertada en la mesa requerirá un valor de wingspan , aunque un valor de NULL tenga más sentido. Si deja la columna nulo, es posible que pueda evitar esto con restricciones de verificación, pero podría ponerse feo. ( Herencia de tabla única )