|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
FB3. Вот такой запрос: Код: sql 1. 2. 3. 4. 5. 6. 7.
Что нужно? Нужно получить все записи в таблице modul, которые имеют записи в таблице defect. Запрос отрабатывает правильно, но долго. Если в exists оставить одну таблицу umass, то поведение exists ожидаемое (читается по одной записи из umass для каждой записи modul). Если в exists две таблицы, то umass весь читается. Вообще таблицы umass и defect большие. Поэтому хочется такого поведения - читаем запись из modul, читаем последовательно umass и defect, если запись есть, то переходим к другой записи modul. Можно ли что-то сделать с exists? Или посмотреть другие техники? Какие? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 00:35 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
А по-крестьянски Код: sql 1. 2. 3. 4.
не? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 01:13 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, Код: sql 1. 2. 3.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 01:16 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Хотя, неправ я в общем случае, тут, возможно нужен left join с проверкой на not null, ибо неясно отношение между таблицами: например, если одной записи таблички modul соответствует больше одной записи таблички umass и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 01:21 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Да дело не в exist-e, а в индексах, как пить дать. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 01:23 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
чччДХотя, неправ я в общем случае, тут, возможно нужен left join с проверкой на not null, ибо неясно отношение между таблицами: например, если одной записи таблички modul соответствует больше одной записи таблички umass и т.д. О, Господи, что это я понаписал. Все, спать. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 01:25 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаА по-крестьянски Код: sql 1. 2. 3. 4.
не?По-моему, ты всё написал правильно, но забыл поставить DISTINCT после SELECT: Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 01:56 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev, Такие тонкие советы следует давать, когда ты владеешь достаточным объёмом информации о задаче. Оставь DISTINCT себе. Поскольку sn_mdl в таблице modul может быть изначально неуникальным. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 09:13 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSery, серийный номер в таблицы модулей может быть неуникален в случае совпадения серийных номеров от разных производителей модулей. Добавление в выборку идентификатора производителя эту проблему решит. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 09:19 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev, Продолжаешь решать задачу, условия которой не знаешь, а предполагаешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 09:27 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSery, вернее сказать "домысливаю", исходя из очевидных связей сущностей БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 09:39 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev, Очевидных? Спасибо, поржал. Давно для себя сделал вывод, что очевидное для меня вовсе не очевидно другим. Разбирая очередную поделку команды "ух" разработчиков, почти каждый раз в этом убеждаюсь. Потому скепсис - наше всё. Предпочитаю приятно удивляться, что в этот раз сделано правильно разумно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:41 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка, По-крестьянски поинтереснее. Только вот так, конечно: Код: sql 1. 2. 3. 4.
Но мне сейчас не нравится план: авторПлан PLAN JOIN (C NATURAL, B INDEX (PK_UMASS), A INDEX (PK_MODUL)) Почему defect по натуралу? Хотя может из-за того, что таблица defect на данный момент меньше двух других. Если так, то в корне неправильно. Таблица defect склонна к сильному росту. И всю её сканировать неправильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:44 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, Воспользуйся волшебным +0 А вообще, как только она разрастётся, то план сам поменяется же. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:45 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, как вырастет пересчитаешь статистику и план изменится. Не вижу в этом проблемы ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:47 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> И всю её сканировать неправильно. Ну а первоначальный план какой был? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:47 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, судя по плану запрос не будет эквивалентом exists. defect соединяется не по уникальному ключу, а следовательно будет давать дубликаты записей ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:50 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSeryrdb_dev, Очевидных? Спасибо, поржал. Давно для себя сделал вывод, что очевидное для меня вовсе не очевидно другим. Разбирая очередную поделку команды "ух" разработчиков, почти каждый раз в этом убеждаюсь. Потому скепсис - наше всё. Предпочитаю приятно удивляться, что в этот раз сделано правильно разумно.В крайнем случае, можно полагаться на уникальность идентификатора модуля. Такой вариант должен соответствовать: Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 10:59 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Народ, давайте снова. Таблица umass большая, defect тоже. Какой смысл сканировать в лоб всё, если мне нужно узнать только наличие дочерних записей? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 11:02 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, покажи план который был в изначальном запросе с exists ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 11:10 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, так укажи запросу тот план, что считаешь правильным. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 11:10 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> Какой смысл сканировать в лоб всё Зачем ты начинаешь вещать рассуждать, не понимая азов? Повторяю - покажи план изначального запроса. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 11:22 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
План первого запроса: авторПлан PLAN JOIN (B INDEX (FK_UMASS_RELATIONS_MODUL), C INDEX (DEFECT_IDX1)) PLAN (A NATURAL) DEFECT_IDX1 - это индекс по id_ums. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 11:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, попробуй вот так Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 11:56 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> План первого запроса: В нём что-то не устраивает? Маленькая сканится, большие по индексу. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:12 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис, Чуть исправил, в exists вместо on поставил where. План: авторПлан PLAN (C INDEX (DEFECT_IDX1)) PLAN JOIN (B NATURAL, A INDEX (PK_MODUL)) Может как-то не через select? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:12 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Кстати, какие объёмы данных (сейчас и ожидаемые) ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:12 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, ошибся мальца. На план не смотри если не понимаешь скорость по сравнению с другими вариантами устраивает? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:16 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, тьфу. Этот запрос тоже не правильный. Короче либо вариант с DISTINCT либо изначальный EXISTS ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:18 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис> скорость по сравнению с другими вариантами устраивает? Так он и скорость щас оценить не может, если у него самая большая (в будущем) таблица пока пустая. Надо на количество фетчей смотреть, если он умеет. P.S. Нет никаких вариантов без DISTINCTа, равносильных первоначальному по результату - ни рабоче-крестьянских, ни дворянско-аристократических. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:32 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, есть, но я сомневаюсь что они будут лучше ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:34 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис> есть ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
А, ты про всякие переборы вручную. Несерьёзно. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов ДенисГаджимурадов Рустам, есть, но я сомневаюсь что они будут лучшеCount(), HEAVING ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:53 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
HEAVING звучит замечательно, но это тот же дистинкт, только в профиль. И ничем не лучше. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 12:58 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамP.S. Нет никаких вариантов без DISTINCTа, равносильных первоначальному по результату - ни рабоче-крестьянских, ни дворянско-аристократических. Ну как нет? Попробуйте мне объяснить. Есть таблица modul, у каждой записи таблицы modul может быть до 30 дочерних записей в umass. У каждой записи umass может быть до 100 записей в defect. В modul записей почти миллион, в umass хорошо за два миллиона, в дефект пока чуть меньше ста тысяч. Мне нужны записи в modul, где есть дочерние записи в defect. Записи в таблице defect более-менее равномерно размазаны по umass. Т.е. по моей человеческой логике вероятность нарваться на запись в defect велика, и сканирование по umass большого числа записей не должно быть. Вот как мне получить результат? Вообще мне кажется и схема данных нормальная, и хотелка тоже нужная. Я вообще хотел ещё верхний уровень приклеить. Но пока нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:00 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, ну например Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:04 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, можно пойти от обратного - если записи в defect существуют только для modul через umass, то тебе надо лишь выбрать из defect единичные (DISTINCT) id_ums и по натуралу привязать к выборке сначала umass, а затем modul. Как-то так: Код: sql 1. 2. 3. 4. 5.
Попробуй, вдруг повезет! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:37 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> в дефект пока чуть меньше ста тысяч А будет сколько и когда? Сколько из modul должно выбраться в итоге (в процентах)? И какие есть (если есть) доп.фильтры по каждой из таблиц. Из того, что ты пока рассказал - оставь изначальный вариант. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:40 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денис> group by b.id_mdl Я ж говорю, профиль Фаберже. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:41 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIПланPLAN (C INDEX (DEFECT_IDX1)) PLAN JOIN (B NATURAL, A INDEX (PK_MODUL)) Может как-то не через select? При соотношении modul и umass 1:3 вполне нормальный вариант. Или всё же планируешь до 1:20 довести? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:41 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev> Iiigiaoe, aagoa iiaacao! :) Замечательный подход к разработке. Ламером был - ламером и помрёшь. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:42 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSery> При соотношении modul и umass 1:3 вполне нормальный вариант. > Или всё же планируешь до 1:20 довести? Там 1-30-100. Не вариант справа налево. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:43 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_devПопробуй, вдруг повезет! :)Хороший совет, собирать дистинкт по всей таблице с планируемым объёмом более 100 миллионов записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:43 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIГаджимурадов РустамP.S. Нет никаких вариантов без DISTINCTа, равносильных первоначальному по результату - ни рабоче-крестьянских, ни дворянско-аристократических. Ну как нет? Попробуйте мне объяснить. Есть таблица modul, у каждой записи таблицы modul может быть до 30 дочерних записей в umass. У каждой записи umass может быть до 100 записей в defect. В modul записей почти миллион, в umass хорошо за два миллиона, в дефект пока чуть меньше ста тысяч. Мне нужны записи в modul, где есть дочерние записи в defect. Записи в таблице defect более-менее равномерно размазаны по umass. Т.е. по моей человеческой логике вероятность нарваться на запись в defect велика, и сканирование по umass большого числа записей не должно быть. Вот как мне получить результат? Вообще мне кажется и схема данных нормальная, и хотелка тоже нужная. Я вообще хотел ещё верхний уровень приклеить. Но пока нет. Ну так разверни джойн при помощи заклинаний +0 так, чтобы перебор начинался с дефектов. Но когда/если их таблица распухнет до безобразия, это встанет колом. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:43 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамТам 1-30-100. Не вариант справа налево.Рустам, пусть автор ответит. Это максимально плохое соотношение. Но пока из его речи следует, что только таблица дефектов не наполнена, остальные, значит, в более-менее рабочем состоянии, и текущее соотношение 1:3 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:45 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSery> и текущее соотношение 1:3 Гм... Ты предлагаешь переписывать запрос позже или что? P.S. Повторюсь в третий раз - надо танцевать от доп.фильтров. Наверняка они есть, не может быть регулярная выборка ляма записей мастера с мульти-лямами деталей без доп.фильтров. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 13:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустамrdb_dev> Iiigiaoe, aagoa iiaacao! :) Замечательный подход к разработке. Ламером был - ламером и помрёшь. И это вещает человек, не знакомый с теорией множеств и откуда взялся JOIN в SQL? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:00 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSeryrdb_devПопробуй, вдруг повезет! :)Хороший совет, собирать дистинкт по всей таблице с планируемым объёмом более 100 миллионов записей.Хочешь сказать, что DISTINCT не способен к отбору по индексу, в частности по FK к umass? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:03 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev> Хочешь сказать, что DISTINCT не способен к отбору по индексу Это какой-то феерический песец... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:09 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Да чё вы докопались до Distinct. Пробовать надо. Вряд ли там тысячи дубликатов каждого значения, но вопрошающему виднее. Сортировка резалтсета - не особо затратная операция на умеренном количестве дубликатов. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:14 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_devDISTINCT не способен к отбору по индексу distinct еще с ИБ 6.0 делается исключительно через SORT. Даже если бы он был "по индексу", то не отбором, а проходом, через table order index (как group by, order by...). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:26 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка, Автор написал, что до 100. Да, это мало. И сортировка быстрая. Вот только "родительских" записей сейчас уже почти три миллиона. А провести три миллиона сортировок - это уже совсем другая история. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:27 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, Если это такой частый запрос, тут самое место для хранимого агрегата. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:29 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
WildSeryГаджимурадов РустамТам 1-30-100. Не вариант справа налево.Рустам, пусть автор ответит. Это максимально плохое соотношение. Но пока из его речи следует, что только таблица дефектов не наполнена, остальные, значит, в более-менее рабочем состоянии, и текущее соотношение 1:3 А что автор ответит? Какая-то нестандартная схема работы? Описать бизнес процесс? Мне представляется невозможным просчитывать соотношения количества записей в таблицах. Все таблицы растут, defect явно меньше umass. Пусть планировщик FB сам решает по какому пути пойти. Естественно, ни о каком ручном подборе плана не может идти речи. И фильтров, собственно, нет. И, самое главное, почему Exists? Надо знать - Есть записи или нет. А какие они там - другой вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:30 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, с точки зрения множеств, тут хоть тресни - либо modul + (umass + defect), либо (modul + umass) + defect т.е. из трех множеств получить 2, и их уже склеить. Более быстрым вариантом, на мой взгляд, при имеющемся соотношении записей является modul + (umass + defect). Не пробовал вариант - from modul where exists (from umass where exists (defect)) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:37 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
kdvrdb_devDISTINCT не способен к отбору по индексу distinct еще с ИБ 6.0 делается исключительно через SORT. Даже если бы он был "по индексу", то не отбором, а проходом, через table order index (как group by, order by...).Правильно поправил - именно проходом. Странно, что в ФБ до сих пор DISTINCT только по натуралу. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:40 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev, во-первых не по натуралы, а внешней сортировкой. Во-вторых distinct применяется ко всем полям в предложении select. А в-третьих с чего ты взял что навигация по индексы будет быстрее при полном фетче? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:47 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev...Странно, что в ФБ до сих пор DISTINCT только по натуралу. А как еще, если все поля учитываются? Рассказывай. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:48 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
kdvKreatorXXI, с точки зрения множеств, тут хоть тресни - либо modul + (umass + defect), либо (modul + umass) + defect т.е. из трех множеств получить 2, и их уже склеить. Более быстрым вариантом, на мой взгляд, при имеющемся соотношении записей является modul + (umass + defect). Не пробовал вариант - from modul where exists (from umass where exists (defect)) ? Кто такой умасс я не догадываюсь, но слова модуль и дефект таки порождают смутные ассоциации из объективной реальности. И что-то мне шепчет, что у реального модуля вряд ли бывает больше пяти типов возможных дефектов. А вот один и тот же дефект (например, "не фурычит") может иметь чортова прорва типов модулей. То есть, количество возможных типов дефектов, по сравнению со всевозможными модулями, скорее всего, зело ограниченное. Начинать перебор от них мне представляется разумным. Хотя могу быть введён в заблуждение семантическими экивоками. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денисrdb_dev, во-первых не по натуралы, а внешней сортировкой.А "внешняя сортировка" в плане как выглядит? PLAN SORT(table NATURAL) - сортировка по значениям всех полей в SELECT записей, отобранных без использования индекса? Симонов ДенисВо-вторых distinct применяется ко всем полям в предложении select. А в-третьих с чего ты взял что навигация по индексы будет быстрее при полном фетче?Если все указанные в SELECT поля попадают в индекс, что мешает планировщику использовать именно индекс? Всего лишь отсутствие такой возможности, не так ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 14:58 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
kdvНе пробовал вариант - from modul where exists (from umass where exists (defect)) ? Примерно тоже самое. Необычный результат получается, если попробовать использовать конструкцию "first 1". Может попробовать перебрать возможные варианты с ней? А? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 15:01 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаслова модуль и дефект таки порождают смутные ассоциации из объективной реальности. И что-то мне шепчет, что у реального модуля вряд ли бывает больше пяти типов возможных дефектов. А вот один и тот же дефект (например, "не фурычит") может иметь чортова прорва типов модулей. То есть, количество возможных типов дефектов, по сравнению со всевозможными модулями, скорее всего, зело ограниченное. Начинать перебор от них мне представляется разумным. Хотя могу быть введён в заблуждение семантическими экивоками. Кстати, да, +1. KreatorXXI> Мне представляется невозможным просчитывать KreatorXXI> соотношения количества записей в таблицах. Гм... Ну если сам не можешь просчитать - хоть аналитика постановщика вашего спроси/попроси. KreatorXXI> И фильтров, собственно, нет. Да ладно врать... ОК, вот выбрал ты записи каким-то макаром, получил из ляма 15 тыщ - дальше с ними что собрался делать? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 15:06 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> Необычный результат получается Чем же он необычный? Быстрее или результат отличается? > Может попробовать перебрать возможные варианты с ней? А? Не может. "first 1" с Exist-ом не нужен. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 15:08 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Вариант "а-ля DISTINCT" использующий индексы. Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 17:12 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
rdb_dev, не правильный запрос. У него defect->umass->modul Т.е. производную таблицу с GROUP BY надо делать по связке двух таблиц. Я этот вариант уже приводил через CTE ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 17:18 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Симонов Денисrdb_dev, Т.е. производную таблицу с GROUP BY надо делать по связке двух таблиц. Я этот вариант уже приводил через CTEСогласен! Проглядел приведенный тобой код. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.09.2017, 21:51 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
а так? Код: sql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.09.2017, 02:17 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаХотя могу быть введён в заблуждение семантическими экивоками. Именно так. В defect пишутся выявленные проблемы в изделии. vvvaitа так? Код: sql 1. 2. 3. 4. 5. 6. 7.
По барабану, всё также. Что называется - "От перемены мест слагаемых сумма не меняется". Попробовал через хранимку, через "for select". Банально, находится запись в defect, выходим из хранимки. С точки зрения количества сканированных записей получен очень хороший результат, раз в 30 меньше. Но с точки зрения времени выполнения - очень плохо. Время уходит на подготовку "for select"? Или сам вызов хранимки? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 17:54 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIБанально, находится запись в defect, выходим из хранимки. Это ничем не отличается от exists, только тормознее. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 18:00 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> В defect пишутся выявленные проблемы в изделии. А umass что? > Попробовал через хранимку, через "for select". Банально, находится > запись в defect, выходим из хранимки. Во-первых, если делать хранимку, то делать весь запрос в хранимке, а не его часть. Во-вторых, хранимка тут вряд ли чем-то поможет, слишком простой случай. В-третьих, "находим-выходим" - это как тупой exists, он именно так и работает. > С точки зрения количества сканированных записей получен очень > хороший результат, раз в 30 меньше. Не похоже на правду. Показывай текст хранимки, планы и время + количество фетчей. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 18:01 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI, а как ты это количество сканированных записей определяешь? Трейсом что ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 18:01 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
vvvaitwhere exists ( select * from umass b left join defect так получится, что umass left join defect выдаст ВСЕ записи из umass для проверки на exists, а без defect они к делу не относятся. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 18:05 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4.
? Предполагается, что все индексы имеют место быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 18:49 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка Код: sql 1. 2. 3. 4.
? Предполагается, что все индексы имеют место быть. Индексы для дистинкт? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2017, 18:59 |
|
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 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXIГаджимурадов Рустам> Денормализацию modul_id в дефекты для данной задачи не советую. Как раз, ИМХО, это реальный путь. Потому что может быть много разных условий (были ли вообще ВД, есть ли незакрытые и ещё масса признаков, которые пишутся в defect). Не факт, что будет всё востребовано, но вдруг. Может и загоняемся. Хотелось сразу в комбобоксе отсечь "бездефектные" изделия. По мне лучше тогда пусть отображаются все, при выборе "бездефектных" просто не будет конкретики и всё. Чем выдумывать не совсем логичные схемы.Исходя из вышеописанного тобой, ИМХО, тебе нужна отдельная таблица неустраненных дефектов: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
В триггере ДО удаления/обновления/добавления таблицы defect лочить запись таблицы defects_count с нужным идентификатором module_id, а в триггере ПОСЛЕ удаления/обновления/добавления эту запись обновлять - уменьшать/увеличивать на единицу, соответственно. Еще раз в сутки, во время обслуживания БД, запускать хранимую процедуру, проверяющую целостность - вычисляющую реальное количество дефектов для каждого module_id по таблице defect, сравнивающую со значением в таблице defects_count и, при расхождении, исправляющую это значение. Как-то так... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 11:52 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
kdv> Здесь можно так же сделать. Какой ужас... Нет, здесь не надо так делать. :) И modul_id, и has_defects на порядок лучше. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 11:57 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, почему ужас-то? вполне себе полезное дублирование. Никаких многопользовательских конфликтов, и целостность вполне триггерами обеспечивается. Правда, у автора структура не совсем такая. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 12:06 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Вы знаете почему меня больше устраивает внедрение в defect доп. полей? У нас есть ещё подобная таблица, подвязанная к umass, с другой структурой и для других целей. И с ней такой же будет вопрос (пока не поднялся). В принципе не исключаю ещё подобных вопросов с другими таблицами. Подобное производство так работает. Структуру данных особо не поменяешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 12:44 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
KreatorXXI> Вы знаете почему меня больше устраивает внедрение в defect доп. полей? KreatorXXI> У нас есть ещё подобная таблица, подвязанная к umass, с другой структурой KreatorXXI> и для других целей. И с ней такой же будет вопрос (пока не поднялся). Ну будет их две, три - не тридцать же. Считать надо не количество таблиц, а количество... "признаков". Вот в данном случае "имеет дефекты" является признаком (при чем не изделия, а паспорта - это, видимо его модификация). Для понимания можно воспринимать/называть признак не как "дефективный", а как "протестированный и готовый к ..." > Подобное производство так работает. Структуру данных особо не поменяешь. Но именно структуру вы и собираетесь менять. :) Думать надо в первую очередь с т.з. бизнес-логики, а не БД и пр. технологических тонкостей. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 13:12 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
> делать в таблице изделий признак (поле) "has defects" > (или "defective", как больше нравится), который будет > проставляться (видимо по визе ОТК) в true/false. Щас подумал, вспоминая схему работы ОТК - он ведь тоже в вашей системе работает - наверняка, сама эта виза является документом и имеет кучу атрибутов (дата, проверяющие etc), а список дефектов - лишь приложение к ней. Вот по этому документу вы и могли бы как раз получить список изделий с дефектами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 13:16 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, "Визы" мастера и ОТК хранятся как раз в umass. Вот к этой таблице и подвязываем. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 15:38 |
|
Exists по двум или более таблицам
|
|||
---|---|---|---|
#18+
Вроде как в umass хранились некие операции (не понял, что это). Но в любом случае, механизм тот же - если ОТК в своей визе сказал "проверил, дефектов нет" - соотв. признак и надо проставлять для конкретного паспорта (или группы, если виза групповая). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2017, 17:34 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1561418]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
117ms |
get tp. blocked users: |
1ms |
others: | 296ms |
total: | 511ms |
0 / 0 |