|
| |
|
|
| |
для: Anwor
(11.08.2006 в 12:29)
| | | >То есть как я понял, политика "много мелких запросов" более
>выигрышная, чем "один здоровый"? Даже если по сути они дадут
>один и тот же результат?
Такая политика выгодна, если у вас большой объём данных и чем больше размер таблицы, тем выгоднее становится использовать элементарные запросы вместо объединений. | |
| |
|
|
| |
|
|
| |
для: Anwor
(11.08.2006 в 15:26)
| | | Все определяется спецификой организации взаимосвязей таблиц в конкретной БД.
Да и большой запрос тоже можно написать по-разному. | |
| |
|
|
| |
|
|
| |
для: Trianon
(11.08.2006 в 12:34)
| | | ))))
Это я понимаю, но:
1) Запрос таки выполняется, хоть и через Ж...
2) Мне как раз и интересно, не приведет ли увеличение количества запросов, которые по сути в сумме дадут такую же кучу информации, к еще большим временным затратам? | |
| |
|
|
| |
|
|
| |
для: Anwor
(11.08.2006 в 12:29)
| | | В общем случае, политика "много мелких запросов" менее выигрышна, чем "один здоровый запрос", но более выигрышна, чем "один дохлый запрос". | |
| |
|
|
| |
|
|
| |
для: Trianon
(10.08.2006 в 18:50)
| | | То есть как я понял, политика "много мелких запросов" более выигрышная, чем "один здоровый"? Даже если по сути они дадут один и тот же результат? | |
| |
|
|
| |
|
|
| |
для: Anwor
(10.08.2006 в 17:45)
| | | примерно в таком направлении и надо двигаться...
во всяком случае, если не удастся упростить запрос другими способами. | |
| |
|
|
| |
|
|
| |
для: Anwor
(10.08.2006 в 17:45)
| | | С ростом объёма любой из таблиц скорость будет только падать, так как линейный рост объёма в любой из таблиц при 11-табличном запросе будет приводить к экспоненциальному росту объёма вычислений. | |
| |
|
|
| |
|
|
| |
для: hars
(10.08.2006 в 17:20)
| | | Вот это нифига себе, перспективка.. ))
А если мне оставить те же 11 таблиц, но сильно упростить проверяющие условия? Имеется в виду, провести сначала несколько уточняющих запросов по всяким там айдишникам, а потом уже подставить под знаки равно тупо числа? Или такое всё равно не поможет?
ЗЫ: к сожалению, я уже не смогу реконструировать БД, потому как весь сайт уже готов, всё там между собой связано, и изменения в таблицах повлекут кошмарные изменения в движке. Надо мне как-то по-другому провернуть... | |
| |
|
|
| |
|
|
| |
для: Anwor
(10.08.2006 в 17:11)
| | | Думаю лучше свести эти 11 таблиц к разумному количеству,либо и правда придётся вам писать несколько отдельных запросов,а если база растёт,то у вас такой запрос не 34 секунды будет выполняться ,а все 34 часа :) | |
| |
|
|
| |
|
|
| |
для: Anwor
(10.08.2006 в 17:11)
| | | >А это действительно в большей степени зависит от количества используемых в запросе таблиц?
Да, так как СУБД сначала объединяет все таблицы, что приводит к колоссальном объёму памяти, которое зачастую сбарсываются на жёсткий диск (что ещё больше усугубляет ситуацию), потом СУБД начинает рыться в этих данных - их очень много и на перелопачивание уходит значительное время. Это при том, что подавляющее большинство полученных данных приходится отбрасывать - в результирующую таблицу идут доли процента сгенерированного массива. | |
| |
|
|
|
