|
|
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Есть документ, в котором есть список людей, а у каждого человека может быть несколько адресов. Вообщем обычная связь один ко многим. Было принято решение, что все действия с документом проходят на стороне клиента, а в базу все что наворочено записывается по кнопке сохранить. Для этого использую два 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 08:58 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Удалить список людей с адресами у документа и запостить новый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 09:52 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
DimaBr, это не решает проблему получения правильных id_person для адресов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 10:02 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Это решает проблемы всевозможных синхронизация данных которые были и которые появились/изменились/удалились Вы загружаете на клиента список сотрудников с адресами обрабатываете его на клиенте и выгружаете обратно. А от получения IdPerson никуда не уйти. Разве что хранить Адреса не в виде таблицы, а в виде текста в самой таблице сотрудников ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 10:20 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
cptngrb, Может прикрутить к ID в MemTable генератор из базы, а в базе убрать автоинкремент? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 10:35 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
cptngrb Если документ новый, то id_document=-1. Человек новый id_person=-1. Адрес новый id_adr=-1. Почему-бы новым строкам не добавлять инкрементные отрицательные значения? -1, -2, -3 и т.д. Тогда при записи будет понятно, что ид изменится и далее заменять и у зависимостей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 10:43 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Я прошу прощения, а Вы id человека, id адреса создаете в клиенте ? А если два клиента одновременно будут документ создавать ? Почему нельзя редактировать (и сохранять) каждый адрес отдельно ? То есть у Вас открыта информация о человеке. Вы нажимаете кнопку добавить адрес. Открывается формочка с параметрами адреса, которые Вы заполняете не забыв заполнить id человека. Нажимаете сохранить и очередной адрес записывается в базу данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 10:59 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
cptngrb Все это громозко и очень топорно. Хотя задача стандартная. Какие есть стандартные изящные решения? если под "стандартными" имеются в виду из коробки то никаких, раз уж даже FD не помогает я лично делаю так - 11730884 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 11:01 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
wadman я так и делаю inc(id_p, -1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 11:27 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Sinemurius, ид человека еще не известен, если человек тоже добавляется. его реальный id появиться, только после записи в БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 11:28 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
cptngrb я так и делаю inc(id_p, -1) Это лишнее поле в моем представлении. Уже имеется id_person. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 11:29 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Sinemurius, два клиента пускай одновременно создают, правильные id я беру при записи из базы через генератор, а он сам обеспечивает неповторяемость ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 11:32 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
wadman, согласен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 11:33 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
cptngrb, Есть два способа, достаточно правильных, что-бы не нарваться на "грабли" 1. Перед формированием записи, заранее запрашиваете значение генератора с сервера, и работаете с этим значением. Некоторых этот способ пугает, - "а что, если запись не была создана, а значение генератора было использовано?". Тут уж на Ваше усмотрение. 2. На сервере создаете хранимую процедуру, в которую передаёте всё, что пожелаете. В этой процедуре и делите данные на две таблицы. Из процедуры возвращаете ID новой записи, по которой и будете делать рефреш из клиента ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 12:13 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
авторSinemurius, ид человека еще не известен, если человек тоже добавляется. его реальный id появиться, только после записи в БД Так добавляйте адрес только тогда, когда человек в БД уже записан и у него есть ID человека. То есть добавили человека, записали в БД. Добавили адрес, записали в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 12:15 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Я знаю, что делать! Нужно cptngrb inc(id_p, -1) заменить на Код: pascal 1. ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 13:16 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
ёёёёё, )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 13:53 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Sinemurius, про удобство для пользователя совсем забыть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 13:54 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Большая проблема написать 2 цикла ? Тут кода на 15 строчек Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 14:13 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
Вся проблема из-за кэширования информации, оставьте кэширование только на detail таблице, а на мастере уберите. Да и вообще я могу понять когда раньше этот режим вводили для узких каналов связи которые к тому же еще и были нестабильны. Сейчас CachedUpdates скорее уже архаизм, чем объективная реальность, хотя наверное есть сценарии где имеет смысл их использовать. Вышесказанное не более чем IMHO :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 16:16 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
энди, к сожалению есть куча сценариев ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 18:32 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
в принципе, ответ я получил - пиши ручками ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 18:33 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
cptngrb, А что мешает новый ID запрашивать не при сохранении, а при добавлении пользователя? Одно значение получить не долго, а если для ID используется BIGINT, то даже "потерянные" (из-за отмены сохранения) значения погоды не сделают?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 19:10 |
|
||
|
Правильная организация master-detail локальной работы с данными
|
|||
|---|---|---|---|
|
#18+
alekcvp, не хочу generator просто так дергать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2019, 19:59 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39901344&tid=2038776]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
133ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
2ms |
| others: | 243ms |
| total: | 501ms |

| 0 / 0 |
