Я пытаюсь смоделировать специализацию/обобщение, склоняясь к использованию наследования таблицы класса (см. этот ответ).
Однако у моего коллеги есть обслуживание и проблемы производительности, потому что будут многие (50 +) перекрывающиеся специализации той же таблицы. Его предложение состоит в том, чтобы составить таблицу со следующими столбцами:
Тем путем все атрибуты сохраняются в одной таблице и могут быть фильтрованы столбцом специализации. Я не знаю то, чем называют этот дизайн, но я волнуюсь, что он так или иначе связан с EAV...
Мое основное беспокойство является аномалиями модификации, но помимо этого я не вижу оснований, это - плохая идея. Одно решение ясно выше другого, или мы должны просто выбрать один и перемещение?
При разработке таблиц я обычно проектирую их с учетом одной вещи: использования.
Как я буду записывать туда данные и как я буду запрашивать их обратно. Я склоняюсь к чтению или записи, основываясь на том, что будет более важно для производительности, насколько часто повторяется и т.д.
Ваш вопрос не объясняет, что вы используете, поэтому все предложения в моем ответе здесь являются полной спекуляцией. Если вы вставляете 20 тысяч строк в день, дизайн будет отличаться от того, если вы вставляете 5 строк в день. Также, если вам нужно выполнять 20 тысяч поисковых запросов в день по любому столбцу любого типа или если вы выполняете 5 запросов в день, это повлияет на то, как вы настроите свои таблицы.
С учетом сказанного, общий подход может быть примерно таким:
50+ перекрывающихся таблиц специализаций будут кошмаром для написания запросов. Я бы попытался придумать 1 основную общую таблицу и, может быть, 5 или около того других общих таблиц, в которых вы можете немного поработать над "наследованием одной таблицы" (где у вас может быть несколько столбцов, которые не относятся к каждому типу, но включены, чтобы охватить как можно больше столбцов из как можно большего числа типов). После этого покройте оставшиеся столбцы с помощью подхода, подобного EAV.