Создание элемента — какая схема лучше?

Question

[Руслан Демидов]

Здравствуйте.
Возник вопрос реализации добавления нового элемента.

Есть два варианта:
1. Создать в базе данных элемент с значениями по-умолчанию, получить его id и отобразить пользователю диалог изменения свойств уже существующего элемента. Т.е. использовать унифицированный метод Create.
Пользователь заполнит поля, нажмёт "Сохранить" и мы просто используем метод Update.

2. Не создавать элемент, отобразить пользователю диалог изменения свойств.
Пользователь заполнит поля, нажмёт "Сохранить" и мы используем метод Create, в котором создаём элемент, заполняем свойства и сохраняем в базе данных.

Во втором варианте после нажатия кнопки "Сохранить" нам нужно будет определять - элемент уже существует или нет.
И соответственно использовать метод Create или Update.
Как бы лишнее ветвление получается.

Как быть? Какую схему лучше выбрать7

Answer 1

[d-stream]

Как-то на практике чуть удобнее получается нечто типа 2 еще и с объединенным функционалом в виде create or update в "полунеявном" виде.

То есть если объект не имеет UID, то при сохранении - это явный знак, что он "новый" и надо insert, есть - значит update

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

Answer 2

[vintage]

Совсем идеальный вариант: клиент генерирует GUID и для него создаёт свою локальную запись. Далее сразу или по нажатию кнопки "сохранить", происходит синхронизация с сервером. Если на сервере нет записи с таким GUID, то она создаётся. Если есть, то проверяются права доступа и если всё ок, то изменения применяются.

Чем это хорошо:
1. Все запросы идемпотентные (их можно безопасно повторять при затыках сети).
2. Даже у не сохранённой на сервере записи есть уникальный идентификатор, что сильно упрощает клиентскую логику.
3. Не захламляется база данных временными записями.
4. Логика работы клиента не зависит от протокола взаимодействия. Вам не нужно предварительно создавать запись, прежде чем её редактировать, не нужно иметь две различные логики работы для записей с локальными идентификаторами и с серверными. Просто создаёте записи и работаете с ними, а взаимодействие с сервером обеспечит отдельный заменяемый адаптер.
5. GUID можно генерировать сразу человекопонятным. Например, для блога это может быть "vintage/2017-03-08T12:47:33". Обратите внимание, что тут мы не позволяем создавать более одного поста в секунду. Записи, созданные в одну и ту же секунду будут одной и той же записью.
6. Вы сами решаете когда и как сохранять данные на сервер и это не навязывается вам протоколом.
7. На запись, которая ещё не сохранена, уже можно дать ссылку. Фактически создана она будет лишь после первого редактирования. Актуально для вики проектов, где вы сначала создаёте ссылку, потом по ней переходите, и только тогда уже заполняете.

Чем это плохо:
1. сквозная нумерация не представляется возможной. Но она и редко когда необходима.
2. Идентификаторы получаются относительно длинными. С другой - они могут содержать некоторую метаинформацию. Например - когда, кем и где создана.
3. В базе для GUID должна быть дополнительная текстовая колонка с уникальным индексом. Но скорее всего всё-равно у вас такая будет, когда начнёте внедрять [slug](https://ru.wikipedia.org/wiki/Семантический_URL#Slug) для человекопонятности.