Какова правильная практика использования уникального идентификатора(Postgres SERIAL)?

Question

[Viktoria Smirnova]

Добрый день ребята.
Какова будет правильная практика использования уникального идентификатора в моем случае?

Есть таблица с вопросами:

create table questions
(
  id    serial      not null
    constraint questions_pkey
      primary key,
  title varchar(25) not null
);

и есть таблица с ответами:

create table users
(
  question_id integer
    constraint users_question_id_fkey
      references questions,
  a           varchar(25)
);

Как Вы поняли в поле "а" вписывается ответ "no" или "yes" .

В моем бизнесе вопросы собраны в Репорт (Репорты разные. В зависимости от Репорта имеют от 10 до 70 вопросов). Таким образом ответы заходящие в таблицу user нужно разделять по Репортам.

Как это реализовать?

Мое видение проблемы создать таблицу с репортами который будет присваивать уникальный идентификатор, далее брать его и ложить в поле question_id в таблице users каждого вопроса, но это два последовательных запроса. Какова правильность этого алгоритма? Или может есть более изящное решение?

Answer 1

[Melkij]

Как Вы поняли в поле "а" вписывается ответ "no" или "yes" .

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

В моем бизнесе вопросы собраны в Репорт (Репорты разные. В зависимости от Репорта имеют от 10 до 70 вопросов). Таким образом ответы заходящие в таблицу user нужно разделять по Репортам.

Хотелось бы знать, как из первого вытекает второе.

Если у вас есть некие "репорты", состоящие из некоторого числа вопросов, а на вопросы отвечают пользователи то совершенно очевидно у вас есть:
таблица пользователей
таблица репортов
таблица вопросов с полем-ссылкой на репорт
таблица ответов из 3 полей: id пользователя, id вопроса, значение ответа. Primary key на первые два поля.