Таблица «Наследование» в SQL Server

Question

В настоящее время я занимаюсь реструктуризацией нашей базы данных управления контактами, и мне хотелось бы услышать мнения людей о решении проблемы с рядом типов контактов, имеющих общие атрибуты.

В основном у нас есть 6 типов контактов, которые включают Персона, Компания и Должность @ Компания.

В текущей структуре все они имеют адрес, однако в таблице адресов вы должны сохранить их тип, чтобы присоединиться к контакту.

Это непротиворечивое требование присоединиться по типу контакта через некоторое время разочаровывает.

Сегодня я наткнулся на пост, обсуждающий "Наследование таблиц" (http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server).

Обычно у вас есть родительская таблица и несколько вложенных таблиц (в данном случае каждый тип контакта). Оттуда вы обеспечиваете целостность, так что у подчиненной таблицы должен быть главный эквивалент, в котором определен ее тип.

На мой взгляд, с помощью этого метода мне больше не нужно хранить тип в таблицах, таких как адрес, поскольку идентификатор уникален для всех типов.

Я просто хотел узнать, есть ли у кого-нибудь какие-либо чувства к этому методу, хороший ли это путь или, возможно, альтернативы?

Я использую SQL Server 05 и 08, если это что-то изменит.

Спасибо

Ed

Answer 1

Я спроектировал базу данных так же, как и указанная вами ссылка. Дело было в том, чтобы хранить данные для множества различных технических отчетов. Число типов отчетов не определено и, вероятно, увеличится до 40 различных типов.

Я создал одну таблицу основного отчета с первичным ключом автоинкремента. Эта таблица содержит всю общую информацию, такую ​​как клиент, тестовый сайт, оборудование, дата и т. Д.

Тогда у меня есть одна таблица для каждого типа отчета, которая содержит специальную информацию, относящуюся к этому типу отчета. Эта таблица имеет тот же первичный ключ, что и мастер, и также ссылается на мастер.

Моя идея разбить это на разные таблицы с отношением 1: 1 (что обычно было бы «нет-нет») состояла в том, чтобы избежать получения одной таблицы с огромным количеством столбцов, которую очень трудно поддерживать, поскольку вы постоянно добавление столбцов.

Мой дизайн с наследованием таблиц дал мне сегментированные данные и расширяемость без необходимости поддерживать их. Единственное, что мне нужно было сделать - это написать специальный специальный метод сохранения для автоматической записи в две таблицы. Пока что я очень доволен дизайном и не нашел никаких недостатков, за исключением немного более сложного метода сохранения.

Answer 2

Гугл на "Реляционное моделирование". Вы найдете много статей, обсуждающих именно этот шаблон. Некоторые из них сосредоточены на дизайне стола, а другие на объектно-ориентированном подходе.

В некоторых из них появляется наследование таблиц.

Answer 3

Могу ли я предложить, чтобы мы просто добавили таблицу типов. Т.е. у человека есть адрес, имя и т. Д., А затем учащийся, учитель, поскольку каждый сценарий использования представляет себя, у нас есть таблица PersonType, в которой в качестве системы указана запись из таблицы person для n типов и последующих новых таблиц учителя, иностранца, певца. eveolves ...

Answer 4

Я собираюсь попробовать этот подход. Да, вы должны создавать новые таблицы, когда у вас есть новый тип, но, поскольку эта таблица, вероятно, будет иметь другие столбцы, вы все равно будете делать это, если не будете использовать эту схему.

Если таблицы, которые наследуют мастер, не сильно отличаются друг от друга, я бы порекомендовал вам попробовать другой подход.

Answer 5

Если у вас 7-й тип, вам придется создать еще одну таблицу.

Answer 6

Я собираюсь выйти на передний план и предложить вам переосмыслить свою стратегию нормализации (поскольку вам кажется, что вам повезло, что вы в состоянии переосмыслить свою схему совершенно фундаментально). Если вы обычно сохраняете адрес для каждого контакта, то в вашей таблице контактов должны быть поля адреса. В качестве альтернативы, если адрес хранится для каждой компании, тогда адрес должен быть сохранен в таблице компании, а ваши контакты связаны с этой компанией.

Если ваши контакты имеют только один адрес или один (или даже 3, но не «много») экземпляр из других полей, подумайте о том, чтобы объединить их в одну таблицу. По моему опыту, наличие нескольких нулевых полей - гораздо лучшая альтернатива, чем необходимость левого присоединения к данным, которых вы не уверены, существует.

К счастью для тех, кто категорически не согласен со мной, вы спрашивали мнения! :) ИМХО вам следует нормализоваться только тогда, когда вам действительно нужно. Там, где вы переосмысливаете схемы, денормализация должна учитываться при каждой возможности.

Answer 7

Я знаю, что сейчас это не сильно поможет, но изначально, возможно, было бы лучше иметь таблицу Entity, а не 6 различных типов контактов. Тогда каждый объект может иметь столько адресов, сколько необходимо, и в соединении не будет необходимости вводить тип.

Answer 8

У вас по-прежнему будет проблема в том, что если вам нужны поля подтипа и у вас есть только главный контакт, вы должны будете знать, на какую таблицу смотреть, или присоединиться ко всем из них. Но в остальном это реальное решение общей проблемы.

Другая возможность (довольно похожая по структуре, но разная в том, как вы к ней относитесь) - просто поместить все ваши контакты в одну таблицу. Затем для более конкретных полей (birthday скажем для людей и department для должности @ компания) создайте отдельные таблицы, связанные с этим контактом.

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

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

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

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

Это требует другого подхода к вещам, хотя - вместо того, чтобы думать о людях и компаниях, вы думаете о различных функциональных требованиях для выполняемой задачи - если вы хотите разослать поздравительные открытки, получите все контакты иметь дни рождения, связанные с ними, и т.д ..