Касательно запроса и таблицы

Dinya · Сообщение **Dinya** » 28 мар 2005, 17:32

>sag, Merlin

Ах вот еще, господа! Хотелось бы кратенько получить коментарий по поводу как бы мне это в дальнейшем поиспользовать триггеры и как вы на это смотрите?
Ка вообще вам эта тема?

Dinya · Сообщение **Dinya** » 28 мар 2005, 18:40

sag!

вторая и остальные части кода + доп. индексы...
Хм, может это и не правильно, но индексы сделаны по всем полям, которые выбираются, по которым сортируется и т.д.
Приборы:
" План
PLAN SORT (JOIN (JOIN (JURMAT INDEX (JURMAT_IDX1,JURMAT_IDX2),AL INDEX (_IDX3)),CLIENTS INDEX (CLIENTS_IDX1)))

Адаптированный план
PLAN SORT (JOIN (JOIN (JURMAT INDEX (JURMAT_IDX1,JURMAT_IDX2),AL INDEX (_IDX3)),CLIENTS INDEX (CLIENTS_IDX1)))

------ Performance info ------
Prepare time = 10ms
Execute time = 1m 32s 673ms
Avg fetch time = 5 148,50 ms
Current memory = 27 085 949
Max memory = 27 229 141
Memory buffers = 2 048
Reads from disk to cache = 20 271
Writes from cache to disk = 2
Fetches from cache = 8 173 797"

// результат намного лучше чем раньше...

не знаю как вас, а меня это радует!!! УРА!!!!!!!!!!!

извините, это минутная слабость!//

так вот, закидываю этот запрос (имя ему al_jur_cl) в последний вид с именем... сами понимаете с каким

CREATE VIEW JUREXTEN_VIEW(
"agregat",
"system",
"gruppa",
"part",
"naimenovan",
"producer",
"gen",
"manager",
"region",
"city",
"ppol",
"nomnu",
"god",
"num_week",
"kol",
"su")
AS
select gr.agregat, gr.system, gr.groupa, al_jur_cl.*
from al_jur_cl
left outer join gr on (al_jur_cl."part")=gr.part
;

Приборы:
"План
PLAN JOIN (SORT (JOIN (JOIN (AL_JUR_CL JURMAT INDEX (JURMAT_IDX1,JURMAT_IDX2),AL_JUR_CL AL INDEX (_IDX3)),AL_JUR_CL CLIENTS INDEX (CLIENTS_IDX1))),GR INDEX (GR_IDX4))

Адаптированный план
PLAN JOIN (SORT (JOIN (JOIN (AL_JUR_CL JURMAT INDEX (JURMAT_IDX1,JURMAT_IDX2),AL_JUR_CL AL INDEX (_IDX3)),AL_JUR_CL CLIENTS INDEX (CLIENTS_IDX1))),GR INDEX (GR_IDX4))
------ Performance info ------
Prepare time = 40ms
Execute time = 1m 57s 28ms
Avg fetch time = 6 501,56 ms
Current memory = 27 110 339
Max memory = 27 779 586
Memory buffers = 2 048
Reads from disk to cache = 20 251
Writes from cache to disk = 0
Fetches from cache = 8 174 384
"
вроде тоже прожевало!

sag · Сообщение **sag** » 28 мар 2005, 23:22

Merlin писал(а):

ик. Ну, не послал меня и на том спасибо.
Я не являюсь обладателем канделябра, биты или даже серпа, только совет могу дать, страна у нас такая, да и сегодняшнее настроение мое к этому располагает. Еще и разрешение дано, продолжаем.
Виртуальный мой собеседник Dinya (или, пардон, собеседница?!), понимаешь ли какое дело, ты задаешь вопросы в надежде, что отвечающие тебе помогут разобраться, поэтому если люди о чем-то тебя спрашивают, задавая наводящие вопросы, отвечай на эти самые вопросы, ей-ей, так будет проще.
Я попытался на пальцах показать как можно подойти к оптимизации запросов. Вещи которые я описал для большинства присутствующих очевидны и неинтересны. Но, вдруг быть может, я не зря старался. Но назвался груздем, допишу до конца.
Вопросов у тебя много, вопросы разные, вопросы твои из разных областей. Едем.
1. Версия сервера. Не сказать штоб это было очень-очень важно, спрашиваю так, для порядка.

2. OUTER. OUTER? Оправдан, нужен? Понимаешь ли, это уже важнее. Дело тут в чем. Этот самый OUTER, в твоих выборках может сильно ограничить простор действий оптимизатора, принуждая всегда идти от JURMAT. Плохо это или хорошо, правильно или неправильно это - только тебе определять.

3. Вью. Почему вью? Почему не просто запрос? Тут такие мысли приходят в мою тугую голову. Раз сделанное представление в дальнейшем может упростить разработчику процесс написания будущих запросов (кнопок меньше нажимать придется), однако, возможно, делу оптимизации (а ведь мы с тобой про оптимизацию толкуем?) это все припарки. Насколько я понимаю, раз речь идет про представления, то ты занимаешься составлением запроса к которому могут быть добавлены многообразные разнообразные условия. Это усложняет дело и процесс оптимизации становится еще более творческим. Я этих кошек (вью), на дух не переношу, а наверное все потому, что готовить их не умею. Но не об этом речь. Тебе нужно помедитировать на тему всех возможных вариантов накладывания условий, в конце-то концов, ты ж запрос будешь вызывать из, к примеру, формы, количество вариантов условий конечно. Тут надо помочь оптимизатору зацепится за что-нибудь, сузить критерии обязательного отбора и (а) еще желательно по индексу, пойти "правильным", наиболее быстрым путем.

4.

Dinya писал(а):Хм, может это и не правильно, но индексы сделаны по всем полям, которые выбираются, по которым сортируется и т.д.
// результат намного лучше чем раньше...
не знаю как вас, а меня это радует!!! УРА!!!!!!!!!!!

Тебя колбасит. Это крайность. Конечно хорошо, что сегодня лучше чем вчера, но индексы на все поля... Можешь немерянно огрести в процессе вставки данных в таблицы. Это не наши методы.

5. Метаданные. Ну просят товарищи, ну опиши кратенько.
Хотя лично мне они не нужны (я не про товарищей, а про метаданные). Увидел у тебя в плане твоего запроса что-то похожее на AL INDEX (какой-то индекс),CLIENTS INDEX (сикой-то индекс), поэтому не стал углубляться далее, в надежде, что три твои таблицы связаны через обычные fk.

6.

Dinya писал(а):А вот еще вопрос: запуская запрос в SQL-редакторе, получая рез-ты, как проще всего занести их в таблицу без дополнительной мороки с созданием вручную таблицы? можно это как-нить провернуть?

Можно я не буду отвечать прямо? Конечно увидев в твоей фразе слова "занести", "без мороки", "в таблицу" можно было бы брякнуть что-либо типа "а пошарь в IBExpert-е мышью вокруг результатов запроса ближе к экспорту в скрипт в районе добавления add create table statement", но ЗАЧЕМ? Если и взаправду есть нужда какая в приложении в таких таблицах, временные ли они, или не временные, служащие для "хранимых агрегатов" или еще какие-нибудь, их как и все остальное надо вдумчиво проектировать, и вопрос "проворачивания без мороки" непонятен.

7.

Dinya писал(а):Хотелось бы кратенько получить коментарий по
поводу как бы мне это в дальнейшем поиспользовать триггеры и как
вы на это смотрите? Ка вообще вам эта тема?

Мне как-то ближе темы рыбалки и всяких там внедорожных говнолазаний. Правда-правда.

Надеюсь, что в процессе озвучивания очевидного клятв не нарушил, а навредил если вопрошающему - то не сильно.

Ivan_Pisarevsky

Чукча не читатель, чукча писатель (с)

Динйа, когда читать будем?

У файрберда есть такой такой параметр (судя по твоим постам он именно в таком виде, как ниже я привел)
#DefaultDbCachePages = 2048
Если убрать пипку '#' и накрутить цифирку побольше, то... КУРИТЕ ДОКИ !!! вобщем намек я дал, про волшебное слово твоего ораклового программера

Dinya · Сообщение **Dinya** » 29 мар 2005, 10:41

Доброе утро всем! sag, Merlyn, Ivan_Pisarevsky

Тут шняга такая: все нарастает как снежный ком

.
Теперь еще запрос осложняется тем, что надо создать процедуру или еще какое средство, которое по-существу будет являться доп. условием для отборки в запросе из связанных табличек.

Версия сервака: WI-V6.2.908 Firebird 1.0

Раскрою вот такой секрет. Основная идея - создание на основе конечного вида некоего динамического куба... Фишка в том, что мой руководитель создал его в Fox'е, а теперь в связи с политикой компании о переходе с Oracle на IB с меня причитается создание этого куба в IB. Правомерно и выполнимо ли? как вы считаете?

Я - собеседник.

А еще вот что, по поводу переменных. Вот необходимо ли писать процедуру для возвращения в запрос параметра в переменную, допустим, имени менеджера и использования этого значения для доп. ограничения при отборке или можно еще как-либо выкрутится?

Далее... у меня еще не сформировалось толком понимание того, что такое "метаданные", но понимаю, что это индексы, таблички, представления...
Или я неправильно понимаю? Поясните, плиз!

Merlin, я не могу сказать однозначно (я в этом еще не компетентен) есть ли огромная нужда и необходимость в использовании OUTER, сорри

ВИД. Почему вид тоже не могу внятно объяснить, но задача ставилась как объединение нескольких таблиц на основе вот как раз этого самого вида, а далее юзание его в создании динамического куба...
ИНДЕКСЫ. Индексы не на все поля поставленны, а тока на те, что участвуют в запросе и отборке. У меня таблица индексирована не по всем полям

А вот ни fk, ни pk у меня нет... Может у вас лица станут типа

, но я не создавал их когда копировал данные из Access в табл. IB, а потом не получалось накладывать на мои таблички такие ограничения, было очень много дублирующих записей (хотя как это получалось - ума не приложу).

Ну пока что все, пишите еще!
С уважением, Dinya

Dinya · Сообщение **Dinya** » 29 мар 2005, 10:47

sag, извиняюсь - ступил... это все конечно ответы на твои вопросы были, но и Merlin'у я думаю тоже было бы понятно что к чему, может он тоже подскажет чего

Я весь во внимании..

Merlin · Сообщение **Merlin** » 29 мар 2005, 11:41

Sag, куча респектов, снимаю шляпу. Пару лет назад я тоже ещё был способен железной рукой вести упирающегося к щастью. И даже стиль у меня тогда был похож, видимо, цель его формирует таки. Если есть время и дальнейший интерес - пробуй, если получится, удовлетворение действительно будет глубоким. Однако, на мой взгляд, в данном клиническом случае медицина всё же бессильна. Во всяком случае, на обозримом временном интервале. Я окончательно умываю руки.

Ivan_Pisarevsky

Я - собеседник.

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

Тут шняга такая: все нарастает как снежный ком .
Теперь еще запрос осложняется тем, что надо создать процедуру или еще какое средство, которое по-существу будет являться доп. условием для отборки в запросе из связанных табличек.

Выбрось свою вьюху, она тебе здесь не понадобится. И садись читать доки, их полно прямо здесь на ibase и еще во многих местах (я, например, в свое время, долго и упорно грыз ПДФы которые шли с пятым IB), потом, когда дозреешь до конкретных вопросов, задавай.
Разводить пустую болтовню мне неинтересно, не будет конкретики, я последую примеру Мерлина.

sag · Сообщение **sag** » 29 мар 2005, 16:08

Здравствуй, Dinya,

Dinya писал(а):Основная идея - создание на основе конечного вида некоего динамического куба... Фишка в том, что мой руководитель создал его в Fox'е, а теперь в связи с политикой компании о переходе с Oracle на IB с меня причитается создание этого куба в IB. Правомерно и выполнимо ли?

Правомерно ли то, что причитается с тебя - не знаю, выполнимо - наверно да.

Dinya писал(а):у меня еще не сформировалось толком понимание того, что такое "метаданные", но понимаю, что это индексы, таблички, представления...

это и имелось в виду, схема бд

Dinya писал(а):Тут шняга такая: все нарастает как снежный ком

Dinya, тяжело, понимаю, а еще и весна, хоть и запоздалая.
Что могу тебе посоветовать.
Надо тебе в нескольких направлениях действовать. Навести порядок в схеме бд, создать нормальные структуры. Раз твоя контора находится в процессе апгрейта оракла до фб, то наверняка какие-то специалисты-бэдэшники у вас имеются, возможно, будет не лишним тебе обсудить с ними свою схему (если я правильно вник, твой случай - пяток-десяток таблиц, много времени у них не займешь), в курилке на коленке такие вещи обычно на ура рисуются.
Со своего руководителя стряси нечто тз-подобное, пусть даже словесное, причем старайся при этом (вернее на этом этапе) не произносить такие слова как VIEW, SP; тебе надо заполучить описание некоего "черного ящика", откликающегося на различные варианты наборов входных параметров.
Много читать на темы иб, бд, sql, благо есть что почитать.

Привет, Merlin,

Merlin писал(а):И даже стиль у меня тогда был похож, видимо, цель его формирует таки.

Сложно сказать, может быть и так, не задумывался. А может быть сказывается влияние атмосферы заведения, в кафешке второго корпуса которого мы с тобой, очень даже вероятно (мир тесен!), в одной очереди пересекались.

Merlin писал(а):Если есть время и дальнейший интерес - пробуй, если получится, удовлетворение действительно будет глубоким.

Со временем проблемы, оно конечно бывает, но не регулярно.
Да и тема эта получилась суперабстрактной. Удивляюсь, что kdv до сих пор ее терпит.

Merlin · Сообщение **Merlin** » 29 мар 2005, 21:22

sag писал(а): А может быть сказывается влияние атмосферы заведения, в кафешке второго корпуса которого мы с тобой, очень даже вероятно (мир тесен!), в одной очереди пересекались.

Гюльчатай, я давно чувствую знакомые интонации, но через чадру как-то неотчётливо

Если действительно знакомы, то мыло моё для тебя тоже не секрет

Сообщение **kdv** » 29 мар 2005, 21:40

kdv до сих пор ее терпит.

а что, зничтожить? Это мы завсегда... Но в данном случае мне и самому интересно. Читаю вопросы - ну ничего не понятно. Читаю ответы - все понятно.

Dinya · Сообщение **Dinya** » 30 мар 2005, 10:23

Приветик!

Постараюсь задавать конкретные вопросы, уж как смогу

1. Как связать несколько таблиц, чтобы необходимые данные по задаваемым параметрам выбирались из исходных таблиц?

2. Во что лучше загонять выбираемые записи, учитывая, что это не разовое обращение за имеющимися данными, а постоянная выборка по любым условиям? в табл. или в вид?
ЭТО необходимо для проведения анализа по продажам, по деятельности компании тогда-то и тогда-то, поэтому нет смысла рассматривать эту задачу с тчки зрения разового отчета, когда можно подождать пока пройдет выборка, пока неспешно просмотрятся все записи. Тут требуется оперативное получение инфыиз таблиц.

Вот стал я делать выборку по средству вида, у вас возникают вопросы "почему вид?"

Я не в курсе, может и еще что-то в этом случае сгодится?

Просто замысел такой что создаваемая в итоге хрень (цитата "динамический куб" типа OLAP) будет использоваться разными людьми в дальнейшем для получения всей необходимой инфы, эдакий универсальный ответ на все и любые вопросы/запросы, с какой стороны к нему не подойди.

4. Вопрос индексированности полей. Если посмотреть на код запроса

SELECT AL.PART, AL.NAIMENOVAN, AL.PRODUCER, AL.GEN,
CLIENTS.MANAGER, CLIENTS.REGION, CLIENTS.CITY,
JURMAT."ppol", JURMAT."nomnu",
"GetYear"(jurmat.dat) as god , "WeekOfYear"(jurmat.dat) as num_week,
sum(jurmat."kol"),
sum(jurmat."sale_price")
FROM AL
RIGHT OUTER JOIN JURMAT ON (AL.INV = JURMAT."nomnu")
LEFT OUTER JOIN CLIENTS ON (JURMAT."ppol" = CLIENTS.PSEVDONIMK)
where jurmat."ndoc"='Накладная' and jurmat."mscet"='21'

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 AL.PART, AL.NAIMENOVAN, AL.PRODUCER, AL.GEN, CLIENTS.MANAGER, CLIENTS.REGION, CLIENTS.CITY, JURMAT."ppol", JURMAT."nomnu",
"GetYear"(jurmat.dat) as god , "WeekOfYear"(jurmat.dat) as num_week,
sum(jurmat."kol"), sum(jurmat."sale_price")),

отбор (where jurmat."ndoc"='Накладная' and jurmat."mscet"='21'
) и т.д.

Есть ли смысл индексировать ВСЕ участвующие в запросе поля

(AL.PART, AL.NAIMENOVAN, AL.PRODUCER, AL.GEN, CLIENTS.MANAGER, CLIENTS.REGION, CLIENTS.CITY, JURMAT."ppol", JURMAT."nomnu",
"GetYear"(jurmat.dat) as god , "WeekOfYear"(jurmat.dat) as num_week,
sum(jurmat."kol"), sum(jurmat."sale_price")

или только ТЕ, по которым идет основная выборка с условием(jurmat."ndoc", jurmat."mscet")?

Там еще есть и вычисление суммы... Может по ним еще тоже проиндексировать?

4. Конечно, было огромное желание написать клиентское приложение в Delphi, но тогда я бы вас точно заколебал и тему эту уважаемый модератор бы точняк закрыл, зничтожил!
100пудово, что открываться этот куб будет как в Access'е, так и в Excel'е. Созданный и худо-бедно работающий вид открывается в Access'е через ODBC, а в Excel'е не открывается.

Как тут быть и через что лучше работать с создаваемым видом или что там получится? Тут возникают подспутные задачи (от которых я честно говоря устал, потому что каждый день от ЭТОГО хотят много и по-быстрее), которые могут быть решены тока через какие-либо средства: форма, поле для ввода информации, листбокс, чекбоксы и т.д. Как с этим быть в IB, если не создавать кл. приложение?

Пока не могу еще чего сообразить, поэтому откланеюсь!
Dinya

Ivan_Pisarevsky

kdv писал(а):
kdv до сих пор ее терпит.
а что, зничтожить? Это мы завсегда... Но в данном случае мне и самому интересно. Читаю вопросы - ну ничего не понятно. Читаю ответы - все понятно.

А может во флейм перенести, или там к юмору поближе... А то "чиста конкретный" вопрос:

Постараюсь задавать конкретные вопросы, уж как смогу

1. Как связать несколько таблиц, чтобы необходимые данные по задаваемым параметрам выбирались из исходных таблиц?

Так и подмывает написать что-нидь эдакое

Сообщение **kdv** » 30 мар 2005, 15:51

ответы на вопросы, по номерам

1. учить SQL, читать книжку Грабера

2. читать про DataWarehouse, "киоски данных", накапливать хранимые агрегаты, а не пытаться всю аналитику просчитывать по исходным данным. Если сейчас такое будет выполняться относительно быстро, то на реальных данных такие запросы просто умрут по скорости.

Вот стал я делать выборку по средству вида, у вас возникают вопросы "почему вид?"

не коверкай терминологию. view это "представление". если сомневаешься, что поймут - так и пиши: view.
"Вот я стал делать выборку по средству view..." - что такое СРЕДСТВО view???

4. Если есть условия отбора, часто упоминающиеся, то да, по ним желательно иметь построенные индексы. причем регулярно собирать статистику по этим индексам (см. документацию по set statistics index), чтобы оптимизатор их правильно использовал.

Созданный и худо-бедно работающий вид открывается в Access'е через ODBC, а в Excel'е не открывается

www.ibase.ru/devinfo/excel_odbc.htm

форма, поле для ввода информации, листбокс, чекбоксы и т.д. Как с этим быть в IB, если не создавать кл. приложение?

какие нафиг чекбоксы на сервере??? Сервер (любой) оперирует только SQL-ом. Ты решил приколоться, или тебя совсем уже загнуло?

sag · Сообщение **sag** » 31 мар 2005, 10:59

kdv писал(а):
Вот стал я делать выборку по средству вида, у вас возникают вопросы "почему вид?"
"Вот я стал делать выборку по средству view..." - что такое СРЕДСТВО view???

На эту тему мне понравилось такое:
"Взглянув ночью на небо, вы увидите звезды. Посмотрев в телескоп, вы увидите больше звезд. Понятно, что звезды находятся вовсе не в телескопе - просто вы смотрите на звезды в другой перспективе, то есть получаете более близкое представление о них.
...
Когда пользователи работают с представлениями, они видят те же данные, что находятся в таблицах данных, но, возможно в другой перспективе. Аналогично тому, как телескоп не содержит звезд, представление не содержит данных." С.Бобровски (1995)

хотя Dinya, надеюсь, с этим уже разобрался.