| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проблема с памятью [D7, Access]
VadimSpb © (2005-12-04 11:22:00)Добрый день!
Возникла проблема, связанная с памятью.
Суть проблемы: Если подключаемся через ADOTable к таблице, где 60000 записей, размер программы в памяти увеличивается на ~6 МБ, если через запрос на объединение с другими таблицами (ADOQuery) - ~60 МБ.
Собственно на запросы пришлось перейти, т.к. если поля в ADOTable лукапить с другой таблицей, они потом не сортируются. Но в результате попал на память!
Таких запросов несколько + увеличится число записей. В общем такие расходы памяти неприемлемы.
Как решить эту проблему?
msguns (2005-12-07 10:11:00) [1]Вставлю свои 2 коп.
Поддержу Sniknik в плане "правильной психологии" работы с БД. Никто не утверждает, что нельзяпользоваться TADOQuery или TADOTable. Делать это точно так же глупо, как и запрещать носить галоши ВООБЩЕ.
Однако наличие подобного инструментария так или иначе стимулирует "ламерство" не слишком отягощенных пониманием ADO программистов, которые "по быстрячку" лепят проги, "работающие" с БД. Фиг его знает КАК, но работающие. В отладке такие программы могут не обнаружить свои дефекты, а вот по прошествии некоторого времени, когда база разростется, кол-во клиентов резко увеличится и т.д...
Также подтвержаю "чудеса" со св-вом TADOQuery.SQL, когда длинная строка приводит к ошибке-"фантому", пропадающей по мере отсечения с последующей приклейкой фрагментов строки (я об этом как-то заводил ветку - так ничего вразумительного и не услышал, из чего сделал вывод - это просто глюк)
Fay (2005-12-07 09:41:00) [2]2 Anatoly Podgoretsky © (07.12.05 9:19) [26]
Точно. 8)
3 года назад мне это понадобилось, но я (каким-то образом) не нашёл. С тех пор не проверял, работал тупо с COM.
2 sniknik © (07.12.05 8:58) [24]
> > Нифига подобного - ADOQuery (и остальная братия) не
>знает про Unidirectional.
> наивный. зачем тогда свойство? из любви мелкософта
> вводить Fay в заблуждение? ;о))
Забудь. Это меня колбасит.
Anatoly Podgoretsky (2005-12-07 09:19:00) [3]Fay © (07.12.05 04:40) [23]
Что это такое по твоему ctOpenForwardOnly
sniknik (2005-12-07 09:05:00) [4]кстати MSSQL поддерживает, ты вроде говорил с ним работаеш. смотри еще. доку прочитай в конце концов раз больше уже ништо не помогает... ;)
sniknik (2005-12-07 08:58:00) [5]> но пока я не понял.
не хотел. я про это с самого начала твержу. сами компоненты не причем но они накладывают стереотипы использования т.к. названы и призваны заменять аналоги из BDE. но аналогами как таковыми даже близко не являются.
зайди в базы и посмотри сколько народу пользуется ADOTable, и даже не задумывается (да и не хочет) , что это не тоже самое что TTable. дали "костылик" они на нем и ковыляют, не было бы его - пришлось учить новое в таком виде какое оно есть.
> Нифига подобного - ADOQuery (и остальная братия) не знает про Unidirectional.
наивный. зачем тогда свойство? из любви мелкософта вводить Fay в заблуждение? ;о))
просто оно зависит от свойств локальный/серверный курсор, + сам провайдер может не поддерживать однонаправленных. там где все условия совпадают оно должно работать (просто обязано).
Fay (2005-12-07 04:40:00) [6]2 sniknik © (06.12.05 9:19) [21]
> но он мне приводит однонаправленые курсоры как аргумент за ADOQuery
Нифига подобного - ADOQuery (и остальная братия) не знает про Unidirectional. Это было о пользе "бескомпонентной" работы 8).
Fay (2005-12-07 04:35:00) [7]2 sniknik © (06.12.05 9:19) [21]
Я не говорю, что ADOQuery предпочтительней.
Я просто не могу понять, почему его нельзя (категорически) использовать. М.б. я невнимательно читал, но пока я не понял.
sniknik (2005-12-06 09:19:00) [8]> А что, ADODataSet бывает UniDirectional ?! Можно подробнее?
ВОТ! вот это я и назаваю непосредственным вредом от ADOQuery. в каждом посте твержу что это тот же, но замаскированный ADODataSet, но он мне приводит однонаправленые курсоры как аргумент за ADOQuery и тут же спрашивает а разве ADODataSet это позволяет.
еще раз. все что позволяет ADOQuery позволяет и ADODataSet т.к. единственное, что делает ADOQuery это передает запрос на выполнение ADODataSet (если так можно сказать о наследнике).
ни одного полезного свойства в ADOQuery не добавлено. все только убрано.
ADOQuery = ADODataSet с настройкой на тип команды cmdText, добавлена "нашлепка" в виде метода SQL, дла странных манипуляций с самим запросом при раздельном его внесении. (описано см. выше) . и метод ExecSQL {for TQuery compatibility} который тоже ничего не делает, только передает команду дальше в ADOCommand. все.
ADOTable = ADODataSet с настройкой на тип команды cmdTable. позволяет менять тип на cmdTableDirect специальным методом а не непосредственно у типа. добавлено перенаправление (переименован) DataSource в MasterSource для тойже совместимости с TTable.
и без пояснений, что это всетаки не таблица как в BDE, это всетаки запрос хотя таблицей и назван.
все.
ADOStoredProc = ADODataSet с настройкой на тип команды cmdStoredProc. ничего кроме "оригинального" вызова ExecProc (какой был у TStoredProc) не добавлено. все.
т.е. все что позволяет любой из них естественно позволяет и ADODataSet т.к. ни один непосредственно работой не занят, занят перенаправлением команд ADODataSet-у.
> А с параметрами при ADOQuery не судьба?
железный аргумент! но только "слегка" не по адресу. так еще можно говорить когда используется сложный и запутанный способ чтобы указать прямой, но не наоборот.
наоборот это я должен говорить зачем пользуешся ADOQuery, не судьба использовать "родной" компонент.
тем более "судьба" по оптимизации времени говорит, не надо делать лишних вызовов даже быстрых процедур, т.к. на вызов самих процедур тоже время расходуется. так что если можно обойтась то лучше обходится без посредников. пару вызовов сэкономим.
p.s. пора завязывать. переубеждение каждого сторонника ADOQuery слишком накладно по времени. а "скопом" они не переубеждаются (у меня почемуто чуство, что видел ты мои посты (> [6]), просто не воспринял написаное за аргумент. как и сейчас)
p.p.s. как не поймете, ADOQuery это не та "революция", что была при переходе с TTable на TQuery в BDE. в ADO это не более чем дань привычкам для тех кто с него(BDE) начал.
но, хотите пользоваться, ваше дело, пользуйтесь.
но без выяснений что лучше, одно и тоже это, разница только в мозгах, а так говорил уже, и через ADOTable можно запросы делать пользуясь методами предка (т.е. получается не хуже ADODataSet-а...).
Fay (2005-12-06 02:12:00) [9]> ну прямо откровение свыше. ;о))
> не зависит от компонент, UniDirectional датасеты
А что, ADODataSet бывает UniDirectional ?! Можно подробнее?
> у человека ускорение не в разы, в 200 раз
А с параметрами при ADOQuery не судьба?
sniknik (2005-12-06 01:03:00) [10]> В определённых ситуациях (обычно - forward-only read-only recordsets) прирост скорости (в разы) можно получить.
ну прямо откровение свыше. ;о))
не зависит от компонент, UniDirectional датасеты всегда получаются быстрее обычных, в силу некоторых причин (не надо заботится обратной связи. не поддерживаются букмарки. /может еще чегото)
> Я не пересказываю слухи, просто под рукой нет компактной "демонстрашки", а писать специально - лениво.
вообщето это ты спросил, т.е. тебе было надо. или спросил с умыслом наоборот меня переубедить? не получится.
кстати ссылку не прочитал... у человека ускорение не в разы, в 200 раз, это уже порядки. и естественно, в той, его определенной ситуации, "в общем" ничего не ускоряется. (но думаю теперь он тоже с опаской смотрит на "неликвид" от борланда ;)
Fay (2005-12-06 00:32:00) [11]2 sniknik © (05.12.05 23:52) [16]
> имеется ввиду _Connection.Execute вызывать?
Да хоть бы и так.
> это не будет работать быстрее положенного рядом и подключенного к конекту
Зависит от " это". В определённых ситуациях (обычно - forward-only read-only recordsets) прирост скорости (в разы) можно получить. Я не пересказываю слухи, просто под рукой нет компактной "демонстрашки", а писать специально - лениво.
sniknik (2005-12-05 23:53:00) [12]к конекту ADOConnection-а => к конекту ADOCommand-а
sniknik (2005-12-05 23:52:00) [13]насчет скорости
http://www.delphimaster.ru/cgi-bin/forum.pl?id=1131457561&n=1
> В это случае нужно работать без компонентов (ну разве что получить у ADOConnection его _Connection).
это не будет работать быстрее положенного рядом и подключенного к конекту ADOConnection-а, (имеется ввиду _Connection.Execute вызывать?) иначе зачем конект, без запроса.
т.к. постоянная работа со строкой (передача запроса), + нет параметров, + нет препаре команды.
в "нормальном" ADOCommand парметры и препаре есть, передачь строк нет.
sniknik (2005-12-05 23:38:00) [14]Fay © (05.12.05 04:53) [14]
> Описаных проблем не встречал. Смоделировать (MSSQL) не удалось.
значит повезло. и как ты это смоделируеш это сейчас? давно пофиксено все, смотри дату статьи.
> О каком "новом" идёт речь? ADODataSet чем-то "новее" ADOQuery? Не замечал.
это одно и тоже, говорил же.
> Пока я услышал только то, что ADOQuery чем-то хуже, но хуже он как-то по-странному - не понятно, чем же лучше
> ADODataSet?..
не собираюсь доказывать чем "А" лучше тойже "А" но в обертке от "Б".
вообще это твое дело, пользуешся пользуйся.
Fay (2005-12-05 04:53:00) [15]2 sniknik © (05.12.05 00:24) [13]
Описаных проблем не встречал. Смоделировать (MSSQL) не удалось.
> ну и если скорость нужна (на милисикунды счет идет)
В это случае нужно работать без компонентов (ну разве что получить у ADOConnection его _Connection).
> для 'совместимости с мозгами привыкших к BDE'
Указанные мозги никакого отношения к ADOQuery не имеют и хуже его не делают.
> ну сделали чтото новое, пользуйся им какое оно есть, зачем старые
> стереотипы на него "натягивать"?
О каком "новом" идёт речь? ADODataSet чем-то "новее" ADOQuery? Не замечал.
Пока я услышал только то, что ADOQuery чем-то хуже, но хуже он как-то по-странному - не понятно, чем же лучше ADODataSet?..
sniknik (2005-12-05 00:24:00) [16]вот статья которую читал
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=733
заметь кстати насколько сильны стереотипы, "типовые решения" исправляют тот же "кверик" про ADODataSet даже и не вспомнили, а ведь это на передаче ему "ломаного" запроса возникала ошибка, он то сделан под одну строку (CommandText). замени и горя не знай. с ним по другому как весь запрос целиком и не получится.
ну вернее это надо очень "постараться" написать
ADODataSet.CommandText:= 'SELECT ';
ADODataSet.CommandText:= ADODataSet.CommandText + '* ';
ADODataSet.CommandText:= ADODataSet.CommandText + 'FROM ';
.....
по диотски выглядит да? а ведь с ADOQuery так и было, только "замазано" дополнительной надстройкой - свойством "SQL".... (счас то уже исправили. наверняка буферизуют передачу. неохота смотреть), и никого не удивляло.
sniknik (2005-12-05 00:02:00) [17]VadimSpb (04.12.05 19:57) [9]
> Хорошо, курсоры на сервере. Разве при этом на локальной машине их нельзя сортировать? Попробовал - сортируются!
это у тебя не правильный мед. не с того улья. ты видать пробовал получить уже отсортированный рекордсет с сервера а не сортировать на клиенте...
(я понял нужна именно на клиенте. наверное ошибся)
VadimSpb (04.12.05 20:08) [10]
> Как принято реализовывать ситуацию, когда необходимо просматривать все записи в таблице ....
таких ситуаций принято избегать. всеми мыслимыми и немыслимыми способами.
> что необходимо для экранного отображения с некоторым запасом. Затем по скроллу подгружать данные.
это как раз при серверном курсоре и делается, докачивается по мере обращения. (резкий сдвиг скрола далеко вниз, и тормоза... ;)
> Фильтрация не пройдет,
какая фильтрация на 60тысячной таблице? избавляйся, это наследие тяжолого "локальнофайлового" прошлого получать нужное фильтром из общего набора данных (с таблицей это наоборот хороший вариант). на клиент серверном настоящем надо подумать, что именно тебе нужно и именно его и запросить... (в идеале)
> нужна последовательность данных.
какая? последовательность не гарантируется sql сервером, если только не задана явно сортировкой в запросе
Fay © (04.12.05 22:27) [11]
> Я правильно понял, что речь идёт не о каких-то "технических" проблемах?
технически ADOTable/ADOQuery/ADOStoredProc это одно и тоже и = ADODataSet, так какие могут быть технические проблемы?
считать технической упорное стремление затянуть весь несколькомилионный рекордсет на клиента и отфильтровать 10 нужных записей?
хотя и это было (технические), был глюк в реализации ADOStoredProc в самом начале ADO (узнал много позже про него т.к. не использую и не коснулось), был глюк в ADOQuery с получением параметра при раздельном внесении запроса как обычно с ним и делают. (аналогично не коснулось)
было кстати забавно читать про чужие грабли и думать "ай какой маладетц, прочитал, что это компоненты для 'совместимости с мозгами привыкших к BDE', а оригинальное вот это , и решил не использовать... скольких проблем оказывается избежал и не заметил".
на королевстве дельфи по моему читал, там список "глюкавостей ADO" гдето был.
ну и если скорость нужна (на милисикунды счет идет) то тоже небольшое техническое преимущество у ADOCommand перед ADOQuery есть... когда множественное выполнение в циклах это заметно.
и т.д. по мелочи, всего не упомниш.
но это ерунда можно привыкнуть, смысла нет но можно, а в основном проблема конечно "мозгах", в силе привычке. и тут уже непонятно, ну сделали чтото новое, пользуйся им какое оно есть, зачем старые стереотипы на него "натягивать"? лучше оно облицованное старым фасадом не будет. хуже запросто.
Fay (2005-12-04 22:27:00) [18]2 sniknik © (04.12.05 17:58) [8]
Я правильно понял, что речь идёт не о каких-то "технических" проблемах?
VadimSpb (2005-12-04 20:08:00) [19]Как принято реализовывать ситуацию, когда необходимо просматривать все записи в таблице, а тащить всю слишком много? Насколько я понимаю, достаточно перенести то, что необходимо для экранного отображения с некоторым запасом. Затем по скроллу подгружать данные. Или я ошибаюсь?
Фильтрация не пройдет, нужна последовательность данных.
VadimSpb (2005-12-04 19:57:00) [20]Хорошо, курсоры на сервере. Разве при этом на локальной машине их нельзя сортировать? Попробовал - сортируются!
| |
Страницы: 