Во времена пика интереса к NoSQL базам данных простоватые K-V хранилища были несколько обойдены вниманием - отчасти это понятно, вещь не очень "инновационная", можно даже сказать старинная. В то же время своя "ниша" у них находится до сих пор (не считая того что они используются в более сложных БД в качестве индексов).

В то же время в обычной SQL-ной базе проекта порой "не хватает" такого общего K-V хранилища для разнородных (семантически) записей. В своих проектах я такую обычно завожу. Среди коллег этот подход порой вызывает негатив :)

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

Типичные ситуации

Обычно это про сущности которых по-видимому не будет много - у которых не много полей (или вообще одно) и которые не требуется дополнительно индексировать по этим полям, например (с собственного сайта):

• админские нотификации пользователям (типа "поправь то и то у себя в профиле") - они исчезают после прочтения и поэтому "постоянно" их в пределах жалких 5 штук на 50 тыщ аккаунтов

• зависимости между упражнениями в духе "решения задачи А не показывать если не решена задача Б" - таких в принципе не много т.к. задач всего штук 400 и подобных связок всего может штук 10

• "закладки" на задачи для пользователей - эту "фичу" попросили на днях и пока не факт что она много кому понадобится

• список языков (ru, es, fr...) на которые есть перевод текста данной задачи (переводы есть м.б. у полусотни задач - и переводов обычно меньше 10

• top-of-week - полтора десятка строчек с пользователями нарешавшими больше всего за последнюю неделю

• временные ключи для подтверждения / восстановления пароля

Академичный подход заключается...

Академичный подход, конечно, в том, чтобы создавать отдельные таблички - одну под нотификации, другую под зависимости, третью под переводы и так далее. У этих табличек будут понятные (по крайней мере сначала) названия, в духе:

create table admin_notifications (userid int, message text);
create table task_no_show_solution_deps (taskid int, dependent_task_id int);
create table task_bookmarks (userid int, taskid int);
create table task_translations (taskid int, lang text);
create table top_of_week (userid int, solved int);
create table password_reset (userid, temp_password text, ts timestamp)

При этом можно реализовывать и one-to-one, и one-to-many, и many-to-many ситуации, благо таблицы независимы - и по ходу эволюции проекта можно добавлять в них какие-то нужные поля и т.п.

Недостатки такого подхода - не то чтобы критичны:

• на каждую подобную мелкую фичу нужно добавлять миграцию в БД с созданием новой таблицы

• со временем получается много "мелких таблиц" однотипных по структуре, часто с небольшим количеством записей (даже порой пустых)

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

Вариант с единой K-V таблицей

Интуитивно напрашивается "вынести" название таблицы в отдельное поле и использовать одну таблицу из 3 полей:

create table stuff (id text, record_type text, value text);

в record_type предполагается записывать что-то типа adm_msg, week_top, temp_pwd и так далее - и индексом должна быть пара id, record_type.

Тут сразу видны мелкие недочёты - числовые индексы (например userid, taskid) придётся держать как строки - а record_type будет содержать много повторяющихся значений. Но это действительно мелочи пока в таблице не миллиарды записей - первый не особо аффектит вообще а второй - ну можно либо использовать короткие метки, либо сделать отдельно enum для этих значений (но enum-ам есть свои противопоказания).

Поскольку индекс составной, то в принципе почему бы не упростить таблицу до двух колонок:

create table keyval (key text, val text);

и конкатенировать "айдишник" с типом записи, в духе:

insert into keyval values ('admmsg.12345', 'Please, change your avatar');
insert into keyval values ('trans.115', 'ru fr es sk');
insert into keyval values ('bookmk.54321', '90 115 36 42');

Смысл этого подхода понятен - если для очередной фичи нужна новая простая табличка - то она уже есть - от миграций мы освободились (не считая того что с роллбэками в таблице может оставаться какой-то мусор но в большинстве случаев он никому не помешает).

Для ключей предпочтительно использовать b-tree индекс а не хэш ради того чтобы иметь возможность с его помощью выбирать сразу все значения нужной категории

select key, val from keyval where key like 'admmsg.%'

из тех же соображений "категория" идёт в начале ключа. Впрочем если уверены что вам это не потребуется, можно следовать другим соображениям :)

В то же время возможно хранение all-in-one - когда для данной категории сущностей ключ всего один и других не предвидится - например таблицу top-of-week можно хранить как один JSON по единственному ключу (всё равно она нужна только чтобы отдавать её на UI):

insert into keyval values ('weektop',
    '{["johndoe", "John X. Doe", 67], ["lyztaylor", "Elizabeth Kitty", 53], ...}');

Недостатков тут можно усмотреть немало, но остановимся на двух:

• сложность с хранением нескольких значений по одному ключу - нужно "изобретать" какой-то формат внутри "значения" - либо простой список, а может json и т.п.

• нужны отдельные усилия чтобы эффективно использовать такую таблицу в коде, особенно если используется ORM - не очень культурно если везде по коду будут разбросаны префиксы типа записи (эти admmsg и bookmk)

Однако поскольку такая таблица всего одна то большинство подобных неудобств и решаются в одном месте - вероятно появляется энум (но в коде!) с типами и утильные методы get / put которые умеют преобразовывать записи в массивы и объекты (по какому признаку они решают это делать - это уж на усмотрение автора).

Однозначно что использовать такую "гибкость" оказывается несколько легче в скриптовых языках с динамической типизацией - но в целом это мы уже углубляемся в отдельную тему schema-less хранения по которой много уже написано и копий сломано.

Показания и противопоказания, заключение

Помните, у католиков, перед "Адом" существует такая зона "Чистилище" - из неё в принципе можно попасть и в ад и в рай. Ну или зависнуть до второго пришествия.

Можно воспринимать такую K-V таблицу в составе обычной "операционной" БД именно как "Чистилище", для сущностей которые связаны с фичами и идеями нуждающимися в "дозревании".

Суть аналогии ясна - если спустя некоторое время (релиз-другой) мы поняли что "фича" и соответствующией ей записи (сущности) прочно устаканились в проекте и им будет хорошо иметь "собственную" таблицу - что ж, тогда её и сделаем. А если фича оказалась невостребованной или вообще выпилена - скорее всего и делать ничего не придётся.

В проекте давно уже пережившем "бурные времена" и вошедшем в более стабильную фазу, где изменения в схеме БД редки, как праздники - ценность подобной таблички сомнительна.

Наоборот, если проект в динамичной (а то и стартовой) фазе, а аналитики (или в целом идеолухи) приходят с новыми выдумками поразительно часто и вообще склоняются к стилю работы "а-а-а, пожар, срочно выпиливаем то что срочно добавили в предыдщем спринте" - польза от такого подхода к хранению чувствительна. Можно назвать это разновидностью "schema-as-a-code" подхода.

Отдельный юзкейс связан с кастомизацией (которую мы все обожаем) - как часто оказывается, у каждого из вариантов под разных клиентов оказываются какие-то мелкие но очень важные "ништяки" и кастомизировать миграции схемы вообще болезненно (за исключением варианта когда для всех кастомеров создаются все таблицы - и нужные и ненужные). Правда здесь уже почти наверняка можно пойти дальше и организовать полноценный no-sql отдельчик в рамках sql-ной базы (с использованием JSON-колонок и запросов например).

В целом же как и многие подобные вопросы "самой лучшей организации хранения данных" эта маленькая дилемма сводится к персональным вкусам и привычкам разработчика.