Псевдо-событийная вычитка данных из БД и вокруг неё

← →
Ega23 © (2007-04-19 13:29) [0]

Задача стоит следующая: есть некая таблица протокола событий. Струкутра таблицы - ужасная, почти полностью денормализована (по ряду причин).
На клиенте я должен перечитывать данные из этой таблицы, причём, желательно, асинхронно, т.е. по мере появления записи в таблице.
при этом, данный DataSet, в который данные загоняются, должен представлять из себя кольцевой буффер на N записей (если всего записей меньше N - то все, если больше, то последние N).
Также должна быть возможность сортировки данных на клиенте по:
1. Времени события
2. Типу события

Сейчас сделано следующим образом: запускается поток, который через какой-то промежуток долбится в эту таблицу. Если есть что-то новое (а точнее, то, что больше последней даты-времени), то эти записи передаются в основной поток, запоминается последняя дата-время и пошёл пинг дальше.

Передача данных в основной поток, а также их хранение в данный момент организовано через задницу (писалось когда-то давно и на скорую руку).

Как я сейчас себе вижу улучшение:
На клиенте создаётся TADODataSet без коннекта. Как передать в него структуру данных, приходящих от потока - вопрос отдельный.
Дополнительный поток пингует протокольную таблицу; если есть что-то новое - забирает себе. После через synchronize запихивает полученные данные в датасет основного потока.

Вопросы следующие:
1. Как такая архитектура в целом? Недостаточна, избыточна или вообще глупая?
Если с первым вопросом всё ОК, то:
2. Как изначально задать структуру FieldDefs датасета на клиенте? Вручную не хочется, т.к. хп, которая данные возвращает, может меняться, а ребилд проекта делать каждый раз не хочется.

← →
Johnmen © (2007-04-19 13:34) [1]

Я бы создал TClientDataSet для этих целей.
Насчёт структуры не понял. Или мы её знаем и тогда работаем, или не знаем и узнать не можем и тогда кирдык...

← →
Reindeer Moss Eater © (2007-04-19 13:36) [2]

зачем вообще насиловать таблицы с клиента, если можно повесить триггер, в котором заюзать xp которая оповестит всех кого надо любыми доступными средствами?

← →
sniknik © (2007-04-19 13:37) [3]

> 1. Как такая архитектура в целом?
поток лишний, получение данных можно(и проще) сделать асинхронным (поток делает ADO), а все остальное у тебя и так в синхронизации, кроме ожидания (sleep) в потоке, ну так стандартный таймер в основном ничуть не хуже.

> 2. Как изначально задать структуру FieldDefs датасета на клиенте?
пример создания в рантайме в примере по TClientDataSet.CreateDataSet

← →
sniknik © (2007-04-19 13:40) [4]

> Я бы создал TClientDataSet для этих целей.
я бы для того же самого использовал TADODataSet (практически аналогичен, а библиотеки мидас таскать/включать в прогу не надо)

← →
ANB © (2007-04-19 13:41) [5]

> Ega23 © (19.04.07 13:29)

Хотелось бы предостеречь. У нас написали новую систему, где тоже сдуру использовали для отлова событий циклический опрос служебных таблиц. Пока отлаживались у нас - все более менее работало. Попытались внедрять - 5 юзеров уложили довольно нехилый сервер. Сейчас повырубали нафиг опрос событий и переписывают все на статусную модель.
Короче - поаккуратнее с этим. И через отдельный коннект в основном потоке по таймеру, как советует sniknik © (19.04.07 13:37) [3]

← →
Ega23 © (2007-04-19 13:41) [6]

> Я бы создал TClientDataSet для этих целей.

В существующем варианте именно он и используется. Вот только свойства Sort у него нет, надо индексы заводить... :(

> Насчёт структуры не понял.

Данные возвращает ХП. Теоретически, я могу её изменить. Например, вместо
Select strDate=Convert(varchar(10), registerDate, 104) написать
Select strDate=Convert(varchar(10), registerDate, 104), strTime = Convert(varchar(10), registerDate, 108).
Т.е. результирующая выборка изменилась: вместо одного поля стало приходить 2.
В свою очередь, это означает, что на клиенте мне инициализацию CDS придётся переделывать (добавить создание поля strDate).
вот хотелось бы как-то этого избежать...

← →
sniknik © (2007-04-19 13:45) [7]

> Вот только свойства Sort у него нет, надо индексы заводить... :(
ну так используй то в чем есть то что нужно... хотя у клиентского аналогичным по действию будет установка поля "индекснейм", вроде бы...

← →
Ega23 © (2007-04-19 13:48) [8]

А у ADODataset поля, по-идее, также как и в CDS должны добавляться?

Вот ещё один моментик поясните:
Creates the recordset for an ADO dataset. Delphi syntax: procedure CreateDataSet; Description Applications should not need to call CreateDataSet themselves. CreateDataSet is called automatically by an ADO dataset to create its recordset.

Для TClientDataSet надо было вызывать принудительно. Для ADODataset надо или нет?

справку смотрел ([3]) ?
все аналогично.

> справку смотрел ([3]) ?

Конечно смотрел. И внедрял.

> все аналогично.

Это и хотел услышать. Просто мало ли, может у ADO какие особености хитрые есть.

Всё, всем спасибо!

> поток лишний, получение данных можно(и проще) сделать асинхронным
> (поток делает ADO), а все остальное у тебя и так в синхронизации,
> кроме ожидания (sleep) в потоке, ну так стандартный таймер
> в основном ничуть не хуже.

В общем, именно так и сделал. Всё устраивает.
Всем большое спасибо, а sniknik © - отдельное!

Псевдо-событийная вычитка данных из БД и вокруг неё Найти похожие ветки