PostgreSQL много столбцов jsonb против многих строк

Question

Из других ответов на многие столбцы и многие строки (или таблицы) кажется, что столбцы более эффективны для нормализованных данных. Как насчет сериализованных данных?

Я собираюсь хранить множество незавершенных веб-форм, т. Е. Еще не проверено только дамп того, что пользователь имеет до сих пор, чтобы они могли продолжить в другом сеансе. Формы будут сериализованы как json и сохранены в столбце jsonb. В настоящее время существует десять форм, но (много) будет добавлено в будущем.

ли лучше иметь один столбец с идентификатором пользователя и столбец для каждой формы:

CREATE TABLE "forms" (
    "user_id" uuid NOT NULL, 
    "form_a" jsonb, 
    "form_b" jsonb, 
    "form_c" jsonb, 
    ... 
) 

или нескольких строк с пользователем UUID, идентификатор формы и столбцы JSon формы:

CREATE TABLE "forms" (
    "user_id" uuid NOT NULL, 
    "form_id" uuid NOT NULL, 
    "form_json" jsonb NOT NULL 
) 

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

спасибо!

Answer 1

Если новые формы вводятся только во время обслуживания (обновления), вы можете избежать использования первого метода.

Если новые формы могут быть введены во время нормальной работы, что повлечет за собой проблемы:

• ALTER TABLE блоков и блокируется все параллельными данными модифицирующих заявления, которые могут быть проблемой.

• Для запуска ALTER TABLE вам необходимо быть владельцем таблицы или суперпользователем, но по соображениям безопасности лучше, если пользователь вашего приложения может быть кем-то другим, кроме владельца таблицы.

Увеличение объема данных для UPDATE не учитывается, потому что, как говорит the documentation:

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

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