Через чего лучше заходить на MS SQL из Дельфи?

← →
Duce © (2003-07-09 09:51) [0]

Наше Вам!
Сабж. Скорость\неглюкавость\etc.
Непременно "промышленное" происхождение компонент(вводная от шефа).
Про ADO\MDAC в курсе, какие еще варианты?

Благодарю за внимание!

← →
Polevi © (2003-07-09 09:58) [1]

варианты есть, но лучше АДО

← →
Anatoly Podgoretsky © (2003-07-09 10:01) [2]

АДО куда уж промышленнее, от самого производителя данной СУБД, самый прямой клиент для MSSQL, остальные уже производные.

← →
clickmaker © (2003-07-09 11:53) [3]

BDE в целом быстрее ADO, но там нет поддержки многих наворотов сиквела (версий > 7)
Есть еще SQLQuery, SQLDirect - они напрямую общаются с DB Lib SQL сервера, там есть аналоги TQuery, TStoredProc etc.

← →
stone © (2003-07-09 12:00) [4]

> clickmaker © (09.07.03 11:53)
> BDE в целом быстрее ADO

Вот только не надо в очередной раз кривизну рук списывать на недостатки системы. При работе с MS SQL ADO намного быстрее BDE.

← →
clickmaker © (2003-07-09 14:21) [5]

stone © (09.07.03 12:00)

Вот только не надо в очередной раз кривизну рук списывать на недостатки системы. При работе с MS SQL ADO намного быстрее BDE.

Я бы просто так не говорил. При тестировании, при прочих равных, с БДЕ селекты выполнялись намного быстрее. Я ж не умаляю прочих достойнств АДО, просто как вариант, БДЕ вполне жизнеспособен

← →
stone © (2003-07-09 15:12) [6]

> селекты выполнялись намного быстрее

Селекты выполняются сервером и их скорость от средств доступа к серверу не зависит. Другое дело получения результирующего рекордсета на клиента, но это уже отдельная тема разговора.

← →
Stas © (2003-07-09 15:14) [7]

to clickmaker © (09.07.03 14:21)

BDE быстрее ADO ? Может быть с файл-серверными СУБД типа Paradox ?

← →
sniknik © (2003-07-09 17:11) [8]

> Я бы просто так не говорил. При тестировании, при прочих равных, с БДЕ селекты выполнялись намного быстрее.
это как сказать...

многие не справляются с настройками ADO (судя по высказываниям возникающим на форуме) а BDE настроен похоже более менее изначально. смысла не понимают? (сам себе думаю :о))

небольшой пример
простой запрос SELECT * FROM MTABLE
из ADO с локальным курсором (т.е. качаются все данные на клиента) в MTABLE 141312 записи. запрос с перекачкой длится 6,3сек.
берем BDE тот же запрос та же таблица. время 0.96сек! скажете быстрей? нифига подобного! ставим указатель в конец таблици (last) и эта простая операция длится больше минуты. (характерное поведение для серверного курсора, докачка данных, без нее ADO-первый вариант с лок.курсором last время не отслеживается (Now_Old-Now, нужно тики ловить))
делаем тогда и у ADO серверный курсор время 0,43сек. last на конец таблицы (проверить докачку), 18сек (как раз хвостик после минуты в случае с BDE :о))

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

да и как можно думать что чтото станет быстрей если добавить посредника?

← →
handra © (2003-07-09 17:48) [9]

ADO лучше, есть еще Zeos DBO - там прямой API MSSQL (в чем я сомневаюсь).

sniknik © (09.07.03 17:11)
Пример не показательных. Нафиг клиенту видет в списке 141312 записей? Больше 100 - уже перебор.

← →
sniknik © (2003-07-09 18:30) [10]

handra © (09.07.03 17:48)
пример он и есть пример, и как пример очень показателен. а на 100 записях разници не увидиш.
и кстати не обязательно на них смотреть, у меня были задачи и просто по перекачке данных. (были не то слово, чаще всего, только сейчас немного другим занимаюсь) а тесты делали не только на таком мизерном обьеме, были и на 4 мил.записей и просто на время в смысле сколько проработает без глюков ставили постоянную запись и ... на неделю. а так как ни один диск столько не вместит делали несколько потоков - 3 на запись - 2 на удаление тогоже и варьировали как диск начинал кончатся меняли 2 на запись 3 на удаление. и т.д.

← →
Hollywood (2003-07-09 21:15) [11]

BDE неправильно закачивает типы параметров хранимой процедуры, он везде ставит тип ParamType = ptUnknown, когда надо ParamType = ptInput.

Используется: D6 + MSSQL7

смотрел как работает dbExpress - мне понравилось! понимает все правильно!

← →
sniknik © (2003-07-09 22:07) [12]

Hollywood (09.07.03 21:15)
dbExpress использует тот же OLEDB оберткой которого является ADO, так что без разници. (ну почти, пристальней вглядется найдется :о), хотя бы опять в тех же настройках у "родного" компанента их больше)

← →
Theoden (2003-07-11 01:29) [13]

Я например использую SDAC при больших объёмах как у меня, например, 12000 с 29 полями из них 9 Lookup"ов он работает ~ в 2 раза быстрее чем ADO.

← →
Duce © (2003-07-11 09:30) [14]

Спасибо всем за живое участие!
к Theoden: а подробнее? Чье, линк, чтиво? Это тоже ОЛЕДБ?

← →
sniknik © (2003-07-11 09:44) [15]

Duce © (11.07.03 09:30)
поиском совсем пользоватся не умееш?
http://crlab.com/sdac/

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

← →
stone © (2003-07-11 10:16) [16]

> Я например использую SDAC при больших объёмах как у меня,
> например, 12000 с 29 полями из них 9 Lookup"ов

12000 - большой объем?

← →
Theoden (2003-07-11 10:44) [17]

2stone: достаточно

← →
Stas © (2003-07-11 11:37) [18]

>Theoden (11.07.03 01:29)
>Я например использую SDAC при больших объёмах как у меня, >например, 12000 с 29 полями из них 9 Lookup"ов он работает ~ в >2 раза быстрее чем ADO

Я думаю будет Глючить. Кто лучше знает MS SQL чем Microsoft ?

Я себе тоже SDAC скачал. А он с MDAC не конфликтует ?

Попробовал на 600000 записей - вроде время одинаковое с ADO

2Stas ©:
Мое мнение таково, что из двух компонент, которые работают примерно одинаково, я выбираю ту, которая идёт в комплекте (ADO), к тому же SDAC платная.

Я тоже так думаю. Не буду ставить !!!

Через чего лучше заходить на MS SQL из Дельфи? Найти похожие ветки