Данные ключ-значение в приложении - PullRequest
1 голос
/ 24 августа 2011

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

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

Ответы [ 2 ]

1 голос
/ 24 августа 2011

Я бы не согласился с Тони Эндрюсом (и я проголосовал за его ответ), но я бы сказал, что, как и в случае с большинством вопросов проектирования баз данных, ответ «это зависит».

В этом случае это зависит от того, о каких значениях вы говорите здесь.Если часть «ключ-значение» в вашей системе очень общая и потенциально может использоваться для хранения практически чего угодно, особенно важных деловых фактов, то предупреждения Тони против OTLT очень хорошо приняты.

Если, с другой стороны, вы смотрите на относительно ограниченную область ключей и значений, то есть список кодов состояния, которые могут появляться в различных основных таблицах или таблицах транзакций, тогда опасности OTLTне являются серьезными.Фактически, OTLT может быть полезен при поиске кода такого типа, когда ваша система требует интернационализации, а ваши ключи дают вам разные значения в зависимости от текущего выбора языка.Имейте в виду, что эти приемлемые сценарии не являются действительно «OTLT», поскольку ваша многоцелевая таблица поиска не является универсальной .Ограничение области видимости для конкретного поиска кода это хорошо.Попытка заменить DMBS на EAV и OTLT - плохая идея по причинам, описанным Тони в его блоге.

1 голос
/ 24 августа 2011

Таблица для каждого типа - см. OTLT и EAV: две большие ошибки проектирования, которые все новички допускают для моих просмотров одной таблицы для всех поисков.

...