PostgreSQL: столбец JSON или таблица «один ко многим» для параметров конфигурации

Question

В настоящее время у нас есть таблица, в которой хранится информация о пользователях.Некоторые из столбцов содержат информацию, такую ​​как идентификатор пользователя, имя и т. Д., Но многие другие столбцы (логические, целые числа и varchars и т. Д.) Содержат параметры конфигурации для каждого пользователя.

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

Типичный способ сделать это,Исходя из моего опыта, будет иметь новую таблицу, которая будет просто иметь option_id и option_name, и вторую новую таблицу, которая будет содержать, например, user_id, option_id, option_value.

Однако коллега предложил использовать новый тип столбца jsonb в качестве альтернативы, но я не знаю, нравится ли мне идея хранения реляционных данных нереляционным способом,С точки зрения Java, это почти то же самое, насколько я могу судить - он просто превратится в POJO, а затем будет кеширован на объекте.

Я должен упомянуть, что число пользователей будетдовольно мало, только вдаваясь в тысячи, а количество столбцов может и будет исчисляться сотнями.

У кого-нибудь есть советы по поводу лучшего пути вперед?

Answer 1

Технически, вы уже нормализовали структуру своей базы данных, добавив в таблицу столбцы, которые не имеют отношения к некоторым хранящимся в ней сущностям.

Использование JSON - это просто еще один способ отменить нормализацию, составляякуча значений в одно поле столбца-строки.Превосходная двоичная поддержка для JSON в Postgres (тип данных jsonb) позволяет затем индексировать элементы в этих документах JSON, чтобы быстро получить доступ к этим встроенным значениям.Это довольно странно с реляционной точки зрения, но в некоторых ситуациях удобно.

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

Тем не менее, вы должны рассмотреть нормализованную структуру базы данных.

Кстати, этот вопрос о структуре таблиц лучше задать на родственном сайте, http://DBA.StackExchange.com/.

Я предлагаю поискать в Stack Overflow, на этом сайте DBA и в более широком Интернете для обсуждения дизайна базы данных дляхранение пользовательских настроек.Как это .