Технология Клиент-Сервер

← →
alxx © (2003-08-21 17:11) [0]

Кто как предпочитает работать с базой при использовании этой технологии? Я, например, использую запросы Insert, Update, Select и компоненты типа TEdit для работы с отдельными записями (большая часть запросов генерится автоматически). Но один мой знакомый пытается использовать DBEdit на временной таблице с последующим обновлением реальной таблицы (мне кажется, это изврат).

← →
Ru © (2003-08-21 17:19) [1]

>alxx © (21.08.03 17:11)

смотря какой движок базы данных. Например InterBase примерно так и работает. У него есть редактируемые представления (view) и копии реальной таблицы (в необходимом объеме не обязательно вся таблица).

← →
alxx © (2003-08-21 17:24) [2]

MSSQLServer у нас обоих.

← →
Romkin © (2003-08-21 17:26) [3]

Я всегда предпочитаю цеплять визуализацию (TDBEdit etc) к TClientDataset, которую уже через провайдера - к тому, что надо. Получается полная свобода, управляемость и однообразие :)

← →
Nikolay M. © (2003-08-21 17:53) [4]

> один мой знакомый пытается использовать DBEdit на временной
> таблице с последующим обновлением реальной таблицы (мне
> кажется, это изврат).

Действительно, эти извращенцы в борланде придумали чушь какую-то: DBAware-компоненты какие-то... На фига они нужны, если для обновления какой-нибудь таблицы с десятком полей сформировать динамический UPDATE-запрос это как два пальца намочить :)

А Romkin дело говорит.

← →
Ru © (2003-08-21 18:00) [5]

>Nikolay M. © (21.08.03 17:53) [4]

в некоторых проектах DBAware компоненты нужны также как рыбке зонтик

← →
Nikolay M. © (2003-08-21 18:02) [6]

> Ru © (21.08.03 18:00) [5]

Кто-бы спорил. Просто порадовала фраза "с последующим обновлением реальной таблицы (мне кажется, это изврат)" :)

Вот елки-палки... Мне как-то кажется, что написать динамический запрос проще, чем следить за состоянием набора данных постоянно... :(

А когда начинаешь задумываться над производительностью, постепенно само собой получается так, что стараешься давать как можно меньше запросов к базе, дулать как можно более короткие транзакции, передавать как можно меньше данных.
В результате при грамотном планировании реальный выигрыш по времени иногда десятикратным получается, как минимум :)
Приведу пример, из практики.
Имелась форма, сложная, для редактирования. На ней - 3 поля для клиентов (ФИО там или наименование). Что проще?
Все на TClientDataset, следовательно, открыл - и сиди спокойно, транзакция закрыта :)
Решение первое, естественное. При показе формы открыть справочник клиентов и на форме - TDBLookupComboBox. В справочнике - уже конкатенация ФИО или юр. наименования и др. в вычислимом поле, только показать. Удобно. Но справочник растет, и довольно быстро - задержки на открытие растут...
Решение второе. Хранимая процедура, выдающая по заданному ключу одну запись - только показать. На форме уже TDBEdit, присоединенный к calculated field, на событие калькуляции - обращение к процедуре. Рядом с полем - кнопка для вызова формы справочника клиентов. Но список растет :) Три поля - три запроса, дергающиеся на каждое шевеление полей в записи :)
Решение третье. Сделали InternalCalc fields - их можно как обычные использовать, и обращение только если пользователь сменил клиента, по изменению ссылочных полей :) Уже лучше, дергает только когда надо... Но все равно, на медленной машине (увы, пришлось), задержка заметна.
Решение четвертое. Сделали вспомогательную таблицу (warehouse), в которую триггерами пихается полное имя, а процедуру его выборки упростили максимально - взять строку из этой таблицы по первичному ключу :).

Вот так, постепенно и получилось так, что даже на P233 пользователь часиков вообще не видел :))) Ускорение даже считать не буду... Где-то на несколько порядков

Технология Клиент-Сервер Найти похожие ветки