| Konstantine |
| Отправлено: 08.06.2006, 13:53 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
| QUOTE | | например, сначала декартово произведение по первым двум вьюхам. |
в этом что-то есть — нужно подумать о реализации...
правда есть одно НО — параметры встречаются и отрицательные (их мало но они есть)
|
|
| olegenty |
| Отправлено: 08.06.2006, 14:15 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
тут проблема не только со знаком, но и с логической операцией. надо подумать, как знак и операцию инвертировать и свести к такому знаку и направлению, при котором можно пошаговое декартово произведение.
а кто сказал, что всё должно быть легко?
в конце концов — высшее образование у тебя есть 
|
|
| avc* |
| Отправлено: 08.06.2006, 14:25 |
|
Не зарегистрирован
|
Да... Сравнить все со всеми и отобрать нужные... Аналогично вижу только декартово произведение. Сочуствую.
Ни чего другого кроме такого пока в голову не идет
| CODE |
--Select Count(*) From PARECNT -- 4 400 188
--Select Count(distinct ord) около 200
Select
t1.ID as ID1
,t2.ID as ID2
,t3.ID as ID3
,( t1.dolgmonth
+ t2.dolgmonth
+ t3.dolgmonth
) as sumdolgmonth
,t1.ord, t2.ord, t3.ord
,t1.dolgmonth, t2.dolgmonth, t3.dolgmonth
From
PARECNT t1
,PARECNT t2
,PARECNT t3
Where 1 = 1 -- только есди все параметры > 0
and t1.ord = 1 and t1.dolgmonth is not null -- and t1.dolgmonth <= 50
and t2.ord = 2 and t2.dolgmonth is not null -- and t2.dolgmonth <= 50
and t3.ord = 2 and t3.dolgmonth is not null -- and t3.dolgmonth <= 50
--
and ( t1.dolgmonth
+ t2.dolgmonth
+ t3.dolgmonth
) between 30 and 50
--
Order by (t1.dolgmonth + t2.dolgmonth + t3.dolgmonth)
|
при связке t1 и t2 ответ примерно за 2 мин, при добавлении 3 ответа не дождался.
|
|
| olegenty |
| Отправлено: 08.06.2006, 14:33 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2 AVC — надо абстрагироваться от множеств и подумать, как определять минимум данных на ранних этапах. с использованием хранимых процедур и временных таблиц в них это не может быть невозможно. я пока только не придумал, что делать с "невыгодным" направлением логической операции и "невыгодным" знаком условия. но и это решаемо, а тогда всё можно свести к декартовым произведениям пар, как я писал выше.
|
|
| avc* |
| Отправлено: 08.06.2006, 14:53 |
|
Не зарегистрирован
|
| QUOTE (olegenty @ 08/06/2006, 14:33) | 2 AVC — надо абстрагироваться от множеств и подумать, как определять минимум данных на ранних этапах
|
А никак не получается "по шагам". Если данные абсолютно произвольные, то на любом этапе мы можем получить комбинацию, удовлетворяющую условию. Т.е. пока не получищь все ко всем ни чего сказать нельзя.
Я вот пытаюсь подумать о другом способе хранения.
|
|
| olegenty |
| Отправлено: 08.06.2006, 15:32 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
по шагам на любом не получится — в результирующей выборке все 12 ID, а на любом другом этапе — меньше. зато на ранних этапах отсекутся неудолятворяющие условиям запись.
я тоже пытаюсь. как вариант — можно так.
Таблица 1
ID
TypeID
...
Таблица 2
ID
ParamTypeID (Param1, Param2 и так столько, сколько надо)
Value
щас ещё над запросом подумаю, получится ли при такой структуре
|
|
| Konstantine |
| Отправлено: 08.06.2006, 15:34 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
да всё примерно так...
кстати — напоминаю — можно использовать и Builder — т.е. не обязательно SQL должен готовый результат вернуть. можно некоторые промежуточные вычисления программно делать — я так и делаю — какие можно условия до декартового — ввожу и получаю минимальные вьюсы T1,T2 ... но и этого не хватает. реально что я получил — это полмиллиона записей на 6 типах (Аксес — 18 сек FireBird 27 сек). в принципе такое время удовлетворяет, но если бы оно было на 12 типах...
|
|
| Gedeon |
| Отправлено: 08.06.2006, 15:46 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
| QUOTE (olegenty @ 08/06/2006, 13:40) | | 2 Gedeon — читай мой предыдущий пост. я уже передумал и исправился |
Как-то я его или не увидел или открыл страницу, а отписался позже.
|
|
| Gedeon |
| Отправлено: 08.06.2006, 15:48 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
| QUOTE (avc* @ 08/06/2006, 14:53) | | Я вот пытаюсь подумать о другом способе хранения. |
Мне такая мысль сразу в голову пришла, когда увидел более полное обьяснение константина, но как-то предлагать не стал т.к. может эта таблица не самописная, а внешнее условие.
|
|
| Konstantine |
| Отправлено: 08.06.2006, 15:48 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
AVC, а что такое "PARECNT" в запросе?
а вот смотрите — может ли получиться такой вариант — делаем 3 декартовых произведения по 4 типа (это недолго по времени) и упорядочиваем по критериям.
дальше для каждого критерия "не меньше" (напр. Param3>30), значит в Dekart1 этот параметр должен быть>30-(Max(Dekart2.Param2))-(Max(Dekart3.Param2))
и так все остальные, ИМХО этим откинется большая часть записей (особенно если условий ограничений много) и потом из них делаем новое декартово — результирующее... 
|
|
| Konstantine |
| Отправлено: 08.06.2006, 15:51 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
Gedeon,AVC — таблица самописная, её можно менять, но вот на что?
|
|
| AVC |
| Отправлено: 08.06.2006, 16:12 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
>AVC, а что такое "PARECNT" в запросе?
Существующая у меня на FireBird тестовая таблица, с полями, удовлетворяющими условиям эксперимента и содержащая много много записей.
id это id, ord это ваш type, а dolgmonth аналог param1
| QUOTE |
а вот смотрите — может ли получиться такой вариант — делаем 3 декартовых произведения по 4 типа (это недолго по времени) и упорядочиваем по критериям.
|
Нет. Смотрите, допустим в первой четверке получили
(T1.P1 + T2.P1 + T3.P1 + T4.P1) = -200 — отвергли,
но ведь в T5.P1 может стоять 240, значит
(T1.P1 + T2.P1 + T3.P1 + T4.P1 + T5.P1) = 40 — подходит. |
|
| Konstantine |
| Отправлено: 08.06.2006, 16:22 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
но ведь вычитается-то как-раз максимальное.
в том примере Dekart1 — это записи, построенные из P1,P2,P3,P4
Dekart2 — это записи, построенные из P5,P6,P7,P8
Dekart3 — это записи, построенные из P9,P10,P11,P12
промежуточные откидывания — это чтоб сократить записи, которые уже не подойдут...
|
|
| avc* |
| Отправлено: 08.06.2006, 17:40 |
|
Не зарегистрирован
|
Развивая эту идую дальше можно сказать что у нас Dekart1 сотоит из 3, 2 и, наконец, одного представления => ограничения можно наложить сразу на представления => приходим к варианту, предложенному olegenty (я на него тоже сначала повелся ) => мы знаем что вариант ошибочен.
Вопрос сводится к предсказанию результата суммирования при условии, что данные имеют произвольные значения. Пока не получите полного объединения о результате суммирования ни чего сказать нельзя. Вот если бы это было бы произведение то можно было бы предсказать 0 или не 0 и, соответственно, снизить мощность выборок.
|
|
| Konstantine |
| Отправлено: 08.06.2006, 22:03 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
| QUOTE | | что у нас Dekart1 сотоит из 3, 2 и, наконец, одного представления |
ну почему? из 12 представлений получаем 3 представления (около 100.000 записей каждая — проверил на задаче). Теперь из каждой создаём таблицу (наверно так лучше чтоб по нескольку раз не вычислялись декартовы произведения), но ставим условие отбора, предполагая что в каждой из оставшихся таблиц значения каждого параметра не больше максимального (тоже вычисляется для каждого представления). повторюсь:| QUOTE | | дальше для каждого критерия "не меньше" (напр. Param3>30), значит в Dekart1 этот параметр должен быть>30-(Max(Dekart2.Param2))-(Max(Dekart3.Param2)) |
аналогично с ограничением параметра "меньше" — тогда берём в формуле минимум
и, если получиться снизить количество записей в этих 3-х таблицах меньше 100 — их можно объединить в финальное декартово произведение...
так ещё если поможет в оптимизации — параметры в основном имеют нулевые значения (больше 60% всех значений нулевые)
теперь ещё попутный вопрос. если я имею представление A и использую его в представлениях В и С, а представление В использую в С, то при выборке представления С — сколько раз вычисляется А — 1 или 2 ???
Отредактировано Konstantine — 08/06/2006, 22:22
|
|
| AVC |
| Отправлено: 09.06.2006, 10:34 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
дальше для каждого критерия "не меньше" (напр. Param2>30), значит в Dekart1 этот параметр должен быть>30-(Max(Dekart2.Param2))-(Max(Dekart3.Param2)) |
Убедил. Так получится. Этим методом можно вычеркивать гарантированно непригодные (или оставить только пригодные, как у вас) строки и понижать мощность выборки.
Развивая идею дальше: в первом представлении можно оставить строки у которых P2> критерий — (max(p1)_по_T2 + max(p1)_по_T3 ... )
Эти maxmax(p1)_по_TN можно быстро получить одним запросом, только вот будет ли от этого толк? Надо экспериментировать.
| QUOTE |
теперь ещё попутный вопрос. если я имею представление A и использую его в представлениях В и С, а представление В использую в С, то при выборке представления С — сколько раз вычисляется А — 1 или 2
|
Зависит от конкретной реализации сервера. Наверное проще поставить пару эксперимнтов. Возможен вариант когда представления не вычисляться заранее а сервер просто рассчитывает результирующую строку в момент когда её требует курсор. |
|
| Konstantine |
| Отправлено: 13.06.2006, 08:56 |
|
Мастер участка
Группа: Модератор
Сообщений: 545
|
всё равно медленно. а max считает дольше чем само декартово строит
|
|
