Я их специально "вырезал", чтобы унифицировать движки БД. Пользуйтесь запросами.
Запросы зачастую неэффективное решение. С Lookup полями можно получить огромную экономию трафика, памяти и ресурсов сервера БД. А возможно самому их прикрутить?
Если использовать Lookup, то достаточно закачать справочник клиентов и выполнить запрос типа:
SELECT CLIENT_ID, SUM(SUM_SALE) FROM SALES GROUP BY CLIENT_ID
Иначе:
SELECT MIN(CLIENT_NAME), SUM(SUM_SALE) FROM SALES S
INNER JOIN CLIENTS C ON S.CLIENT_ID=C.CLIENT_ID GROUP BY S.CLIENT_ID
Второй запрос дергает таблицу CLIENTS на каждую запись SALES (или наоборот, но от этого не легче), выполняется лишнее вычисление (MIN(CLIENT_NAME)), и на клиента по сети каждый раз при выполнении запроса тащится туева хуча записей VARCHAR. Так что быстрее?
Если использовать Lookup, то достаточно закачать справочник клиентов и выполнить запрос типа...
... на клиента по сети каждый раз при выполнении запроса тащится туева хуча записей VARCHAR. Так что быстрее?
А справочник клиентов это не туева хуча? Особенно если из миллиона записей нужны штук пять...
Если использовать Lookup, то достаточно закачать справочник клиентов и выполнить запрос типа...
... на клиента по сети каждый раз при выполнении запроса тащится туева хуча записей VARCHAR. Так что быстрее?
А справочник клиентов это не туева хуча? Особенно если из миллиона записей нужны штук пять...
Много ли в БД справочников с миллионом записей? Обычно бывает максимум несколько тысяч. Если допустим у нас 1000 клиентов, а выборка из SALES 2000, то экономия ресурсов почти в 2 раза. Тем более, что справочник нужно закачать 1 раз. И нет никаких JOIN, что резко ускоряет выбору. И даже если из SALES выбирается 5 записей, но при этом приходиться прошерстить 100000, то из CLIENTS будет 100000 индексных чтений. А несколько тысяч записей из CLIENTS с двумя полями занимают на клиенте 1-2 метра, что при нынешних ценах на оперативку просто смешно.
Если ты имеешь ввиду Master-Detail, то тут он не пришей рукав
Как мне кажется ты сам с трудом представляешь что делается когда формируются лукапные поля в дельфи. Фактически это calcfield, у которых в момент запроса значения происходит его подтягивание из набора с расшифровкой. Причем тот набор должен быть полностью прокачан, чтобы быть уверенным что ты получишь нужное тебе значение.
В предложенном мной случае для каждой записи формируется запрос одеой записи по ключю. И если тебе хочется назвать это мастер-детэйлом бога ради, только детайл будет содержать всегда ОДНУ запись (если конечно у тебя база нормализована) для данного клиента. А это фактически и есть lookup поле.
Если ты имеешь ввиду Master-Detail, то тут он не пришей рукав
Как мне кажется ты сам с трудом представляешь что делается когда формируются лукапные поля в дельфи. Фактически это calcfield, у которых в момент запроса значения происходит его подтягивание из набора с расшифровкой. Причем тот набор должен быть полностью прокачан, чтобы быть уверенным что ты получишь нужное тебе значение.
В предложенном мной случае для каждой записи формируется запрос одеой записи по ключю. И если тебе хочется назвать это мастер-детэйлом бога ради, только детайл будет содержать всегда ОДНУ запись (если конечно у тебя база нормализована) для данного клиента. А это фактически и есть lookup поле.
Да lookup очень просто работает. Вызывается функция Lookup да и все (см. модуль Db. Хотя действительно формирование значений lookup и вычисляемых полей происходит в одной ф-ии CalculateFields).
А в случае, предложенном тобой при обращении к каждой записи Master будет переоткрываться Detail. Получается, что если скролируются 1000 записей, то на сервер отправляються 1000 запросов. А если по набору записей нужно пройтись несколько раз?
Да lookup очень просто работает. Вызывается функция Lookup да и все (см. модуль Db. Хотя действительно формирование значений lookup и вычисляемых полей происходит в одной ф-ии CalculateFields).
Да lookup очень просто работает. Вызывается функция Lookup да и все (см. модуль Db. Хотя действительно формирование значений lookup и вычисляемых полей происходит в одной ф-ии CalculateFields).
Мда... супер... хоть постеснялся бы...
Посмотри сам, еси не веришь.
Я как погляжу, все советчики работают с Access, FoxPro и с прочей гадостью. Поработаете с клиент-серверными БД, да еще с модемной связью, поймете.
Ну куда блин деваться какие мы крутые. А что Вы вкладываете в понятие "прочей гадости"? Я например работаю с Interbase/Firebird, MS SQL или ORACLE через DBX, чем не клиент-серверная?
А в DB.pas смотреть вообще нельзя там базовые классы описаны, а реализация в разных компонентах может уже быт ь реализована по разному.
Ну куда блин деваться какие мы крутые. А что Вы вкладываете в понятие "прочей гадости"? Я например работаю с Interbase/Firebird, MS SQL или ORACLE через DBX, чем не клиент-серверная?
А в DB.pas смотреть вообще нельзя там базовые классы описаны, а реализация в разных компонентах может уже быт ь реализована по разному.
Я не встречал ни одной реализации DataSet-ов в которых был бы перекрыт метод CalculateFields. А если работаешь с IB/FB, то должен знать, чем чреваты например выборки текстовых полей при сортировке и группировке. Я уже не говорю о дисковых чтениях при JOIN, особенно если на сервере небольшой объем памяти. Ну да ладно. Все разговоры ведь не по теме. Я всего лишь спросил как Lookup прикрутить. Если чем обидел, пардон.
Комментарии
Это интересно где, лукапы более эффективны, чем запросы ?
На мой взгляд, все как раз наоборот.
Таблица продаж Справочник клиентов. Если использовать Lookup, то достаточно закачать справочник клиентов и выполнить запрос типа:
Иначе: Второй запрос дергает таблицу CLIENTS на каждую запись SALES (или наоборот, но от этого не легче), выполняется лишнее вычисление (MIN(CLIENT_NAME)), и на клиента по сети каждый раз при выполнении запроса тащится туева хуча записей VARCHAR. Так что быстрее?
и у второго задай в качестве мастера первый. В результате получишь во втором имя клиента при смене записи в первом. И Lookup не нужен.
В предложенном мной случае для каждой записи формируется запрос одеой записи по ключю. И если тебе хочется назвать это мастер-детэйлом бога ради, только детайл будет содержать всегда ОДНУ запись (если конечно у тебя база нормализована) для данного клиента. А это фактически и есть lookup поле.
А в случае, предложенном тобой при обращении к каждой записи Master будет переоткрываться Detail. Получается, что если скролируются 1000 записей, то на сервер отправляються 1000 запросов. А если по набору записей нужно пройтись несколько раз?
Как там у классика
Я как погляжу, все советчики работают с Access, FoxPro и с прочей гадостью. Поработаете с клиент-серверными БД, да еще с модемной связью, поймете.
А в DB.pas смотреть вообще нельзя там базовые классы описаны, а реализация в разных компонентах может уже быт ь реализована по разному.
Конечно, может я слишком категорично выразился. Однако иногда это справедливо (я забыл добавить слово "иногда").