А че в FR3 нет Lookup полей

freemanzavfreemanzav
отредактировано 03:41 Раздел: FastReport 3.0
Сабж, собственно.

Комментарии

  • AlexTZAlexTZ
    отредактировано 03:41
    Лукапы не поддерживаются.
  • freemanzavfreemanzav
    отредактировано 03:41
    AlexTZ написал:
    Лукапы не поддерживаются.
    Жаль, а будет?
  • AlexTZAlexTZ
    отредактировано 03:41
    Я их специально "вырезал", чтобы унифицировать движки БД. Пользуйтесь запросами.
  • freemanzavfreemanzav
    отредактировано 03:41
    AlexTZ написал:
    Я их специально "вырезал", чтобы унифицировать движки БД. Пользуйтесь запросами.
    Запросы зачастую неэффективное решение. С Lookup полями можно получить огромную экономию трафика, памяти и ресурсов сервера БД. А возможно самому их прикрутить?
  • AlexTZAlexTZ
    отредактировано 03:41
    Нет, практически невозможно - базовый класс на хранение полей не рассчитан.
  • Stalker4Stalker4 123
    отредактировано 03:41
    freemanzav
    написал:
    Запросы зачастую неэффективное решение. С Lookup полями можно получить огромную экономию трафика, памяти и ресурсов сервера БД.

    Это интересно где, лукапы более эффективны, чем запросы ?
    На мой взгляд, все как раз наоборот.

  • freemanzavfreemanzav
    отредактировано May 2005
    Stalker4 написал:
    freemanzav
    Stalker4 написал:
    Запросы зачастую неэффективное решение. С Lookup полями можно получить огромную экономию трафика, памяти и ресурсов сервера БД.

    Это интересно где, лукапы более эффективны, чем запросы ?
    На мой взгляд, все как раз наоборот.
    Пример.
    Таблица продаж 
    CREATE TABLE SALES (
  CLIENT_ID INTEGER,
  SUM_SALE DOUBLE PRECISION

)
    Справочник клиентов. 
    CREATE TABLE CLIENTS (
  CLIENT_ID INTEGER,
  CLIENT_NAME VARCHAR(255)

)
    Если использовать 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. Так что быстрее?
  • StrangerStranger
    отредактировано 03:41
    freemanzav написал:
    Если использовать Lookup, то достаточно закачать справочник клиентов и выполнить запрос типа...
    ... на клиента по сети каждый раз при выполнении запроса тащится туева хуча записей VARCHAR. Так что быстрее?
    А справочник клиентов это не туева хуча? ;) Особенно если из миллиона записей нужны штук пять...
  • MarkusMarkus
    отредактировано 03:41
    Сделай 2 запроса в одном 
    SELECT CLIENT_ID, SUM(SUM_SALE) FROM SALES GROUP BY CLIENT_ID
    во втором 
    SELECT CLIENT_NAME FROM CLIENTS WHERE CLIENT_ID =:CLIENT_ID

    и у второго задай в качестве мастера первый. В результате получишь во втором имя клиента при смене записи в первом. И Lookup не нужен.
  • freemanzavfreemanzav
    отредактировано 03:41
    Stranger написал:
    Stranger написал:
    Если использовать Lookup, то достаточно закачать справочник клиентов и выполнить запрос типа...
    ... на клиента по сети каждый раз при выполнении запроса тащится туева хуча записей VARCHAR. Так что быстрее?
    А справочник клиентов это не туева хуча? ;) Особенно если из миллиона записей нужны штук пять...
    Много ли в БД справочников с миллионом записей? Обычно бывает максимум несколько тысяч. Если допустим у нас 1000 клиентов, а выборка из SALES 2000, то экономия ресурсов почти в 2 раза. Тем более, что справочник нужно закачать 1 раз. И нет никаких JOIN, что резко ускоряет выбору. И даже если из SALES выбирается 5 записей, но при этом приходиться прошерстить 100000, то из CLIENTS будет 100000 индексных чтений. А несколько тысяч записей из CLIENTS с двумя полями занимают на клиенте 1-2 метра, что при нынешних ценах на оперативку просто смешно.
  • freemanzavfreemanzav
    отредактировано 03:41
    Markus написал:
    Сделай 2 запроса в одном 
    SELECT CLIENT_ID, SUM(SUM_SALE) FROM SALES GROUP BY CLIENT_ID
    во втором 
    SELECT CLIENT_NAME FROM CLIENTS WHERE CLIENT_ID =:CLIENT_ID

    и у второго задай в качестве мастера первый. В результате получишь во втором имя клиента при смене записи в первом. И Lookup не нужен.
    Если ты имеешь ввиду Master-Detail, то тут он не пришей рукав
  • MarkusMarkus
    отредактировано 03:41
    freemanzav написал:
    Если ты имеешь ввиду Master-Detail, то тут он не пришей рукав
    Как мне кажется ты сам с трудом представляешь что делается когда формируются лукапные поля в дельфи. Фактически это calcfield, у которых в момент запроса значения происходит его подтягивание из набора с расшифровкой. Причем тот набор должен быть полностью прокачан, чтобы быть уверенным что ты получишь нужное тебе значение.
    В предложенном мной случае для каждой записи формируется запрос одеой записи по ключю. И если тебе хочется назвать это мастер-детэйлом бога ради, только детайл будет содержать всегда ОДНУ запись (если конечно у тебя база нормализована) для данного клиента. А это фактически и есть lookup поле.
  • freemanzavfreemanzav
    отредактировано 03:41
    Markus написал:
    Markus написал:
    Если ты имеешь ввиду Master-Detail, то тут он не пришей рукав
    Как мне кажется ты сам с трудом представляешь что делается когда формируются лукапные поля в дельфи. Фактически это calcfield, у которых в момент запроса значения происходит его подтягивание из набора с расшифровкой. Причем тот набор должен быть полностью прокачан, чтобы быть уверенным что ты получишь нужное тебе значение.
    В предложенном мной случае для каждой записи формируется запрос одеой записи по ключю. И если тебе хочется назвать это мастер-детэйлом бога ради, только детайл будет содержать всегда ОДНУ запись (если конечно у тебя база нормализована) для данного клиента. А это фактически и есть lookup поле.
    Да lookup очень просто работает. Вызывается функция Lookup да и все (см. модуль Db. Хотя действительно формирование значений lookup и вычисляемых полей происходит в одной ф-ии CalculateFields).
    А в случае, предложенном тобой при обращении к каждой записи Master будет переоткрываться Detail. Получается, что если скролируются 1000 записей, то на сервер отправляються 1000 запросов. А если по набору записей нужно пройтись несколько раз?
  • StrangerStranger
    отредактировано 03:41
    freemanzav написал:
    Да lookup очень просто работает. Вызывается функция Lookup да и все (см. модуль Db. Хотя действительно формирование значений lookup и вычисляемых полей происходит в одной ф-ии CalculateFields).
    Мда... супер... хоть постеснялся бы...
  • MarkusMarkus
    отредактировано 03:41
    Судя по всему продолжение дискуссии не имеет смысла.
    Как там у классика
    написал:
    Мужик что бык: втемяшится
    В башку какая блажь —
    Колом ее оттудова
    Не выбьешь: упираются,
    Всяк на своем стоит!
  • freemanzavfreemanzav
    отредактировано May 2005
    Stranger написал:
    Stranger написал:
    Да lookup очень просто работает. Вызывается функция Lookup да и все (см. модуль Db. Хотя действительно формирование значений lookup и вычисляемых полей происходит в одной ф-ии CalculateFields).
    Мда... супер... хоть постеснялся бы...
    Посмотри сам, еси не веришь.
    Я как погляжу, все советчики работают с Access, FoxPro и с прочей гадостью. Поработаете с клиент-серверными БД, да еще с модемной связью, поймете.
  • MarkusMarkus
    отредактировано 03:41
    Ну куда блин деваться какие мы крутые. А что Вы вкладываете в понятие "прочей гадости"? Я например работаю с Interbase/Firebird, MS SQL или ORACLE через DBX, чем не клиент-серверная?

    А в DB.pas смотреть вообще нельзя там базовые классы описаны, а реализация в разных компонентах может уже быт ь реализована по разному.
  • freemanzavfreemanzav
    отредактировано 03:41
    Markus написал:
    Ну куда блин деваться какие мы крутые. А что Вы вкладываете в понятие "прочей гадости"? Я например работаю с Interbase/Firebird, MS SQL или ORACLE через DBX, чем не клиент-серверная?

    А в DB.pas смотреть вообще нельзя там базовые классы описаны, а реализация в разных компонентах может уже быт ь реализована по разному.
    Я не встречал ни одной реализации DataSet-ов в которых был бы перекрыт метод CalculateFields. А если работаешь с IB/FB, то должен знать, чем чреваты например выборки текстовых полей при сортировке и группировке. Я уже не говорю о дисковых чтениях при JOIN, особенно если на сервере небольшой объем памяти. Ну да ладно. Все разговоры ведь не по теме. Я всего лишь спросил как Lookup прикрутить. Если чем обидел, пардон.
  • MarkusMarkus
    отредактировано 03:41
    freemanzav написал:
    Я всего лишь спросил как Lookup прикрутить.
    Угу, а потом стал утверждать что lookup это круче чем запросить всё в одном запросе. Вот из-за этого-то как раз и спор.
  • freemanzavfreemanzav
    отредактировано 03:41
    Markus написал:
    Markus написал:
    Я всего лишь спросил как Lookup прикрутить.
    Угу, а потом стал утверждать что lookup это круче чем запросить всё в одном запросе. Вот из-за этого-то как раз и спор.
    to Markus
    Конечно, может я слишком категорично выразился. Однако иногда это справедливо (я забыл добавить слово "иногда").
  • StasSuhoy145StasSuhoy145
    отредактировано 03:41
    А мужики-то не знают :)

Оставить комментарий

Многофункциональный текстовый редактор. Чтобы отредактировать стиль параграфа, нажмите TAB, чтобы перейти к меню абзаца. Там вы можете выбрать стиль. По умолчанию не выбран ни один стиль. Когда вы выберете текст, появится встроенное меню форматирования. Нажмите TAB, чтобы войти в него. Некоторые элементы, такие как многофункциональные вставки ссылок, картинок, индикаторов загрузки и сообщений об ошибок могут быть вставлены в редактор. Вы можете перемещаться по ним, используя стрелки внутри редактора и удалять с помощью клавиш delete или backspace.

Начало • FastReport 3.0Комментировать как ...

© Vanilla Keystone Theme 2024