Комментарии 7
Вы рассказываете о том, что на буржуйском обычно называется Service Table. Вполне себе обычная штука.
Key-Value таблица для описываемых целей разумна только в случае, когда она индивидуальна для конкретной БД. Если создавать таблицу такого назначения уровня сервера, то используем EAV и кладём её в служебную БД (Service Database, тоже обычная штука).
На самом деле структура должна быть пошире. Весьма разумно держать в такой таблицы поля с информацией о создании (кто, когда) и сроке актуальности записи, последнее весьма способствует поддержанию чистоты в таблице. Класть эти данные в информационную часть - можно, но не очень разумно.
Натуральный ключ в такой таблице - в большинстве случаев сомнительное решение. Лучше синтетика плюс индексы.
С другой стороны, обычно записей в такой таблице не вагон. А таблица используется по варианту Записать - Найти одну запись - Удалить, никаких массированных обработок такой таблице не требуется. И тогда вполне можно пойти на KV/EAV, где информационная часть хранится в сериализованном формате (например, JSON). И даже прикрутить полнотекст.
K-V таблица - очень распространненный и древний паттерн, существоваший еще "при царе Горохе". Самый частый кейс использования (в DWH) - хранение атрибутов сущностей, которые есть у очень малого числа записей. Так же различные настройки, константы и проч. И как указал предыдущий комментатор, должна быть пошире. Как минимум выделенные колонки для разных типов + даты актуальности.
У postgres есть тип массив, в который можно запихивать редко использемые перечисления, небольшие списки, и другую подобную тему. Удобно, не надо класть текст и потом его парсить. Но не знаю, как с этим дружат популярные ORM - тогда, когда мне оно попадалось в рабочей задаче, мы сами дописывали реализацию типа под hibernate...
Как мне видится, в микросервисную архитектуру естественно вписывается большое количество маленьких таблиц; а вот для монолита паттерн может быть интересным
Божественная K-V таблица для мелочей