Правильная организация master-detail локальной работы с данными

Есть документ, в котором есть список людей, а у каждого человека может быть несколько адресов. Вообщем обычная связь один ко многим. Было принято решение, что все действия с документом проходят на стороне клиента, а в базу все что наворочено записывается по кнопке сохранить.
Для этого использую два memtable связанных master-detail и выставленным свойством CachedUpdates=True.
memTable людей(mtPerson [id_document, id_person, fio], memTable адресов (mtAdr [id_person, ord, adres]
Все это дело отображается неплохо, но вот со вставкой новых данных мне не нравиться сама организация работы.

Если документ новый, то id_document=-1. Человек новый id_person=-1. Адрес новый id_adr=-1.

При сохранении документа, я получаю значение id_document(автоинкриментое поле). Потом перед сохранением списка людей пробегаю по memTable людей(mtPerson) и меняю id_document на вновь полученный.
Так как связь master-detail не допускает нескольких записей с id_person=-1, то мне пришлось вводить на форме суррогатный ключ id_p (при добавлении новой записи inc(id_p, -1) )

уже получается
mtPerson [id_document, id_person, fio, id_p]
mtAdr [id_person, ord, adres, id_p]

Потом при записи в БД данных mtPerson я получаю правильный id_person и пробегая по mtAdr сравниваю id_p и меняю id_person на правильный id_person а потом сохраняю в БД.

Потом при локальном удалении, редактировании записей в memTables куча проверок. Все это громозко и очень топорно.
Хотя задача стандартная.

Какие есть стандартные изящные решения?

TFDSchemaAdapter решает такие проблемы, но он подключается только к FDQuery, а мне нужны именно memTable.

Удалить список людей с адресами у документа и запостить новый.

DimaBr, это не решает проблему получения правильных id_person для адресов

Это решает проблемы всевозможных синхронизация данных которые были и которые появились/изменились/удалились
Вы загружаете на клиента список сотрудников с адресами обрабатываете его на клиенте и выгружаете обратно.

А от получения IdPerson никуда не уйти. Разве что хранить Адреса не в виде таблицы, а в виде текста в самой таблице сотрудников

cptngrb,

Может прикрутить к ID в MemTable генератор из базы, а в базе убрать автоинкремент?

cptngrb	↑
Если документ новый, то id_document=-1. Человек новый id_person=-1. Адрес новый id_adr=-1.

Почему-бы новым строкам не добавлять инкрементные отрицательные значения? -1, -2, -3 и т.д.
Тогда при записи будет понятно, что ид изменится и далее заменять и у зависимостей.

Я прошу прощения, а Вы id человека, id адреса создаете в клиенте ?
А если два клиента одновременно будут документ создавать ?
Почему нельзя редактировать (и сохранять) каждый адрес отдельно ? То есть у Вас открыта информация о человеке. Вы нажимаете кнопку добавить адрес. Открывается формочка с параметрами адреса, которые Вы заполняете не забыв заполнить id человека. Нажимаете сохранить и очередной адрес записывается в базу данных.

cptngrb	↑
Все это громозко и очень топорно. Хотя задача стандартная. Какие есть стандартные изящные решения?

если под "стандартными" имеются в виду из коробки то никаких, раз уж даже FD не помогает

я лично делаю так - 11730884

wadman
я так и делаю inc(id_p, -1)

Sinemurius, ид человека еще не известен, если человек тоже добавляется. его реальный id появиться, только после записи в БД