IMO, наилучшим подходом будет сочетание наследования таблиц классов и EAV с некоторыми серьезными ограничениями.
EAVs подобны наркотикам: в небольших количествах и при узком стечении обстоятельств они могут быть полезны; слишком много тебя убьет. EAV как основная часть схемы завершится с ошибкой . Нет вопросов. Однако в качестве дополнения к хорошей схеме базы данных они могут быть полезны, если вы применяете надлежащие ограничения.
Основное правило с EAV - вы можете никогда написать запрос, который включает '[AttributeCol] = 'Attribute'. Другими словами, вы никогда не сможете фильтровать, сортировать, ограничивать диапазон или размещать определенный атрибут в любом месте отчета или формы. Это просто пакет данных, который можно выложить в отчете или на экране в списке. На самом деле, я видел, как люди реализовывали эту функцию в виде столбца Xml.
Если вам удастся сохранить это ограничение, то вы можете добавить структуру EAV в схему наследования таблиц классов, чтобы позволить пользователям добавлять набор атрибутов в продукт только для целей хранения. В тот момент, когда они хотят выполнить любую из verboten задач с атрибутом, он должен стать столбцом первого класса, и все, что влечет за собой.
Ключ находится в принудительном порядке. Если вы не чувствуете, что можете разумно применять или заставить других разработчиков применять это ограничение на использование структуры EAV, то имеет смысл пропустить это. Однако если вы сможете применить это ограничение, это может решить проблему людей, желающих добавить тонны атрибутов просто для целей хранения и отслеживания.