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

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

В основном у нас есть 6 типов контактов, которые включают Person, Company и Position @Company.

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

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

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

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

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

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

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

Спасибо

Ответ 1

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

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

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

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

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

Ответ 2

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

Наследование таблиц появляется в нескольких из них.

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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