Как организовать максимально быструю связь с приложениями?

Николай
Дата: 20.03.2001 18:35:23
Приветствую всех!

У меня возникла проблема связи с Ms SQL Server'ом через ADO в Дельфи.

Если КТО-НИБУДЬ сталивался с необходимостью производить вычисления над запрашиваемыми данными с минимальными затратами времени, ПОДСКАЖИТЕ, как организовать связь.

Компонент открывает НД с такой же скоростью, как и QA, а считывает его в массив ОЧЕНЬ медленно.

Может быть вопрос не совсем по тематике, но НИКТО не смог дать мне ответ.
К тому же я начал уже думать, может это еще зависит и от настроек сервера.

Всего наилучшего!
Garya
Дата: 20.03.2001 19:07:54
Опиши подробнее. Можно на мыло hydro@corbina.ru
Victor
Дата: 21.03.2001 09:11:18
Лучше в конфу. Другим тоже интересно.
Николай
Дата: 21.03.2001 11:20:58
Приветствую всех!

Я недавно столкнулся с необходимостью писать алгоритм обработки данных, который невозможно написать средствами T-SQL Ms SQL Server 2000.
Пришлось мне писать CGI на Delphi 5.0 (я пишу БД для сайта). Связь организовывал через ADO.
Но вот, какая обнаружилась удивительная вещь:
1. Создаю SQL-запрос (38'000 записей) и открываю его ( 0:08 с)
2. Переписываю данные в массив ( 2:35 с)
3. Обрабатываю данные ( 0:00 с)
4. Сохраняю результат в БД (~300 записей) ( 0:17 с)
Не стоит и говорить, что ждать почти 4 мин никакой нормальный человек не будет.
И, самое главное, как видите - узкое место алгоритма - как раз работа с БД.

Никто не может дать ответ на простой, казалось бы вопрос: "ПОЧЕМУ?"

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

Но я сам, естественно, понимаю, что разрешение моей проблемы кроется не в использовании бинарного файла вместо БД, а в правильной организации связи с сервером.

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

Всего наилучшего!
SergSuper
Дата: 21.03.2001 12:15:06
а может стоит покапаться в ODS и написать xp_процедуру?
SergSuper
Дата: 21.03.2001 12:16:55
и кстати - что это за алгоритм?
может всё же его можно написать на T-SQL?
(совместными усилиями )
Garya
Дата: 21.03.2001 13:03:08
Скорее всего проблема связана с переписыванием данных в массив. Поскольку массив располагается в виртуальной памяти (как я подозреваю, к тому же динамический), то при добавлении каждой записи в массив вызывается процедура, запрашивающая через WinAPI дополнительную память у операционной системы. Это само по себе дорогостоящая операция. Кроме того, результирующий массив по размерам может получиться таким, что просто не влезет в физически имеющуюся оперативную память. В этом случае начинает работать файл подкачки - а это дополнительный тормоз. Нужно пересматривать подходы. Может, имеет смысл работать не с массивом а с буферизуемым на клиенте табличным источником (вроде ClientDataSet). А еще лучше всю обработку делать на сервере средствами T-SQL, не загружая клиента. Какой смысл перекачивать на клиент 38000 записей? Я уверен, что ни один нормальный человек просматривать их содержимое не захочет.
Николай
Дата: 21.03.2001 15:52:23
2Garya: Да, массив динамический, но изменение его объемов происходит однажды, после открытия НД (мы тогда знаем, сколько в нем записей), а в процессе работы его размерность НЕ изменяется, изменяются лишь элементы массива индексов рабочего массива.
К использованию массивов меня подтолкнула как раз медленная скорость оперирования данными из компонента ADO-запроса. Т. о. массив здесь совсем не причем.

2SergSuper: А что такое OSD?
2All: Я тут уже задавал вопросы по теме, которую я затронул, но она большая, а представление у меня было расплывчатое, т. о. конкретные вопросы я сформулировать не смог.
Суть задачи: динамическое формирование классификации книг и журналов, в зависимости от:
- количества книг в рубриках,
- количества подрубрик в рубриках,
- рейтинга книг сайта.
Важное условие - то, что по какому пути не пошел бы пользователь, он обязательно пришел бы к нужной ему книге.
Сложность заключается в том, что приходится использовать рекурсивные процедуры, а на сколько мне известно, написать хранимую процедуру, которая являлась бы рекурсивной - невозможно.

Правда, когда речь о рекурсии еще не шла, я пытался написать хр. процедуру, но она отрабатывала минут за 5-6, ведь в UDF нельзя использовать временные таблицы. А это неприемлемо.

Хотя я надеюсь в будущем избавиться от CGI и реализовать этот алгоритм на сервере.
SergSuper
Дата: 21.03.2001 16:21:35
1. Не OSD, а ODS - Open Data Server
Это нечто, что позволяет писать xp_процедуры (т.е. ИксПэ, а не ХэРэ)
Они работают прямо на сервере, хоть представляют собой DLL.
2. Хранимую процедуру можно сделать рекурсивной, но не нужно - уровень вложенности ограничен 32-мя, да и как-то ненадежно это работает
3. В теории любая рекурсивная процедура может быть заменена нерекурсивной с циклом.
4. И вообще у Вас, судя по всему, задача как раз для SQL, просто опыта работы с БД мало(мне так показалось)
AnS1
Дата: 21.03.2001 16:23:04
что-то как-то всё перепутано
1. рекурсию реализовать под sp можно, только вот
- уровень вложенности сущ-но ограничен,
- производительность будет никуда не годная
2. рекурсивный алгоритм можно переделать под нерекурсивный - классическая задачка-с
3. а зачем тебе UDF - просто потому-что они есть?

в общем - прогнись и напиши нормальную sp - оптимальнее по скорости ничего не придумать