многопользовательское приложение БД с большим объемом сохраняемых/редактируемых даны
Добрый день! Помогите определиться с выбором.
Существует электронный документ данные из которого хранятся более чем в 10 таблицах БД. Помимо полей (Edit) существует 4 таблицы(grid). По клику строки грида открывается форма редактирования, содержащая как edit-ы, так и grid-ы. Объем информации, содержащейся в открываемой форме, много больше чем содержится в gridе исходного документа. Т.е. grid носит скорее информативный характер (в нем отображается лишь краткая информация). Сохранение данных в БД осуществляется не при закрытии редактируемой формы, а при клике на кнопку "Сохранить" общего меню документа. Т.е. при глобальном сохранении документа в БД.
Соответственно, для хранения информации используется ClientDataSet, который в свою очередь связан с DataSetProvider. Компонент ClientDataSet позволяет хранить вложенные наборы данных.
1) Для каждого грида электронного документа создаем свою связку ClientDataSet - DataSetProvider. Для тех гридов, редактируемая форма которых имеет свои гриды, необходимо создать дополнительно ClientDataSet в количестве равном количеству гридов редактируемой формы? Правильно ли я понимаю что должно получиться: один ClientDataSet – основной набор данных (edit-ы на вложенной форме) + ClientDataSet (вложенный набор данных) по кол-ву гридов на форме. Не усложнит ли это обработку запросов??? Как организовать связку одного ClientDataSet с несколькими вложенными ClientDataSet -тами по разным ключевым полям?
2) Можно ли несколько DataSetProvider связать с одним ADOQuery? Ли лучше для каждого грида электронного документа (4-х DataSetProvider) использовать свой ADOQuery?
3) Приложение МНОГОПОЛЬЗОВАТЕЛЬСКОЕ и одна из таблиц может иметь от 100 до 1000 записей. Как правильнее сохранять? Ведь транзакция блокирует таблицу БД. Хотя преимущество ClientDataSet - короткие транзакции в момент вызова ApplyUpdates, пугает объем данных и сложная связка ClientDataSet (в т.ч 1 к 4-м). Рассматриваем варианты использования индексов, сохранения лишь редактируемых данных….
Может есть координально другие идеи как организовать работу с БД????
|