Не расстраивайся так, подрастёт когда-нибудь.Dinya писал(а): У меня вот такой вопрос: во есть допустим у меня несколько таблиц каждая в среднем по 100 000, а одна из них на 800 000 записей.
Помедитируй о слове Where. И об них, об индексах.Dinya писал(а): Вот скажите, при создании представления, выбирающего из этой табл. и из других значения, можно ли выводить отобранные записи по-странично или как-нить еще чтобы не сидеть не скучать, не ждать...
Сделать полезные индексы. Не делать лишних индексов.Dinya писал(а): И еще, как мне повысить скорость обработки запроса, одновременно не переполнить базу лишними индесами?
Да ты що?!!!!Dinya писал(а): (база находится на сервере)
Select first 100 skip 200 * from table where ...Dinya писал(а):можно ли выводить отобранные записи по-странично
можно пойти в бухгалтерский отдел, с девочками чяйку попить.Dinya писал(а): или как-нить еще чтобы не сидеть не скучать, не ждать...
делать их только по тем полям, которые нужны для сортировки и фильтрации в order by ... и where ... соответственноDinya писал(а): И еще, как мне повысить скорость обработки запроса, одновременно не переполнить базу лишними индесами?
Ну-ну. Советовать надо аккуратно. Тут на днях один мыслитель "багу" зарегистрировал аж в тракере:DSKalugin писал(а):Select first 100 skip 200 * from table where ...Dinya писал(а):можно ли выводить отобранные записи по-странично
пропустить 200 строк а дальше выбрать 100 штук
вот тебе и постраничность
Если серьёзно, то в первую голову надо конструировать запросы. Создавая под основные индексы с хорошей селективностью и следя за их использованием оптимизатором. Насчёт Fetchall=False - это сильно поможет в случае сортировки гигантской выборки натуралом? Конструирование таблиц пока отложим, но чует моё сердце, что в данном случае собака там тоже основательно порылась.DSKalugin писал(а): Если серьезно, то тебе надо везде где только возможно использовать компоненты Query вместо Table и указать FetchAll=False
везде где это всречается
Ты явно не умеешь их готовить.DSKalugin писал(а): Стараться избегать внешних объединений в запросах...
Про клятву Гиппократа слышал? "Не навреди"? Так ты её прямо только что нарушил с "постраничностью". Этой фичей следует начинать баловаться только когда знаешь как оно работает, что выиграешь с ней, что проиграешь на каком запросе. А не пытаться заместить ей оптимизацию запросов и структур, будет только хуже. Остальные советы главным образом из серии "мойте руки перед едой". Ты в телепатический локатор увидел, что он юзает TTable и усиленно делает fetchall? Кстати, именно и, по-моему, только TTable имеет интересные особенности, дающме очень серьёзный выигрыш при прыжках по длинной таблице из конца в конец. Не путать с TIBTable. И вот, вместо того, чтоб расти над собой в плане понимания что он делает и писания хороших запросов, начнёт он сейчас с твоей подачи тратить время на "поиски правильных компонентов" и возню с fetchall, который и так везде false по умолчанию.DSKalugin писал(а): Откуда ко мне такое пристальное внимание?
А где вопрос-то? Его же нету. "Как мне писать запросы, работающие быстро, и не писать работающие медленно". Отвечать в виде монографии будем? Или эссе?DSKalugin писал(а): Мы вопрос обсуждать будем или мой ответ?
Да ну? А мне показалось, что ты в очередной раз огласил некоторый личный опыт, слабо связанный с затруднениями вопрошающего.DSKalugin писал(а): По крайней мере я дал человеку ответы на его вопросы,
Это действительно нормально. И мне накласть на его и вообще любого вопрошающего уровень познаний. А смех, уже даже раздражительный, вызывает неспособность поставить вопрос, а не уровень познаний. Потому что это массовое явление уже достало. Для того, чтобы ему помочь начать думать в правильную сторону, нужно сутки из него клещами тащить сам запрос, план, применяемый оптимизатором при его выполнении, метаданные таблиц, статистику индексов. И тогда уже можно на примере этого запроса объяснить что такое хорошо и что такое плохо и почему. Хочешь ему действительно помочь - воружайся клешами и приступай. Я уже бессердечный, или как там, мне влом. Если добьёшь его до того момента, когда над ним можно начинать работать - я может и помогу, если будет время. Мне, знаешь ли, тоже время от времени вставляют за что-нибудь. И kdv поможет. И ещё кто-нибудь.DSKalugin писал(а): а не просто посмеялся над его уровнем познаний. Все мы когда-то с чего-то начинали. Это нормально.
От этого еще никто не умирал.У меня вот такой вопрос: во есть допустим у меня несколько таблиц каждая в среднем по 100 000, а одна из них на 800 000 записей.
) взгляд лишних индексов, притормаживающих выполнение запроса?
А это как? разве ИБЭксперт может программу скомпилировать?...Я работаю в IBExpert, а не в Делфях или еще в какой визуал-среде.
За что ты его так жестоко? Ну нельзя же все в груп бай перечислять, немудрено, что тормоза...group by AL.PART, AL.NAIMENOVAN, AL.PRODUCER, AL.GEN, CLIENTS.MANAGER,
CLIENTS.REGION, CLIENTS.CITY, JURMAT."ppol", JURMAT."nomnu" ,
"GetYear"(jurmat.dat), "WeekOfYear"(jurmat.dat)
Код: Выделить всё
select sum(jurmat.kol), sum(jurmat.sale_price)
from jurmat
where jurmat.ndoc='Накладная' and jurmat.mscet='21' Приборы? Влезли в рамки? Едем дальше.select al."Первичный ключ",
sum(jurmat.kol), sum(jurmat.sale_price)
from jurmat [outer] join al on (....)
where jurmat.ndoc='Накладная' and jurmat.mscet='21'
group by 1
Код: Выделить всё
select al."Первичный ключ",
CLIENTS."Первичный ключ",
sum(jurmat.kol), sum(jurmat.sale_price)
from jurmat [outer] join al on (....)
[outer] join CLIENTS on (....)
where jurmat.ndoc='Накладная' and jurmat.mscet='21'
group by 1, 2
Сейчас искал дочке слова мегапеснистарт!
первая часть кода. Приборы:
"План
PLAN (JURMAT NATURAL)
Время: 3m 0s 570ms, но выполнилось....
Код: Выделить всё
Стоять на месте, на месте стоять,
Иначе рискуешь ничо не понять.