Tabla "Herencia" en SQL Server

Question

Actualmente estoy en el proceso de buscar una reestructuración de nuestra base de datos de gestión de contactos y quería escuchar las opiniones de las personas para resolver el problema de una cantidad de tipos de contactos que tienen atributos compartidos.

Básicamente tenemos 6 tipos de contacto que incluyen Person, Company y Position @ Company.

En la estructura actual, todos estos tienen una dirección; sin embargo, en la tabla de direcciones debe almacenar su tipo para unirse al contacto.

Este requisito constante para unirse al tipo de contacto se vuelve frustrante después de un tiempo.

Hoy me encontré con una publicación que habla de "Tabla de herencia" (http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server).

Básicamente tiene una tabla primaria y varias tablas secundarias (en este caso, cada tipo de contacto). A partir de ahí, aplica la integridad para que una subtabla tenga un equivalente maestro donde esté definido su tipo.

De la manera en que lo veo, con este método ya no necesitaría almacenar el tipo en tablas como la dirección, ya que la identificación es única en todos los tipos.

Solo quería saber si alguien tiene algún sentimiento sobre este método, si es un buen camino a seguir, o quizás alternativas.

Estoy usando SQL Server 05 & 08 si eso hace la diferencia.

Gracias

Ed

Answer 1

Usted todavía tiene el problema de que si desea que los campos sub-tipo y tiene sólo el contacto principal, usted tiene que saber qué mesa para ir mirando - O bien únete a todos ellos. Pero de lo contrario, esta es una solución viable para un problema común.

Otra posibilidad (bastante similar en estructura, pero diferente en cómo piensas) es simplemente poner todos tus contactos en una sola tabla. Luego, para los campos más específicos (birthday decir para las personas y department para position @ company), cree tablas separadas que estén asociadas con ese contacto.

 
    Contact Table 
    -------------- 
    Name 
    Phone Number 

    Address Table 
    ------------- 
    Street/state, etc 
    ContactId 

    ContactBirthday Table 
    -------------- 
    Birthday 
    ContactId 

    Departments Table 
    ----------------- 
    Department 
    ContactId 

Se requiere una forma diferente de pensar de las cosas, aunque - en lugar de pensar de las personas frente a las empresas, se piensa en los distintos requisitos funcionales para la tarea en cuestión - si desea enviar tarjetas de cumpleaños, consiga todos los contactos que tienen cumpleaños asociados con ellos, etc.

Answer 2

Sé que esto no ayudará mucho ahora, pero inicialmente podría haber sido mejor tener una tabla Entity en lugar de 6 diferentes tipos de contactos. Entonces cada Entidad podría tener tantas direcciones como sea necesario y no habría necesidad de escribir en la unión.

Answer 3

voy a salir a un miembro aquí y sugieren que debería replantearse su estrategia de normalización (como parece ser la suerte de ser capaz de replantear su esquema bastante fundamentalmente). Si normalmente almacena una dirección para cada contacto, su tabla de contactos debe tener los campos de dirección. De forma alternativa, si la dirección se almacena por compañía, la dirección debe almacenarse en la tabla de la empresa y sus contactos deben estar vinculados a esa empresa.

Si sus contactos solo tienen una dirección, o una (o incluso 3, simplemente no 'muchas') instancias de los otros campos, piense en racionalizarlas en una sola tabla. En mi experiencia, tener algunos campos nulos es una alternativa mucho mejor que la necesidad de unir membresía a datos que no está seguro de que existan.

Afortunadamente para cualquier persona que con vehemencia no esté de acuerdo conmigo, ¡usted pidió opiniones! :) En mi humilde opinión solo debería normalizar cuando realmente necesita hacerlo. Donde esté replanteando los esquemas, se debe considerar la desnormalización en cada oportunidad.

Answer 4

Cuando tiene un 7mo tipo, tendrá que crear otra tabla.

Answer 5

Diseñé una base de datos tal como lo sugiere el enlace que proporcionó. El caso fue almacenar los datos para muchos informes técnicos diferentes. La cantidad de tipos de informes no está definida y probablemente crezca a aproximadamente 40 tipos diferentes.

Creé una tabla de informe maestro, que tiene una clave principal de autoincrementación. Esa tabla contiene toda la información común, como cliente, sitio de prueba, equipo, fecha, etc.

Luego tengo una tabla para cada tipo de informe que contiene la información específica relacionada con ese tipo de informe. Esa tabla tiene la misma clave principal que el maestro y también hace referencia al maestro.

Mi idea para dividir esto en diferentes tablas con una relación 1: 1 (que normalmente sería un no-no) era evitar obtener una sola tabla con un gran número de columnas, que se vuelve muy difícil de mantener como su constantemente agregando columnas.

Mi diseño con herencia de tablas me dio datos segmentados y capacidad de expansión sin ser difícil de mantener. Lo único que tuve que hacer fue escribir un método especial de guardar especial para manejar la escritura en dos tablas automáticamente. Hasta ahora estoy muy contento con el diseño y realmente no he encontrado ningún inconveniente, excepto por un método de guardado un poco más complicado.

Answer 6

Google en "gen-spec relational modeling". Encontrarás muchos artículos discutiendo exactamente este patrón. Algunos de ellos se centran en el diseño de la mesa, mientras que otros se centran en un enfoque orientado a objetos.

La herencia de tablas aparece en algunos de ellos.

Answer 7

Voy a probar este enfoque. Sí, debe crear tablas nuevas cuando tenga un tipo nuevo, pero dado que esta tabla probablemente tendrá columnas diferentes, terminará haciendo esto de todos modos si no utiliza este esquema.

Si las tablas que heredan el maestro no se diferencian mucho entre sí, le recomiendo que pruebe con otro enfoque.

Answer 8

Puedo sugerir que simplemente agreguemos una tabla Type. Es decir, una persona tiene una dirección, un nombre, etc. luego el estudiante, el profesor, ya que cada caso de uso se presenta. Tenemos una tabla PersonType que tiene una entrada de la tabla de personas a n tipos y las tablas nuevas siguientes maestro, extraterrestre, cantante como sistema eveolves ...