Создание пустых объектов в БД или сохранить их позже

Question

У меня есть следующая таблица в моей БД:

CREATE TABLE document (
    id INT PRIMARY KEY AUTOINCREMENT, 
    productModelId INT NOT NULL, 
    comment VARCHAR(50), 
    CONSTRAINT FK_product_model FOREIGN KEY (productModelId) REFERENCES product_model(id), 
) 

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

Наши пользователи хотят видеть номер документа при нажатии кнопки «новый». Итак, для этого нам нужно создать объект в db и отправить клиенту этот объект. Но есть проблема. Нам нужно знать productModelId, прежде чем мы сохраним объект в db. В противном случае у нас будет исключение sql.

Я вижу два возможных варианты (оба некрасиво, на самом деле):

1. Чтобы показать список модального с моделями продукта для пользователя и после этого создать объект в базе данных с productModelId выбранного пользователем.

2. Чтобы создать временный номер и после этого сохранить объект в db, когда пользователь завершит редактирование документа и сохранит идентификатор. Нам также нужно удалить NOT NULL case и проверить его в коде.

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

Второй вариант является уродливым, потому что наша база данных не является согласованной без всех проверок.

Что вы можете предложить нам? Любые новые решения? Что вы делаете в своих приложениях? Возможно, некоторые подсказки пользовательского интерфейса. На данный момент мы используем первый вариант.

Answer 1

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

В настоящее время решение, которое у вас есть, является частично правильным: оно удовлетворяет техническим требованиям, но все еще плохо, потому что, если пользователь не завершит вставку, вы получите БД, имеющую пустые записи (что означает идентификатор и foreign key ok, но все остальные поля пусты или с бесполезными значениями по умолчанию), поэтому вы в основном обходите проверки базы данных.

Есть два лучших решения, но оба требуют, чтобы вы просмотрели свою базу данных.

Первый не должен использовать идентификатор как что-то отображаемое для пользователя. Используйте другой столбец с другим «id», объявите его уникальным в базе данных, сгенерируйте его в приложении, отобразите его пользователю и затем используйте этот другой «id» (если он уникален, он действительно является идентификатором), где это необходимо.

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

Оставьте использование обычного «id int» с автоматическим добавлением или нет и используйте UUID. Ваш идентификатор будет varchar или двоичным, реализация UUID (например, java.util.UUID, но вы можете найти на других языках) будет генерировать уникальный идентификатор по себе всякий раз, когда (и где бы вы ни были, например, на клиенте) он, а затем вы укажете этот идентификатор при сохранении.

Answer 2

Мы делаем это следующим образом.

Создана таблица id_requests с полями issue_type_id и lastId. Нам это нужно, чтобы избежать ситуации, когда два пользователя нажимают кнопку «новый» и получают одинаковые идентификаторы.

И, конечно, мы добавили поле innerNum для всех таблиц, которые мы используем эту функцию в.

Спасибо!