Я читал, что модель пары имя-значение в дизайне базы данных является анти-шаблоном. По сути, у вас есть таблица с двумя столбцами. Один столбец называется «имя», а другой - «значение». Допустим, вы управляете конфигурацией AWS для разных регионов. Структура базы данных будет такой:
name value
aws.new_york.access_key jio4j54h
aws.new_york.site.user john
aws.new_york.site.pass eoiri4iiuh
aws.los_angeles.access_key tret55464
aws.los_angeles.site.user bob
aws.los_angeles.site.pass rtry45yrt
aws.new_york.access_key fgfhgf4fdg
aws.new_york.site.user edward
aws.new_york.site.pass 45gfhgfhgf
Единственное использование - получить конфигурацию:
MyApp.config.get('aws.new_york.access_key')
Другое решение - использовать объединения. Это устранит дублирование и обеспечит ссылочную целостность. Но становится громоздко:
table_aws has_many table_states, у которого есть_many table_credentials, у которого есть столбцы access_key, user, pass. Это позволяет устранить дублирование, но представьте себе возможность увеличения количества вложенных соединений.
Учитывая мой единственный вариант использования, модель модели «имя-значение-пара» все еще является анти-шаблоном или она подойдет?
Если у вас действительно всего 3 «атрибута», тогда, конечно, таблица из 4 столбцов - это отлично: «aws.new_york» в одном столбце (или, может быть, 2?), Затем столбец для каждого из access_key
, site.user
и site.pass
. Если вы планируете время от времени добавлять дополнительные атрибуты, то создание их столбцов станет беспорядочным.
Антипаттерн, о котором вы думаете, вероятно, это Entity-Attribute-Value. Вы описываете простую «хеш-таблицу». Если в этой таблице всего сто строк или даже тысяча, проблем нет.
Но ... Вы действительно описываете EAV, за исключением того, что вы сделали его более беспорядочным.
aws.new_york.access_key
на самом деле aws.new_york
как «Сущность» и «access_key» как «Атрибут».
Обычно таблицы EAV должны состоять из 3 столбцов с PRIMARY KEY(entity, attribute)
в таком порядке.
Если ваша цель - просто хранилище для «конфигурации», то вряд ли вы будете делать запросы, которые дойдут до того места, где EAV развалится.
Итак ... Давайте посмотрим, что вы будете делать с набором данных, прежде чем выносить суждение.
В этом случае вы можете использовать однострочную таблицу со столбцом для каждого параметра.