|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
Приветствую всех! У меня возникла проблема связи с Ms SQL Server'ом через ADO в Дельфи. Если КТО-НИБУДЬ сталивался с необходимостью производить вычисления над запрашиваемыми данными с минимальными затратами времени, ПОДСКАЖИТЕ, как организовать связь. Компонент открывает НД с такой же скоростью, как и QA, а считывает его в массив ОЧЕНЬ медленно. Может быть вопрос не совсем по тематике, но НИКТО не смог дать мне ответ. К тому же я начал уже думать, может это еще зависит и от настроек сервера. Всего наилучшего! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2001, 18:35 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
Опиши подробнее. Можно на мыло hydro@corbina.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2001, 19:07 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
Лучше в конфу. Другим тоже интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 09:11 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
Приветствую всех! Я недавно столкнулся с необходимостью писать алгоритм обработки данных, который невозможно написать средствами 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 с). Но я сам, естественно, понимаю, что разрешение моей проблемы кроется не в использовании бинарного файла вместо БД, а в правильной организации связи с сервером. Я был бы очень признателен, если кто-нибудь поделится своим опытом в этом вопросе. Всего наилучшего! ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 11:20 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
а может стоит покапаться в ODS и написать xp_процедуру? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 12:15 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
и кстати - что это за алгоритм? может всё же его можно написать на T-SQL? (совместными усилиями ) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 12:16 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
Скорее всего проблема связана с переписыванием данных в массив. Поскольку массив располагается в виртуальной памяти (как я подозреваю, к тому же динамический), то при добавлении каждой записи в массив вызывается процедура, запрашивающая через WinAPI дополнительную память у операционной системы. Это само по себе дорогостоящая операция. Кроме того, результирующий массив по размерам может получиться таким, что просто не влезет в физически имеющуюся оперативную память. В этом случае начинает работать файл подкачки - а это дополнительный тормоз. Нужно пересматривать подходы. Может, имеет смысл работать не с массивом а с буферизуемым на клиенте табличным источником (вроде ClientDataSet). А еще лучше всю обработку делать на сервере средствами T-SQL, не загружая клиента. Какой смысл перекачивать на клиент 38000 записей? Я уверен, что ни один нормальный человек просматривать их содержимое не захочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 13:03 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
2Garya: Да, массив динамический, но изменение его объемов происходит однажды, после открытия НД (мы тогда знаем, сколько в нем записей), а в процессе работы его размерность НЕ изменяется, изменяются лишь элементы массива индексов рабочего массива. К использованию массивов меня подтолкнула как раз медленная скорость оперирования данными из компонента ADO-запроса. Т. о. массив здесь совсем не причем. 2SergSuper: А что такое OSD? 2All: Я тут уже задавал вопросы по теме, которую я затронул, но она большая, а представление у меня было расплывчатое, т. о. конкретные вопросы я сформулировать не смог. Суть задачи: динамическое формирование классификации книг и журналов, в зависимости от: - количества книг в рубриках, - количества подрубрик в рубриках, - рейтинга книг сайта. Важное условие - то, что по какому пути не пошел бы пользователь, он обязательно пришел бы к нужной ему книге. Сложность заключается в том, что приходится использовать рекурсивные процедуры , а на сколько мне известно, написать хранимую процедуру, которая являлась бы рекурсивной - невозможно . Правда, когда речь о рекурсии еще не шла, я пытался написать хр. процедуру, но она отрабатывала минут за 5-6, ведь в UDF нельзя использовать временные таблицы . А это неприемлемо. Хотя я надеюсь в будущем избавиться от CGI и реализовать этот алгоритм на сервере. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 15:52 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
1. Не OSD, а ODS - Open Data Server Это нечто, что позволяет писать xp_процедуры (т.е. ИксПэ, а не ХэРэ) Они работают прямо на сервере, хоть представляют собой DLL. 2. Хранимую процедуру можно сделать рекурсивной, но не нужно - уровень вложенности ограничен 32-мя, да и как-то ненадежно это работает 3. В теории любая рекурсивная процедура может быть заменена нерекурсивной с циклом. 4. И вообще у Вас, судя по всему, задача как раз для SQL, просто опыта работы с БД мало(мне так показалось) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 16:21 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
что-то как-то всё перепутано 1. рекурсию реализовать под sp можно, только вот - уровень вложенности сущ-но ограничен, - производительность будет никуда не годная 2. рекурсивный алгоритм можно переделать под нерекурсивный - классическая задачка-с 3. а зачем тебе UDF - просто потому-что они есть? в общем - прогнись и напиши нормальную sp - оптимальнее по скорости ничего не придумать ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 16:23 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
забавно, когда мнения совпадают ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 16:24 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
2SergSuper: вообщем, наверное Вы правы. 2AnS1: мне показалось, что UDF - довольно удобный инструмент. ODS: DLL - это хорошо. Где взять ODS и где можно почитать про него и про xp_procedures? Суммируя все вышеизложенное можно сказать, что нельзя организовать более скоростную связь приложения с БД, верно? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 16:49 |
|
Как организовать максимально быструю связь с приложениями?
|
|||
---|---|---|---|
#18+
наверное как-то можно но если бы у меня была задача, где надо работать с 500 записями я бы уже задумался - а не поставить ли СКЛ-сервер? В наше время, "когда космические корабли бороздят просторы вселенной" работать с огромными массивами - стоит ли? Да еще если учесть что стоит сервер... Про ODS можно почитать в BOL, прямо задав строку для поиска "ODS". Но, как говорила одна моя знакомая, будучи выпившей, другой своей знакомой, которая была совсем пьяной: "Ты проснешься и тебе будет стыдно" ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2001, 17:16 |
|
|
start [/forum/topic.php?fid=46&msg=32003342&tid=1827156]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 18ms |
total: | 159ms |
0 / 0 |