Supertipo / Subtipo que decide entre categorías: disyunción completa o superposición incompleta

Estoy construyendo una base de datos de inventario que almacena hardware de TI, como computadoras de escritorio, computadoras portátiles, conmutadores, enrutadores, teléfonos móviles, etc. Estoy usando un patrón de supertipo / subtipo, donde todos los dispositivos se almacenan en una sola tabla e información específica se pone en tablas de subtipo. Mi dilema es elegir entre los siguientes dos diseños:

En el diagrama superior, todos los dispositivos comparten subtipos comunes. Por ejemplo, las computadoras de escritorio y las computadoras portátiles tendrían registros en las siguientes tablas: Dispositivo, Dispositivo de red. Un conmutador tendría registros en: Dispositivo, Dispositivo de red. Un enrutador tendría registros en: Dispositivo, Dispositivo de red, WANDevice. Cualquier dispositivo para el que rastreemos la ubicación tendrá un registro en Ubicación. Algunos pros y contras que pensé para esta configuración:

• Pro: SELECCIONAR registros basados ​​en un campo común, como Hostname o LocationID es más fácil.
• Pro: sin campos nulos.
• Con: las tablas que deben incluirse en las operaciones CRUD para un dispositivo en particular no son obvias y pueden confundir futuros DBA.

En el diagrama inferior, todos los dispositivos tienen su propio subtipo (hay más clases de dispositivos que no se muestran aquí). En esta situación, es obvio desde qué tablas se insertan o seleccionan los registros. Las computadoras de escritorio y las computadoras portátiles van en Computadora, etc. Algunas ventajas y desventajas que pensé para esta configuración:

• Pro: es inmediatamente obvio qué tablas usar para operaciones CRUD para subtipos.
• Pro: solo tiene que usar una tabla para operaciones CRUD.
• Con: la SELECCIÓN de registros basada en campos de subtipo comunes requiere que todas las tablas se combinen, por ejemplo, buscar por Nombre de host o LocationID.

En ambas situaciones, el campo ClassDiscriminator se coloca en tablas de subtipos para usar con una restricción CHECK para controlar qué tipos se pueden insertar.

¿Hay alguna recomendación para qué diseño es mejor, o es completamente una cuestión de opinión y depende del propósito previsto de la base de datos?

EDITAR: Una pregunta específica que tengo sobre la naturaleza superpuesta de la tabla "NetworkDevice". Esta tabla está destinada a contener información de red para cualquier dispositivo con un nombre de host y / o dirección IP, ya sea una computadora, conmutador o enrutador. ¿Es la naturaleza superpuesta de esta tabla algo que podría causar problemas, o está bien implementarla de esta manera?

Gracias de antemano por cualquier aportación proporcionada. Por favor pregunte si se necesita información adicional.

La implementación física del subtipo en una base de datos es un problema complejo. A menos que tenga una situación en la que ofrezca ventajas convincentes (consulte a continuación uno o dos ejemplos), agrega complejidad a la implementación y proporciona un valor relativamente pequeño.

Habiendo hecho esto con un subtipo realmente complejo (solicitudes y sentencias en un sistema de gestión de casos judiciales, estructuras de contrato de seguro comercial de riesgo combinado dispares) Creo que tengo algunas observaciones al respecto. Algunos casos importantes de esquina son:

• Si el número total de campos de la base de datos en los subtipos es relativamente bajo (digamos: menos de 100) o hay una coincidencia significativa entre los subtipos, entonces dividir los subtipos en tablas físicas separadas probablemente sea de poco valor. Agregará una sobrecarga significativa a las consultas y búsquedas de informes. En la mayoría de los casos, es mejor tener una sola tabla y administrar su subtipo dentro de la aplicación. (Probablemente el más cercano a tu problema)

• Si su subtipo es muy disjunto, y diferentes subtipos tienen estructuras de datos dependientes del tipo que cuelgan de ellas (es decir, tablas secundarias o estructuras más complejas), entonces las tablas de subtipos tienen sentido. En este caso, cada subtipo probablemente tenga relativamente pocos elementos comunes dentro de la aplicación (es decir, probablemente haya un subsistema completo dentro de la aplicación dedicado a ese subtipo). La mayoría de los informes y consultas probablemente ocurrirán dentro de un subtipo dado, con consultas cruzadas principalmente restringidas a un puñado de campos comunes. (Sistema de gestión de casos judiciales)

• Si tiene una gran cantidad de subtipos con atributos dispares y / o un requisito para hacer esto configurable, entonces una estructura genérica y metadatos complementarios pueden ser más apropiados. Vea esta publicación SO para ver un resumen de algunos enfoques posibles. (Sistema de administración de pólizas de seguros)

• Si tiene un número muy grande de campos con poca similitud entre sus subtipos y pocos requisitos para consultar en tablas de subtipos (es decir, nada en el camino de las uniones externas de múltiples vías contra sus tablas de subtipos), entonces sub- las tablas de tipos pueden ayudar a gestionar la expansión de la columna. (Versión patológicamente compleja de su problema)

• Es posible que algunos mapeadores de O / R solo admitan un enfoque particular para administrar subclases.

En la mayoría de los casos, las tablas de subtipos físicos en un esquema de base de datos son un poco una solución en busca de un problema, ya que potencialmente tienen efectos secundarios indeseables.

En su caso, supongo que tiene un número relativamente modesto de subtipos y un número manejable de atributos. Su diagrama y pregunta no indican ninguna intención de colgar las tablas secundarias de los registros. Le sugiero que considere ir con la primera opción sugerida anteriormente y mantener una tabla y administrar el subtipo dentro de su aplicación.

Considere primero desarrollar un modelo de datos lógico sólido utilizando las reglas de jerarquía de clasificación de modelado de datos que se encuentran en Enterprise Model Patterns , un libro de David Hay. Al crear una jerarquía de clasificación, cada aparición (fila) debe ser de un solo subtipo. Esto significa que los subtipos son mutuamente excluyentes. La clasificación debe basarse en una característica única, fundamental e inmutable. El uso de esta regla básica proporcionará mucha claridad a su modelo. En el modelo que tiene, la característica única para clasificar es el propósito del dispositivo: un teléfono, un conmutador de red, una computadora, un enrutador, etc. Cada dispositivo debe ser de uno, y solo uno, de estos tipos. Entonces, por ejemplo, la ubicación no sería un subtipo. Los atributos como la dirección IP pertenecen al supertipo.

Creo que encontrará que la cantidad de tipos de dispositivos será lo suficientemente grande como para garantizar un patrón EAV como se menciona en otra respuesta. El libro de David Hay al que me refiero cubre este patrón de manera muy efectiva. Sin embargo, si el número de subtipos es pequeño, puede ser una regla general para decidir implementar solo una tabla de supertipo con muchas columnas anulables, solo tablas de subtipo con columnas duplicadas, o ambas. Si cada subtipo varía mucho en sus atributos y no tiene relaciones en el nivel de supertipo, puede elegir solo tablas de subtipo. Si lo contrario es cierto, puede elegir solo tablas de supertipo. Si hay una mezcla, entonces implemente ambos.

Finalmente, tenga en cuenta que siempre puede implementar un patrón EAV como un esquema de tabla base y luego crear una capa de abstracción de vista que presente los datos a la aplicación como tablas de super y subtipos. Esto le brinda flexibilidad en la capa de almacenamiento pero capacidad de comprensión en la capa de vista de la aplicación.

Un producto no es inventario. El inventario y los productos son distintos.

Un producto es realmente una especificación de un producto, no una cosa física.

Lo físico es un activo que la empresa posee (o almacena). Puede tener activos que rastrea por número de serie (activos discretos) o activos que rastrea solo por cantidad (activos de inventario).

Vería el Libro de recursos del modelo de datos de Silverston, Vol. 1. Tiene un buen esquema para orgullosos, características, precios, inventario. Esto le ahorrará mucho tiempo.

Una de las preguntas que haría es por qué está rastreando los diversos atributos de sus artículos de inventario - O, más específicamente, ¿qué estás haciendo con esta información de atributo?

Si tiene muchos informes o formularios que tienen un sentido específico de atributos particulares, entonces necesita usar el enfoque recomendado por ConcernedOfTunbridgeWell. Si, por otro lado, estos atributos se registran con el fin de enumerarlos, o posiblemente de compararlos con atributos similares de dispositivos similares, entonces es posible que tenga una buena excusa (rara) para usar EAV. Sé que "EAV es pura maldad" por muchas razones, excepto en casos muy raros cuando esas razones no son importantes para una aplicación específica. La suya podría ser una aplicación de este tipo.

Eche un vistazo a esta respuesta con respecto al diseño de un sistema de inventario de dispositivos y esta respuesta con respecto al diseño de un sistema de catálogo de productos para ver cómo un enfoque EAV podría simplificar su aplicación junto con una discusión sobre cuáles son exactamente los riesgos de EAV y cómo juzgue si esos riesgos pueden no aplicarse a su aplicación específica.