Методы наследования базы данных?

Каковы советы/методы, когда вам нужно сохранять классы с наследованием реляционной базы данных, которая не поддерживает наследование?

Скажем, у меня есть этот классический пример:

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

Каковы доступные методы проектирования базы данных? Плюсы и минусы каждого?

p.s. Я искал и нашел несколько вопросов о наследовании базы данных, но большинство из них касалось изменения на механизм базы данных, который поддерживает его изначально. Но позвольте сказать, что я застрял с SQL Server 2005... какие у меня варианты?

Ответы

Ответ 1

Три общих стратегии:

  • Создайте таблицу для каждого класса в иерархии, которая содержит свойства, определенные для каждого класса, и внешний ключ обратно в таблицу суперкласса верхнего уровня. Таким образом, у вас может быть таблица vehicle с другими таблицами, такими как car и airplane, которые имеют столбец vehicle_id. Недостатком здесь является то, что вам может потребоваться выполнить много соединений, чтобы получить один тип класса.

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

  • Создайте одну таблицу для всей иерархии классов. Это исключает объединения и объединения, но требует, чтобы все столбцы для всех свойств класса были в одной таблице. Вероятно, вам нужно оставить большинство столбцов нулевыми, поскольку некоторые столбцы не будут применяться к записям другого типа. Например, таблица vehicle может содержать столбец с именем wingspan, который соответствует типу airplane. Если вы сделаете этот столбец NOT NULL, то любой экземпляр car, вставленный в таблицу, потребует значение для wingspan, хотя значение NULL может иметь больше смысла. Если оставить столбец нулевым, вы можете обойти это с помощью проверочных ограничений, но он может стать уродливым. (Наследование отдельных таблиц)

Ответ 2

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

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

В любом случае, просто подумал, что я поделюсь некоторыми знаниями, так как мы прошли через эту проблему.