Как стать автором
Обновить

Комментарии 7

Вы рассказываете о том, что на буржуйском обычно называется Service Table. Вполне себе обычная штука.

Key-Value таблица для описываемых целей разумна только в случае, когда она индивидуальна для конкретной БД. Если создавать таблицу такого назначения уровня сервера, то используем EAV и кладём её в служебную БД (Service Database, тоже обычная штука).

На самом деле структура должна быть пошире. Весьма разумно держать в такой таблицы поля с информацией о создании (кто, когда) и сроке актуальности записи, последнее весьма способствует поддержанию чистоты в таблице. Класть эти данные в информационную часть - можно, но не очень разумно.

Натуральный ключ в такой таблице - в большинстве случаев сомнительное решение. Лучше синтетика плюс индексы.

С другой стороны, обычно записей в такой таблице не вагон. А таблица используется по варианту Записать - Найти одну запись - Удалить, никаких массированных обработок такой таблице не требуется. И тогда вполне можно пойти на KV/EAV, где информационная часть хранится в сериализованном формате (например, JSON). И даже прикрутить полнотекст.

Спасибо за ликбез и название :) было подозрение что подобная практика существует и даже как-то называется - но это тот случай когда из-за популярности ключевых (sql, key-value, index) слов трудно найти нужный результат. Ну теперь будет что предъявить коллегам :)

K-V таблица - очень распространненный и древний паттерн, существоваший еще "при царе Горохе". Самый частый кейс использования (в DWH) - хранение атрибутов сущностей, которые есть у очень малого числа записей. Так же различные настройки, константы и проч. И как указал предыдущий комментатор, должна быть пошире. Как минимум выделенные колонки для разных типов + даты актуальности.

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

у postgres есть тип jsonb и туда можно запихать практически что угодно и даже сделать индексы по внутренним полям

да, мне кажется во многом с появлением json в реляционных БД связано некоторое охлаждение интереса к no-sql (по-моему вслед за постгресом подтянулись и прочие даже включая mysql).

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории