что делать, когда нам может понадобиться сначала сохранить ведомые данные

Question

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

• резервирование идентификатора строки мастера, чтобы я мог сохранить данные de slave с зарезервированным идентификатором мастера
• сохранить ведомые данные во временной таблице, чтобы при сохранении основных данных мы могли «импортировать» данные во временную таблицу
• другой ??

Пример в форме заявки / загрузки нескольких файлов, где пользователи могут загружать файлы перед отправкой информации о билете:

Мастер стол PK описание билета

Рабочий стол PK Master_FK Файл

Answer 1

Ваш идентификатор автоматически сгенерирован?

У вас есть несколько вариантов с возможными проблемами.

Сначала не определяйте отношения ФК. Теперь, как вы учитываете записи в частичном состоянии и тех, кто никогда не вступал в брак с реальной записью? И как вы собираетесь объединить записи, когда основная запись вставлена?

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

Третий и самый сложный, но, вероятно, самый безопасный - используйте 3 таблицы. Создайте основную запись в таблице, которая содержит только основной идентификатор записи, и верните ее в свое приложение при открытии формы для создания новой записи. Создайте отношение pk / fk как к основной таблице, так и к таблице внешнего ключа. Удалите автогенерацию идентификатора из исходной основной таблицы и вставьте идентификатор из новой основной таблицы при вставке записи. Вставьте новый идентификатор основной таблицы, когда вы вставляете записи в оригинальную таблицу FK. По крайней мере, таким образом, вы можете продолжать помечать все обязательные поля в базе данных как обязательные, но связь между новой таблицей и другой таблицей не связана с исходной таблицей и другой таблицей. Это не повлияет на запросы (если у вас есть правильная индексация), но усложнит ситуацию, если вы удалите записи, так как вы можете оставить некоторые из них, если не будете осторожны. Также вам нужно будет рассмотреть, есть ли другие процессы (такие как импорт данных из другого источника), которые могут вставлять записи в основную таблицу, которые должны быть скорректированы, так как идентификатор больше не будет генерироваться автоматически.

Answer 2

В Oracle (может быть, в других?) Вы можете отложить проверку ограничения до времени COMMIT.

Так что вы могли бы сначала вставить дочерние строки. (Очевидно, вам понадобится родительский ключ.)

Answer 3

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

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

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

Answer 4

Почему вы не можете создать главную строку и отметить ее как незавершенную?