Книга по ADO для не совсем чайника

← →
Игорь Шевченко © (2010-11-25 13:12) [40]

> у тебя вообще оракл )

и ADO я не пользуюсь

← →
MsGuns © (2010-11-25 15:16) [41]

На вопросы не отвечает, упорно лепит колеса квадратные, меняя кол-во спиц. Когда все равно хреново едет, то вместо колес сандалим гусеницы

>Дмитрий Тимохов (25.11.10 12:27) [39]
>мы не обсуждаем объемы, мы обсуждаем подход к чтению рекордсета в >ADODB.

Да как бы не совсем.
1) У вас курсор клиентский ? Если "да", то все ваши "стотыщпяццот" однофихственно тащятся по сетке и запоминаются в кэше.
2) Вместо того, чтобы просто взять указатель на этот рекордсет и "наживить" его на крючок вроде TADODataSet и спокойно бегать по нему как хочется (ессно, максимально отключив все его события типа AfterScroll), начинаем пассы с курсором.
3) Игнорируем "бегание" по невидимому НД реализовать в "фоновом" потоке, убрав "тормозятый" эффект

Короче, всему виной АДО и фантомы некой ХП, самопроизвольно компиллящейся по ночам :)

← →
MsGuns © (2010-11-25 15:19) [42]

А вот кистати, ежели рекордсет пробегается строго в одном направлении, т.е. используется разово, вероятно для каких-то расчетных или статистических операций, то льзя ли все это леаризовать непосредственно на сервере, а клиенту отсылать уже аггрегированные результаты ?

← →
Дмитрий Тимохов (2010-11-25 15:23) [43]

> Короче, всему виной АДО и фантомы некой ХП, самопроизвольно
> компиллящейся по ночам :)

ты вообще о чем?
давай без телепатии.

у меня был вопрос - товарищ на немецком мне ответил, я понял.

заодно я привел пример быстрой загрузки (ты же не будешь утверждать, что не бывает случаев, когда тебе надо что-то загрузить и унести с собой на флешке, например, домой?!)
возможно, автору топика пригодится.

не веришь, что он быстрее, проверь.

не нужен тебе быстрый пример загрузки, пройди мимо в другую ветку.

зачем писать "знаю-что-но-не-знаю-зачем" так еще и с пафосом про кв. колеса.

>:-[

← →
sniknik © (2010-11-25 16:54) [44]

> не веришь, что он быстрее, проверь.
не верю, но проверил, не быстрее.

87477 записей (не смотрел сколько весит таблица, но весь файл (mdb) где она основная, после упаковки 79.3 мг) открытие (т.е. выполнение запроса + отображение в гриде (не хотелось отключать в готовой "тестилке")) - 5.469 сек.
запрос + перекладывание в масив "по рецепту" выше, около 7сек (готовой "тестилки" нет, т.что засекал по секундной стрелке из "свойства: дата и время").
могу и точнее после, но по моему очевидно, любое дополнительное действие добавляет дополнительное время, какое бы оно, это действие, малое время не занимало.

← →
Дмитрий Тимохов (2010-11-25 17:09) [45]

> sniknik © (25.11.10 16:54) [44]
>
> > не веришь, что он быстрее, проверь.
> не верю, но проверил, не быстрее.

я на MSSQL делал.

← →
sniknik © (2010-11-25 17:23) [46]

> я на MSSQL делал.
какая разница, ты оперируешь уже на клиенте, готовым рекордсетом. данные в момент перед операцией копирования в масив уже полностью на клиенте, какая база послужила для них источником тут абсолютно "пофиг".

kRecordCount := kRS.RecordCount;
вот это вот показывает сколько готовых данных (если бы был серверный курсор, то могло быть либо -1, либо только скачанная часть, которую ты бы только и получил т.к. kRS.GetRows(kRecordCount, вернее рекордсет бы, если в асинхронном режиме дополучил бы все в конце концов, но в масив попала бы только часть готовая к моменту проверки (вот так и происходят "чудеса"))

← →
Дмитрий Тимохов (2010-11-25 17:27) [47]

ладна, напишу тебе пример потом, запустишь, и сравним.
может действительно у меня специфика в железе есть.

← →
sniknik © (2010-11-25 17:50) [48]

не верю в специфику когда A + B меньше чем просто A, при том, что и A и B гарантированно больше 0.

← →
MsGuns © (2010-11-26 01:30) [49]

>Дмитрий Тимохов (25.11.10 15:23) [43]
>> Короче, всему виной АДО и фантомы некой ХП, самопроизвольно
>> компиллящейся по ночам :)
>ты вообще о чем? давай без телепатии.

Какая телепатия, Господь с тобою. Читай свои же посты, в частности [7] и[11]

Тебе тут пытаются объяснить, что ошибка (непонятность) вовсе не в АДОДБ, а "в головах", иными словами что-то делается не так, криво.

Пафоса не было, была попытка слегка юморнуть, но, очевидно, не до всех этот юмор доходит :)

А по поводу прохождения мимо.. Надо ответить или сам догадаешься ?

← →
Дмитрий Тимохов (2010-11-26 11:14) [50]

> sniknik © (25.11.10 17:50) [48]
>
> не верю в специфику когда A + B меньше чем просто A, при
> том, что и A и B гарантированно больше 0.

А вот зря не веришь. Я написал пример не поленился. У меня разница 40%.
Пример, конечно, надуманный, но как пример, я думаю, вполне сойдет.

ОПИСАНИЕ ПРИМЕРА

1. Обращение к серверу происходит по сети (т.е. не локальный сервер).
Сервер, правда, медленный изрядно - специально использую для разработки не быстрый сервер, чтобы не избаловаться ;)

2. Есть таблица adodb_test_table (a int, b int). Без индекса (незачем, мы же тестируем скорость выборки, а не скорость выполнения). В таблице 1млн записей - случайные целые числа от 0 до 1000.

3. База данных и таблица создаются прилагаемым скриптом DBGenerator.sql. Скрипт работает долго - минут 5.

4. Суть теста: выгрузить на клиента всю таблицу и посчитать сумму колонок А и Б (про агрегатную функцию SUM я знаю - напоминаю,текущий пример призван только для того, чтобы сравнить скорости выборок двумя различными способами).

5. В архиве находится также оконное приложение - писано на Delphi2007, но есть exe, если не боитесь. В приложении есть 2 кнопки. Кнопки подписаны. одна проверят скорость выборки с помощью
while not kRS.EOF do begin читаем значения через kRS.Fields["A"].Value; kRS.MoveNext(); end;

другая

kRS.RecordCount kRS.GetRows(...) for kRow := VarArrayLowBound(kRows, 2) to VarArrayHighBound(kRows, 2) do ...

ИСХОДНЫЙ КОД

www.vkkb.ru/temp/2010_11_26_242424/ADODB_GetRows.zip

ВОПРОС
Может я что-то не так делаю?
И у меня MoveNext работает медленнее, чем надо?

Николай, просвети.
Мне очень интересно услышать от тебя комментарии, т.к. результаты моих тестов сильно не согласуются с твоим высказыванием в [48].

← →
mem (2010-11-26 12:01) [51]

> sniknik © (23.11.10 21:38) [18]

а можно в двух словах, чем компоненты дельфовые не устраивают?

← →
Дмитрий Тимохов (2010-11-26 12:13) [52]

> mem (26.11.10 12:01) [51]
> а можно в двух словах, чем компоненты дельфовые не устраивают?

Отвечу от себя, хотя и не мне вопрос, но может полезно будет )))

Мне не нравится, что дельфовые компоненты не могут работать нормально с типом TDecimal. Они его преобразуют в Extended.

А тип TDecimal мне нужен, т.к. в MSSQL-Server ему соответствует decimal(28,10)

Справка. Тип TDecimal - это один из вариантных типов, как varInteger, varSingle и т.д. Но он не реализован в Delphi.
Вот комментарий в модуле system.pas (у меня Delphi 2007, в более поздних редакция не знаю):

//varDecimal = $000E; { vt_decimal 14 } {UNSUPPORTED as of v6.x code base}

При этом сам дельфи не препятствует работе с varDecimal в части присвоения значения. Если пользоваться импортированной библиотекой ADODB, то varDecimal из БД приходит именно как varDecimal, ты его можешь присвоить переменной типа Variant. Выполнять арифметические операции не можешь, это да. Но я использую импортированные из oleauto32.exe функции

function _VarDecAdd(var aDec1: TDecimal; var aDec2: TDecimal; out aDecResult: TDecimal): HResult; stdcall; external "oleaut32.dll" name "VarDecAdd";

и прочие.

В quality central"е на сайте Delphi висит уже 10 лет запрос на реализацию TDecimal. Как раз приведен пример недостатков ADODB в работе с этим типом.
Но пока висит и висит этот запрос...

← →
Anatoly Podgoretsky © (2010-11-26 12:18) [53]

> а можно в двух словах, чем компоненты дельфовые не устраивают?

Не вижу ничего подобного в сообщение.
Умение пользоваться СОМ объектом напрямую огромный плюс, поскольку обертки от Борланда страдают ограниченностью, не грех вспомнить пример особой ограниченности FastNet

← →
Anatoly Podgoretsky © (2010-11-26 12:19) [54]

> Дмитрий Тимохов (26.11.2010 12:13:52) [52]

Я уже писал, что он у них был в 1993 году, но они его условно похоронили.

← →
Дмитрий Тимохов (2010-11-26 12:22) [55]

> Anatoly Podgoretsky © (26.11.10 12:19) [54]
>
> > Дмитрий Тимохов (26.11.2010 12:13:52) [52]
>
> Я уже писал, что он у них был в 1993 году, но они его условно
> похоронили.

Анатолий, а где писал. Можно подробнее?
Почему похоронили?!?! Прекрасный тип. Очень мне его в дельфи не хватает.

← →
Anatoly Podgoretsky © (2010-11-26 12:22) [56]

> Дмитрий Тимохов (26.11.2010 12:13:52) [52]

Кстати еще хуже с типом DECIMAL/NUMERIC(38,x)

← →
Дмитрий Тимохов (2010-11-26 12:24) [57]

> Anatoly Podgoretsky © (26.11.10 12:22) [56]
>
> > Дмитрий Тимохов (26.11.2010 12:13:52) [52]
>
> Кстати еще хуже с типом DECIMAL/NUMERIC(38,x)

именно поэтому пользуемся 28 ))
он 16 байтовый, а 38 вроде нет - не помню уже, 10лет назад это изучал.

← →
Anatoly Podgoretsky © (2010-11-26 12:25) [58]

> Дмитрий Тимохов (26.11.2010 12:22:55) [55]

Речь естественно не о TDecimal а об поддержке BCD вообще, получили они его в
наследство с dBase V и успешно его убили уже в первой своей версии dBase 5.5
заменим его эмуляцией через Float
А реализация у Ashton Tate была великолепна, лучше чем у FoxPro Inc

← →
Дмитрий Тимохов (2010-11-26 12:37) [59]

> Anatoly Podgoretsky © (26.11.10 12:25) [58]
>
> > Дмитрий Тимохов (26.11.2010 12:22:55) [55]
>
> Речь естественно не о TDecimal а об поддержке BCD вообще,

Ага, спасыбо. Понял.

Ну я в общем тоже не о TDecimal - т.е. я не натаиваю, чтобы был именно он. Но аналоги бы хотелось иметь. Пока это Currency, но мне мало 4 знаков после запятой.

← →
mem (2010-11-26 12:48) [60]

> Дмитрий Тимохов (26.11.10 12:13) [52]

спасибо

> Anatoly Podgoretsky © (26.11.10 12:18) [53]

> поскольку обертки от Борланда страдают ограниченностью,

вот про это я и спрашивал. Может, еще что? Быстродействие, например)

← →
Anatoly Podgoretsky © (2010-11-26 13:20) [61]

> Дмитрий Тимохов (26.11.2010 12:24:57) [57]

38 требует 128 бит

← →
Anatoly Podgoretsky © (2010-11-26 13:21) [62]

> Дмитрий Тимохов (26.11.2010 12:37:59) [59]

Сurrency это не BCD - это эмудяция на основе Integer

← →
Суслик_ (2010-11-26 13:34) [63]

> Anatoly Podgoretsky © (26.11.10 13:21) [62]
> > Дмитрий Тимохов (26.11.2010 12:37:59) [59]
> Сurrency это не BCD - это эмудяция на основе Integer

я знаю. я тебе про восприятие программиста - тип с фиксированной запятой. по функционалу Currency именно такой тип, только с 4 знаками после запятой.

я смотрел реализацию Currency по CPU. мне было интересно - Delphi сама реализует арифметические операции из Currency или берет их аналоги их oleauto32.dll по аналогии с TDecimal (в dll и для Currency есть все необходимые функции).

оказалось, что Delphi сами реализуют арифметические операции...
непонятно, кстати, зачем.

← →
Дмитрий Тимохов (2010-11-26 13:35) [64]

Блин, Хром меня знает как Суслика.
Виноват.

← →
Anatoly Podgoretsky © (2010-11-26 14:40) [65]

> Суслик_ (26.11.2010 13:34:03) [63]

Сама, это написано в документации, а делает потому что не хочет связываться
с OLE это большой провал по производительности, вот решили свой велосипед
сварганить.

← →
app © (2010-11-26 14:41) [66]

> Дмитрий Тимохов (26.11.2010 13:35:04) [64]

Прощаю

← →
mem (2010-11-26 14:48) [67]

> app ©

хочу себе фиолетовую с в кружочке

← →
Anatoly Podgoretsky © (2010-11-26 14:50) [68]

А дождешься другого :-)

← →
Дмитрий Тимохов (2010-11-26 14:50) [69]

> Anatoly Podgoretsky © (26.11.10 14:40) [65]
> > Суслик_ (26.11.2010 13:34:03) [63]
> Сама, это написано в документации, а делает потому что не
> хочет связываться
> с OLE это большой провал по производительности, вот решили
> свой велосипед сварганить.

TDecimal мне нравится как сделан. Я сомневаюсь, что его можно сильно ускорить.

А в чем провал, если используешь напрямую функцию VarDecAdd из oleaut32.dll - это же просто функция, а не OLE.

Или я не прав? И там на каждый бит создается отдельный COM-объекты? :)

> а можно в двух словах, чем компоненты дельфовые не устраивают?
в двух словах - читай тщательнее.
где я чтото подобное говорил?

Дмитрий Тимохов
Ю ИСХОДНЫЙ КОД

> www.vkkb.ru/temp/2010_11_26_242424/ADODB_GetRows.zip

ВОПРОС
> Может я что-то не так делаю?
> И у меня MoveNext работает медленнее, чем надо?
и что ты сравниваешь? ты же не передачу данных сравниваешь, ты работу(свою!!!) с ними сравниваешь. в одном случае выборку по позиционную из структуры (предназначенную не для линейной скорости доступа, а для обработки данных, фильтров например, индексирования на клиенте, ...), во втором пакетную (одной командой) операцию с индексным доступом (по смещению в массиве)...
для тех кто не в курсе аналог - массив обьектов из которых значения достаются по RTTI сравнивается с выборкой из "плоского" массива, в который закачали все данные в обход RTTI каким то методом объекта у которого есть прямой доступ.

в общем как и ожидал никаких чудес, просто неверное понимание.

по тесту -
такая же пакетная передача всего рекордсета в датасет про которую говорил, вида ADODataSet1.Recordset:= kRS; вместо своего цикла занимает 0 сек.

сумма из рекодсета, слегка поправлена (убрана явная подтасовка с поиском по текстовому имени внутри цикла. вынесено за него) - т.е. изменено на это
fA, fB: Field; ... fA:= kRS.Fields["A"]; fB:= kRS.Fields["B"]; while not kRS.EOF do begin kCurrentA := fA.Value; kCurrentB := fB.Value; Inc(kSumOfA, kCurrentA); Inc(kSumOfB, kCurrentB); kRS.MoveNext(); end;

на 700 000 записей (10 как то вообще не показатель) занимает
AdodbRecordset.MoveNext test: Sum of A=350643419; Sum of B=349693129; Duration=1,9070

ну и с moveto массив + сумирование в нем
AdodbRecordset.GetRows: Sum of A=350643419; Sum of B=349693129; Duration=1,6212

т.е. не такая уж большая разница, на чудо не тянет.
ну а учитывая, что тест надуманный, такое вряд ли кто в здравом уме будет делать (запросом то эти же суммы получаются за 0.0360 сек) то пользы от этого "трюка" 0.

> т.к. результаты моих тестов сильно не согласуются с твоим высказыванием в [48].
по моим высказываниям ты тут сравниваешь 0 с 1,6212 (вернее с 1,4774 на GetRows(kRecordCount без перебора на суммирование). именно столько занимает B оттуда на передачу рекордсета, то что ты придумал еще дополнительно свое C, и сравниваешь с ним - твои проблемы.

← →
Дмитрий Тимохов (2010-11-26 21:07) [71]

> ну а учитывая, что тест надуманный,

да... это аргумент. последний )

я бы признал, что формально ты был не прав: getrows позволяет получить (действительно, это более корректный термин, нежели скачать) быстрее.
называй как хочешь - но если тебе нужны все данные, то выбирать (получать, доставать - как угодно) через getrows быстрее это факт.

мне не понятно - какие тут могут быть сомнения, сам же привел разницу в 15%.

опять же вполне бы мог признать, что для тебя это было удивительно, что getrows работает быстрее, хоть и не так сильно - действительно, не корректный тест я сделал утром с доступом по именам. виноват.

я пример свой переделал на одну колонку - стабильные разницы 10-15% имею.

← →
mem (2010-11-26 21:21) [72]

> sniknik © (26.11.10 20:37) [70]
>
> > а можно в двух словах, чем компоненты дельфовые не устраивают?
>
> в двух словах - читай тщательнее.
> где я чтото подобное говорил?

ну, если чел предпочитает сложный способ простому, а общение с ole db напрямую, по сравнению с компонентами ADO, таковым и является, то можно предположить, что чем-то(я не говорю всем) последние не устраивают. Хорошо, переформулирую вопрос: какие преимущества можно извлечь из непосредственного использования ole db, по сравнению с TADOxxx?
1. Работа с Decimal;
2.?

> сам же привел разницу в 15%.
да нет, "моя" разница на 100% у больше. т.к. сравнивать нужно передачу, говорили о ней, а не обработку. а это 0 vs 1,4774.

если ты к примеру в цикл sleep поставишь, то что от этого время передачи увеличится? по твоему выходит так.

> опять же вполне бы мог признать, что для тебя это было удивительно, что getrows работает быстрее
во первых, на php только так и пишем, там все на массивах, рекордсетов нет, во вторых чего удивляться то "move" сработал быстрее, чем "выковыривание" из обьектов... ой ну надо же.

> я пример свой переделал на одну колонку - стабильные разницы 10-15% имею.
а давай переделаем на более реальное, ну например на сортировку, или на суммирование полей B только где A = 0, или поиск в данных... и т.д. т.е. сдвинем тест чуть ближе к тому для чего рекордсеты предназначены.

> какие преимущества можно извлечь из непосредственного использования ole db, по сравнению с TADOxxx?
да никаких практически.

> 1. Работа с Decimal;
"варианты" есть и в "обертках", прямой доступ к обьектам, если, что не устраивает тоже.

> 2.?
понты.

← →
Дмитрий Тимохов (2010-11-26 21:32) [75]

> sniknik © (26.11.10 21:26) [73]

Я же не спорю сильно то ))
Просто формально быстрей работает в случаях тупой загрузки. Вообще мне все равно этот пример не подходит (((
У меня TDecimal, а эти типы в массива вариантов не живут. Вот в Variant просто могут жить, а в массиве нет.

Удалю ка я из тракера тикет с задачей по оптимизации посредством GetRows, чтобы не баламутил больше )

первый вариант кстати можно ускорить. немного, структура все таки никуда не денется...
добавить вот это перед определением полей
kRS:= kRS.Clone(adLockReadOnly);
время на построение обратных связей для полей уберет.

← →
mem (2010-11-26 21:43) [77]

← →
Дмитрий Тимохов (2010-11-26 21:50) [78]

> sniknik © (26.11.10 21:41) [76]
>
> первый вариант кстати можно ускорить. немного, структура
> все таки никуда не денется...
> добавить вот это перед определением полей
> kRS:= kRS.Clone(adLockReadOnly);
> время на построение обратных связей для полей уберет.

знаю, но имхо, мало очень. я не замечаю разницы.

← →
Дмитрий Тимохов (2010-11-26 22:02) [79]

> mem (26.11.10 21:43) [77]
>
> > > 2.?
> > понты.

если взять меня, то я просто не знаю дельфовые компонеты - ни доступа к БД, ни работы с БД в GUI.

так получилось, что когда серьезно базами занялся (до этого на дельфи много писал, но не БД) мне сразу не понарвилось, что нормально в TDecimal нельзя работать, так и не изучил, о чем, кстати, жалею.

> я не замечаю разницы.
вот заметная разница, коментариш присвоение для одной из переменных, та и там, например
//kCurrentB := fB.Value;
и
kCurrentB := kRows[1, kRow];

и тест поменяется, примерно так
AdodbRecordset.MoveNext test: Sum of A=350643419; Sum of B=0; Duration=1,4684
AdodbRecordset.GetRows: Sum of A=350643419; Sum of B=0; Duration=1,6076

потому как время передачи никак не поменялось, время "выковыривания" меньше в 2 раза, а именно оно и существенно для рекордсета, и несущественно для взятия из массива.

добавь строк, и ситуация изменится еще более координально.

Книга по ADO для не совсем чайника Найти похожие ветки