Блог

Я строю, где большая часть пользовательского интерфейса развивается из мастеров заполнения и заполнения форм пользователем, сосредоточенных вокруг определенной темы. В настоящее время я использую PostgreSQL с движком Hasura GraphQL на бэкэнде. Я выбрал Hasura, потому что я использую GraphQL для привлечения других источников данных, а также из-за того, насколько хорошо он справляется с событиями в Postgres. Мои требования заключаются в следующем:

1. Поскольку это стартап на ранней стадии, вопросы в этих формах, скорее всего, будут часто меняться. Вопросы могут принимать несколько различных форм, поэтому я использовал столбцы JSONB для хранения ответов.Я изо всех сил стараюсь убедиться, что модель данных не слишком сильно меняется вместе с ней, но этого следует ожидать.
2. Эти мастера отслеживают состояние, поэтому пользователь должен иметь возможность продолжить с того места, на котором он остановился, прежде чем завершить его (текущий слайд, ответы и т.д.).
3. Идея заключается в том, что как только пользователь заполняет форму, она помечается как полная, и некоторые (не все) эти данные так или иначе используются в пользовательском интерфейсе. Некоторые из вопросов больше предназначены для того, чтобы помочь пользователю/собрать дополнительную информацию.
4. поскольку большая часть пользовательского интерфейса строится на основе этих форм, следует ожидать высокой записи.

Я уже некоторое время ломаю голову, пытаясь найти лучшую модель, которая обеспечивает максимальную гибкость и при этом масштабируемость. До сих пор у меня есть эти 3 идеи:

Вариант 1 (Что я собираюсь сделать): создайте таблицу, содержащую состояние формы, включая ответы (jsonb), идентификатор пользователя и статус. Когда пользователь заполняет форму, существует логика для деконструкции столбца JSONB и заполнения других таблиц, из которых может извлекаться пользовательский интерфейс. Это обеспечивает гибкость в схеме вопросов/ответов, но я опасаюсь, что, если пользователь не заполнил форму до изменения вопроса, он останется в недопустимом состоянии (также будут дублироваться данные, занимающие место).

Вариант 1.5 заключается в использовании DynamoDB для хранения этих состояний вместо этого, что позволяет ускорить чтение/запись с помощью JSON, но добавляет больше сложности.

Вариант 2 (что я сейчас делаю): есть таблица для сохранения статуса формы и текущего слайда, а также другая таблица, которая является таблицей EAV для хранения ответов (здесь помечены атрибуты), как показано ниже:

 CREATE TABLE public.company_attribute (
    attribute_id text NOT NULL,
    company_id uuid NOT NULL,
    "attribute" jsonb NOT NULL DEFAULT jsonb_build_object(),
    form_id text NULL,
    id serial NOT NULL,
    CONSTRAINT company_attribute_pkey PRIMARY KEY (attribute_id,company_id)
);
 

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

Вариант 3 : То же, что и вариант 2, за исключением того, что вместо таблицы EAV я бы просто укусил пулю и создал таблицы для разных групп атрибутов. Из того, что я понимаю, это было бы наиболее эффективным и типичным, но было бы гораздо менее гибким и более бухгалтерским.

Я скоро запускаю этот продукт и просто хочу убедиться, что моя модель данных не повредит слишком сильно позже. Компромиссы, по сути, сводятся к производительности, гибкости и безопасности типа. Я должен отметить, что везде, где есть столбцы JSONB, я буду выполнять проверку в коде.