Наследование таблиц классов против денормализации - PullRequest
8 голосов
/ 12 апреля 2010

Я пытаюсь смоделировать специализацию / обобщение, склоняясь к использованию наследования таблиц классов (см. этот ответ ).

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

  • Ссылка на общую таблицу
  • Ссылка на таблицу с типами специализаций
  • Ссылка на таблицу, в которой хранятся значения атрибутов

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

Моя главная проблема - аномалии модификации , но кроме того, что я не вижу причин, это плохая идея. Одно решение явно превосходит другое, или мы должны просто выбрать одно и двигаться дальше?

1 Ответ

7 голосов
/ 12 апреля 2010

При разработке таблиц я обычно проектирую их с одной целью: использование.

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

Ваш вопрос на самом деле не объясняет вашего использования, поэтому все предложения в моем ответе здесь являются полным предположением. Если вы вставляете 20 тыс. Строк в день, дизайн будет отличаться от того, если вы вставите 5 строк в день. Кроме того, если вам нужно выполнить 20 000 запросов в день по любому столбцу любого типа или если вы запускаете 5 в день. это повлияет на то, как вы настроите свои таблицы.

С учетом вышесказанного общий подход может заключаться в следующем:

50+ перекрывающихся таблиц специализаций будут кошмаром для написания запросов. Я бы попытался создать 1 основную общую таблицу и, может быть, 5 или около того других общих таблиц, в которых вы могли бы немного погрузиться в «Наследование отдельных таблиц» (где у вас может быть несколько столбцов, которые не относятся к каждому типу, но включены так Вы покрываете как можно больше столбцов из максимально возможного числа типов). Оттуда закройте остальные столбцы EAV-подобным подходом.

...