|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
чччДСтарый плюшевый мишка Код: sql 1. 2. 3. 4.
? Предполагается, что все индексы имеют место быть. Индексы для дистинкт? :) Для джойн, чудушко. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 19:01 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкачччДпропущено... Индексы для дистинкт? :) Для джойн, чудушко. Ну, пациент же ж рассказал, что после джойнов столько данных, что дистинкт грустит. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 19:06 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
чччД, не нравится DISTINCT используй GROUP BY. Только я сомневаюсь что вариант с DISTINCT и JOIN будет лучше чем EXISTS. Пробовать надо ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 19:07 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис, да, нужно смотреть, оценивать и пробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 19:09 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
чччДНу, пациент же ж рассказал, что после джойнов столько данных, что дистинкт грустит. Да? Ну, может быть, я невнимателен. Но я не заметил чтобы пациент рассказал хоть что-либо кроме названий таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 19:11 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Где-то там выше было про хранимый агрегат. Свидетельствую тому Благородному Дону свое почтение. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 20:40 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Да какие к чёрту хранимые агрегаты, у ТСа на это квалификации не хватит. Он на полном серьёзе утверждает, что ему лям записей на клиенте нужен. Ну ок, не лям, а пол-ляма, с дефектами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 21:54 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамДа какие к чёрту хранимые агрегаты, у ТСа на это квалификации не хватит. Он на полном серьёзе утверждает, что ему лям записей на клиенте нужен. Ну ок, не лям, а пол-ляма, с дефектами. Да ладно, это может отчёт раз в месяц. Но он же молчит и аб индексах, и аб задаче, и аб лошадях, и аб бабах, аки рыба в пироге. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 22:41 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Если отчёт раз в месяц, то до фени, 14 он секунд или 3 минуты. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 23:14 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денисне нравится DISTINCT используй GROUP BY. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 09:14 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаГаджимурадов РустамДа какие к чёрту хранимые агрегаты, у ТСа на это квалификации не хватит. Он на полном серьёзе утверждает, что ему лям записей на клиенте нужен. Ну ок, не лям, а пол-ляма, с дефектами. Да ладно, это может отчёт раз в месяц. Но он же молчит и аб индексах, и аб задаче, и аб лошадях, и аб бабах, аки рыба в пироге. Не отчёт в месяц. Задача производственная. Есть крупное изделие, каждый экземпляр хранится в таблице modul (их немного, сотни). Для сборки этого изделия существуют уникальные технологические паспорта, на изделие 5-6 тысяч, хранятся тоже в modul как дети к изделию (типа дерева). У каждого технологического паспорта может быть от 2 до 30 уникальных операций (в среднем 6, наверно), хранятся в umass. Каждую операцию выполняет рабочий, он должен отметить её выполнение, потом проверит его мастер, тоже поставит свою визу. Последний этап - проверка контролёром БТК (ОТК другими словами). Если всё нормально, ставит свою визу. Если ненормально, оформляет Ведомость дефектов. Эти ведомости хранятся в defect, их количество относительно к одной операции может быть и одна штука и пятьдесят, в зависимости от операции. Нужно получить для начала список изделий, в которых были оформлены ведомости дефектов. Теоретически, во всех изделиях они есть. но опять же не факт. Индексы все есть. Что ещё рассказать? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 11:24 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, денормализация поможет. Почему бы вам не хранить флаг наличия хотя бы одного дефекта в таблице modul, поднимать этот флаг в триггере на вставку дефекта, а при устранении всех дефектов сбрасывать этот флаг. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 11:36 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис, Да. Я уже подумал об этом. Только в defect ссылочное поле на изделие и ссылочное поле на паспорт добавить. Вспоминается dbf и т.д. А что ещё делать? Логику работы Exists же не поправить. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 11:54 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, у exists нормальная логика. Максимум что может быть будет сделано в будущем это выполнение exists как SEMI JOIN, тогда появится возможность выбирать алгоритм соединение NESTED LOOP/MERGE/HASH. ИХМО в твоём случае даже это не поможет ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 12:01 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис, Как всегда, жаль. Хотелки какие-то пишем. А я всё время упираюсь в быстродействие. Дайте хоть ссылку на "хранимый агрегат", посмотрю - что это. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 12:29 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIДайте хоть ссылку на "хранимый агрегат", посмотрю - что это. ссылку??? хранимый агрегат - это например "сумма по заказам за день", которая хранится в какой-нибудь таблице, а не вычисляется каждый раз (что является онанизмом). То есть, мы считаем какой-то агрегат (sum, avg, min, max...) и сохраняем результат в таблице для дальнейшего использования. В остальном фантазия ничем не ограничена. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 13:00 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIЕсть крупное изделие, каждый экземпляр хранится в таблице modul (их немного, сотни). Для сборки этого изделия существуют уникальные технологические паспорта, на изделие 5-6 тысяч, хранятся тоже в modul как дети к изделию (типа дерева). Я бы так не делал. Замена отношения 1:n деревом в реляционной модели повышению быстродействия отнюдь не способствует. Не вдаваясь в тему рекурсии при других выборках, прямо в этом запросе оно и приводит к перебору огромного количества записей в ведущей таблице, подавлящее количество которых ведущими не является, а является сущностью следующего уровня иерархии. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 13:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, что мешает протащить ID из modul сразу в defect? один раз скриптом, а потом триггером? можно даже FK устроить. или таблицу связку. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 14:10 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
pastorKreatorXXI, что мешает протащить ID из modul сразу в defect? один раз скриптом, а потом триггером? можно даже FK устроить. или таблицу связку. Денормализацию уже обсудили. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 14:19 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Ну так я и думал, что это ОТК и АСУТП какое-нибудь... KreatorXXI> Нужно получить для начала список изделий, в KreatorXXI> которых были оформлены ведомости дефектов. ... а потом сами ведомости дефектов?... :) Значит, так. У вас на клиенте есть некое представление (дерево, список, комбобокс etc), который нужно либо сформировать (получить список дефектных изделий), либо там весь список и нужно по выбранному изделию представить список дефектов. Если первое, то нужно делать в таблице изделий признак (поле) "has defects" (или "defective", как больше нравится), который будет проставляться (видимо по визе ОТК) в true/false. Назвать это аж "хранимым агрегатом" я не могу, это даже денормализацией с натяжкой можно назвать. :) Если же второе, полный список-ведомости, то сабж (т.е. задача) поставлены неправильно, не с того конца. P.S. Мишку не слушай, он не разобрался. В смысле, паспорта можно/нужно хранить отдельно, но в данном случае это никак бы не помогло, проблема не в них. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 16:41 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
> делать в таблице изделий признак (поле) "has defects" > (или "defective", как больше нравится), который будет > проставляться (видимо по визе ОТК) в true/false. Денис выше то же самое примерно описал. Триггер там необязателен, но как один из вариантов. Денормализацию modul_id в дефекты для данной задачи не советую. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 16:46 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам> Денормализацию modul_id в дефекты для данной задачи не советую. Как раз, ИМХО, это реальный путь. Потому что может быть много разных условий (были ли вообще ВД, есть ли незакрытые и ещё масса признаков, которые пишутся в defect). Не факт, что будет всё востребовано, но вдруг. Может и загоняемся. Хотелось сразу в комбобоксе отсечь "бездефектные" изделия. По мне лучше тогда пусть отображаются все, при выборе "бездефектных" просто не будет конкретики и всё. Чем выдумывать не совсем логичные схемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 17:53 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> Как раз, ИМХО, это реальный путь. Это дело хозяйское, лабайте как душе угодно. :) > Потому что может быть много разных условий > (были ли вообще ВД, есть ли незакрытые "Были ли ВД" как раз гораздо эффективнее решается признаком, а не modul_id (хотя и ID проверять будет проще, чем сейчас); есть ли незакрытые - это совсем другая задача (и как я понимаю, для совсем другого отдела и интерфейса - там сами ВД (список) нужно показывать, а не список изделий). > По мне лучше тогда пусть отображаются все, при > выборе "бездефектных" просто не будет конкретики и всё. > Чем выдумывать не совсем логичные схемы. Вы уж определитесь, чего конкретно вам надо. Если пусть все отображаются, то сабж вообще не нужен, по одному выбранному изделию/паспорту будете ВД отображать (и там join, а не exists). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.09.2017, 18:15 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIЧем выдумывать не совсем логичные схемы.Не надо нелогичные, надо удобные. Не обязательно собирать отчет исключительно по таблицам первичных документов, но на таблицы первички вполне можно навесить триггеры, которые будут писать некий сырец для отчетов (обратить внимание на неблокируемость, лучше употреблять по возможности только инсерты в данном случае). Как пример есть первичка - накладная в заголовке дата, в списочной части товар, как найти сколько товара было отгружено в определенный период времени? джойним заголовок со спецификацией и два условия в разделе where, все как будто по науке, да только оптимизатор мечется, что ему по первой брать? товар или дату... дилемма, причем в разных случаях выиграть/проиграть можно запросто. Как не проигрывать никогда? Правильно композитный индекс дата+товар, но тогда они должны быть в одной таблице, по факту есть еще контрагент(как найти сколько товара из некоего списка товара отгруженено конкретному товарищу за позапрошлый месяц?), склад отгрузки и т.п. чтобы не протаскивать через репликатор всю спецификацию, когда меняют дату в накладной, держим оную стыковочную табличку на триггерах и не таскаем через репликацию. Да, местом в базе, то бишь дисковым пространством платить придется по любому. Как-то так, ты выше просил порассуждать про хранимые агрегаты. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 10:39 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIМожет и загоняемся. Хотелось сразу в комбобоксе отсечь "бездефектные" изделия. мне кажется, у нас была похожая фигня с веб-проектом. Там сначала влепили одну таблицу для идентификации юзеров, со всеми данными, а потом оказалось что регистрируются только где-то около 50% (сейчас уже не помню, может и 30% их всего было). При этом основные запросы обрабатывали только зарегистрировавшихся. Было принято решение добавить таблицу, в которую триггерами копировались регистрирующиеся юзеры. В результате того, что эта таблица была гораздо уже, и содержала меньше записей, все стало летать. Ну и отпала необходимость исключать незарегистрировавшихся в запросах. Здесь можно так же сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 11:42 |
|
|
start [/forum/topic.php?fid=40&msg=39522525&tid=1561418]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
137ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 259ms |
0 / 0 |