Организация работы с наборами данных

← →
Jony (2002-08-30 13:24) [0]

В форуме уже не раз поднимались вопросы о рациональной, грамотной организации проектов, подходах в технике работы с клиент-серверной БД и т.п. Хочу поставить еще один вопрос для программистов, имеющих опыт работы с большими проектами.
Как правильно, грамотно работать с наборами данных?
1.Когда открывать и когда закрывать?
2.Использовать или нет один и тот же набор в нескольких модулях (для MDI-приложений)?
3.Если да, то как контролировать открытие/закрытие?
4.Целесообразность создания нескольких DataModule
К сожалению этим вопросам в литературе практически не уделяется внимание.
Заранее благодарен всем мастерам, поделившимся своим опытом и конструктивными советами.

← →
Delirium (2002-08-30 16:01) [1]

Что касается MDI, у меня каждое окно работает независимо от остальных, информация обновляется OnActivate.

← →
Val (2002-08-30 16:09) [2]

>Delirium © (30.08.02 16:01)
..информация обновляется OnActivate.
думаю, не всегда хорошее решение. Может быть несколько открытых окон с большими открытыми НД, при попытке по ним "пробежаться" -могут быть тормоза. у нас используют кнопки рефреша + насильтсвенное обновление пр необходимости.

← →
Delirium (2002-08-30 16:37) [3]

> Val

У меня все запросы в потоках так, что тормоза скрадываются отрисовкой или ещё чем-нибудь. Хотя, разумееется, некоторая связь между окнами нужна - для этого подходит MainForm. Т.е. от окна к окну обращение формализовано через главное окно.

← →
Alen Delon (2002-08-30 16:46) [4]

Jony © (30.08.02 13:24)
Модули данных лучше всего создавать для группы компонент БД, логика работы с которыми имеет общие алгоритмы: связи, триггеры и т.п. В этом же модуле удобно писать универсальные обработчики событий (например, обработка ошибок постирования по конфликтам ключей), сконцентрированние в соотв-х TActionList и т.д. А вообще невозможно, IMHO, написать какие-либо глобальные правила на все случаи жизни КАК ОРГАНИЗОВЫВАТЬ ПРОГРАММИРОВАНИЕ БД. По логике самих БД, т.е.принципам организации данных (разбивка по таблицам, индексирование и пр.) еще можно, но не по программированию доступа и тем более как это все разбивать по юнитам

← →
Jony (2002-08-30 17:47) [5]

Спасибо всем!
При работе с DataModule все (или какая-то группа) НД хранятся централизованно. Зачем это и что нужно оставить на плечах DataModule я знаю.
Но, честно говоря, меня интересовали некоторые конкретные вопросы. (см. в исходном тексте)
1.Насколько я понимаю, открывать любой НД нужно по необходимости и закрывать вместе с модулем, его использующим, чтобы рационально использовать ресурсы компьютера. Если же один и тот же набор использовать в нескольких модулях, то необходимо как-то отслеживать при закрытии модуля, а вместе с ним и НД, открыты ли еще какие-то модули, в которых используется этот НД. Да и необходимость сортировать, фильтровать, связывать с другими наборами в одном модуле может вызвать некорректные ситуации в других, использующем этот набор и открытых в данный момент. Сохранять/восстанавливать все состояния НД при переходе с одного модуля на другой - дело не благодарное. У меня тут даже возникла ситуация, когда в одном модуле, при использовании PageControl на одной странице должен отражаться весь набор, а на другой - в связи Master-Detail в качестве подчиненного. Установка/разрыв связи в RunTime у меня почему-то работает некорректно. Вот и приходится для одного модуля создавать два НД одной и той же таблицы.Отсюда вывод - каждый НД должен использоваться только в одном месте (модуле).
2.Но тогда другая проблема. Проект у меня довольно большой - полная система управления производственной фирмой с довольно большой номкенклатурой (порядка 1000 наименований, желающие могут познакомиться с характером продукции на wwm.com.ua) и приличными оборотами. Одних таблиц на сервере - уже до 150. А еще ХП, Views и пр. Естественно, что НД в проекте очень много. Уже сейчас, (а в эксплуатацию сданы только первые модули), видимая часть модуля данных забита так, что ориентироваться в ней уже сложно. Поэтому и возникает вопрос о включении в проект нескольких DataModule.
Вот, в кратце, та проблема, с которой мне пришлось столкнуться. И то, как я представляю себе ее решение. Просто это мой первый проект в ООП (до этого программировал под ДОС), поэтому у меня возникает много вопросов чисто организационного порядка. Если я на правильном пути, то буду благодарен за поддержку и одобрение. Также как и за конструктивные напутствия.

← →
MsGuns (2002-08-30 18:52) [6]

DataModule сам по себе ничего не связывает и ничего не делает ! Это просто доп (и довольно удобное) средство программирования, а точнее способ концентрации всего или почти всего, что связано непосредственно с БД, в ОДНОМ месте, к которому потом можно обращаться множество раз при разработке других проектов (чтобы не изобретать велосипед каждый раз, когда надо съездить в булочную). Наверное, Вы немного неправильно выразились или не совсем правильно понимаете смысл "Модуль данных"

← →
Jeer (2002-08-30 19:18) [7]

1.Поэкспериментировав с различными вариантами размещения Dataset, а также однажды увидев неплохую, в общем-то разработку, связанную с ГИС, где все ушло в модуль данных я решил, что я так делать не буду - громоздко, малочитаемо и пр.
2.В итоге модуль данных почти пустой, в нем только вспомогательные и общие Dataset.
3.Формы являются самодостаточными и обмениваются сообщениями об изменении набора данных.
4.На основе relations обновление набора осуществляется только при условии наличия взимосвязанных таблиц.
5. Еще один вариант, довольно широко мной используемый - объектный подход к работе с базой.
Создаются наследуемые таблицы-классы с методами и свойствами. Dataset-ы создаются и формируются в run-time.
В итоге на форме в design-time вообще может не быть Dataset-ов.

← →
Jony (2002-08-30 20:18) [8]

> MsGuns
Я уже говорил, что я знаю что такое DataModule и понимаю его назначение в программе (проекте). Как раз об этом было где почитать.

> Jeer
Может поделишься подробнее по поводу создания DataSet в RunTime. Я недавно задавал вопрос об этом, но никто толком ничего не ответил.

В общем, вижу, что мнения самые разнообразные и, нередко, далеки от теории.
Может еще кто-то откликнется?

Организация работы с наборами данных Найти похожие ветки