Для меня, если вы идете в один ряд или EAV, зависит от того, как вы хотите их использовать.
Сила EAV в том, что новые данные могут быть добавлены без изменений в структуре. Это означает, что если вам нужно новое значение конфигурации, вы просто добавляете его в таблицу и извлекаете его там, где хотите, в коде, и вам не нужно добавлять новое поле в запрос домена, схемы, сопоставления, запросов DAL. , и т.д.
Его недостаток в том, что он имеет только самую незначительную структуру, требующую от вас пессимистического отношения к данным. Каждое использование любого значения конфигурации должно ожидать, что значение не будет присутствовать или не в правильном формате, и вести себя соответственно, когда это не так. Значение config не может быть разборчиво в double, либо в int, либо в char. Это может быть ноль. может не быть строки для значения вообще. Обходные пути обычно требуют наличия единого действительного значения «по умолчанию» для всех значений конфигурации определенного типа в коде ( крайне редко; чаще всего значение по умолчанию столь же проблематично для потребления кода, как и вообще никакого), или сохраняйте жестко закодированный словарь значений по умолчанию (который должен меняться при каждом добавлении нового столбца, что делает основное преимущество хранилища EAV довольно спорным).
Один широкий ряд в значительной степени противоположен. Вы сопоставляете его с одним экземпляром объекта конфигурации с полем / свойством для каждого существующего значения конфигурации. Вы точно знаете, какого типа должны быть эти значения во время компиляции, и вы «быстро терпите неудачу» в DAL, если столбец конфигурации не существует или не имеет значения правильного типа, что дает вам одно место для поиска исключений на основе по поиску конфигурации / проблемы с гидратацией.
Основным недостатком является то, что для каждого нового значения требуется структурное изменение; новый столбец БД, новый столбец в DAL (сопоставление или SQL-запросы / SP), новый столбец домена, все необходимое для правильного тестирования использования.
Надлежащей ситуацией, в которой можно использовать любой из них, является ситуация, в которой недостатки устраняются. Для меня большинство ситуаций для кодирования конфигурации требовало однострочной реализации. Это происходит главным образом потому, что если вы вводите совершенно новое значение конфигурации, которое управляет поведением некоторой части вашей программы, вам уже нужно изменить код, чтобы использовать новое значение конфигурации; почему бы не перейти к объекту конфигурации и добавить значение, которое будет использоваться?
Короче говоря, схема EAV для хранения конфигурации действительно не решает проблему, которую она намеревается решить, и большинство обходных путей для проблем, которые она представляет, нарушают DRY.