|
Сложный запрос
|
|||
---|---|---|---|
#18+
Всем привет, большая проблема, очень нужна помощь(( Есть база пациентов, случаев очень много, на данный момент 5 миллионов, ну и каждый месяц естественно добавляются новые. Задача в том, что нужно выбрать повторные случаи, то есть, если один и тот же человек с одним полисом посещал несколько раз медицинское учреждение, ну и плюс кое-какие условия, типа совпадает специальность врача, цель посещения и т.д, то тогда эти случаи нужно отобрать. В базе есть разные таблицы, основная - случай лечения, которая соединяется с таблицей пациентов. Один и тот же человек может быть в таблице пациентов под несколькими id. Проблема в том, что когда там много записей процедура, отбирающая эти случаи отрабатывает ооооочень долго. Ну естественно, потому что таблица объединяется сама с собой... Как быть в такой ситуации? Может быть у кого-то было что-то похожее? Каким образом можно попытаться ускорить? Дайте совет пожалуйста ( ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:27 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Тут нужен программист, освоивший язык SQL до слов GROUP BY и HAVING. А соединять таблицу с собой при этом совсем не нужно. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:34 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, нельзя просто сгруппировать по номеру полису и взять >1. Одно из условий на дату посещения, если больше 15 дней, то повторным уже не считается ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:48 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_заянельзя Можно. Кареглазая_заяесли больше 15 дней, то повторным уже не считается А если было четыре посещения с периодом в две недели каждое, это как считается? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:54 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_зая> нельзя Зачем спорить, если элементарно не хватает квалификации? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:58 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, все 4 должны быть отобраны. Первый потому что у него есть второе посещение и разница дней между ними не больше 15, у второго третье, у третьего четвертое ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 23:02 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, я не спорю. А говорю, что обычной группировкой тут не обойдешься ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 23:12 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Вот примерная структура r_pacient : id, polis, dr r_schet : id, id_type r_sl : id, id_schet, id_r_pacient, dt_end, mkb, pos, nomlpu Выбрать r_schet.id, r_sl.id , r_sl.nomlpu, такие, что возраст (r_pacient.dr) < 65 посещения (r_sl.dt_end)между двумя случаями <16 исключить r_sl.mkb на букву O, r_schet.id_type 1, пары с r_sl1.pos = 2 , а r_sl2.pos =1, если r_sl1.dt_end < r_sl2.dt_end Помогите пожалуйста тогда написать запрос! ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 23:31 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Как-то так. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 00:14 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, как-то так я сейчас и делаю. Правда соединять надо не по id_r_pacient, а по полису. Но таблица r_sl очень большая, можно ли каким-нибудь образом exists заменить? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 01:22 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
А я бы вообще запросом не делал, а набросал ХП, в которой можно было бы спокойно учесть все предикаты, нюансы и перламутровые пуговицы, которые через неделю всплывут. Заодно подзапроса можно будет выкинуть, одного цикла хватит. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 01:32 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, ХП - хранимая процедура? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 01:46 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_заятаблица r_sl очень большая, можно ли каким-нибудь образом exists заменить?Я бы в 1-ю очередь обратил внимание на join'ы - они по-умолчанию inner, если я не ошибаюсь. Если есть возможность, лучше заменять их на left/right [outer] join'ы - они работают "в один проход" при чем "с нужной стороны", в отличие от inner. Например, если к основной таблице чз left join присоединить другую с записями по ключу - такое соединение пройдет наиболее безболезненно по времени. Что касается exists - он работает быстро, ведь он в WHERE и не участвует в соединении таблиц, а только в фильтрации результата. Можно попробовать и приджойнить "себя же" и в WHERE только даты сравнивать, но я очень сомневаюсь, что будет быстрее. Да, еще, основное условие "mkb not starting with 'O'" ужасно, по полю mkb с таким условием индекс сомневаюсь, что получится использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 02:07 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Да, а долго будет в любом случае, т.к. условия идут по второстепенным таблицам, а значит наверняка перебираются все записи основной большой таблицы не по индексу. Чтобы хоть часть отсечь в таком случае - придется основной таблицей делать пациентов - их можно по возрасту по индексу фильтрануть. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 02:21 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockЕсли есть возможность, лучше заменять их на left/right [outer] join'ы - они работают "в один проход" при чем "с нужной стороны", в отличие от inner. Например, если к основной таблице чз left join присоединить другую с записями по ключу - такое соединение пройдет наиболее безболезненно по времени. А давай ты не будешь говорить о том в чём совсем не смыслишь. Оба твоих сообщения полнейшая чушь ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 06:58 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_заяОдин и тот же человек может быть в таблице пациентов под несколькими id. Бардак. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 08:41 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
wadmanКареглазая_заяОдин и тот же человек может быть в таблице пациентов под несколькими id. Бардак. Надо Дока звать, он предметную часть знает. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:44 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_заякак-то так я сейчас и делаю. Тогда в полный рост встаёт вопрос планов, статистики, наличия индексов и прочий высший пилотаж. Раз уж хитроподвывернутые условия так криво ложатся на схему БД. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:56 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
GallemarНадо Дока звать не надо, "я еще не волшебник..." © :) С wadman согласен на 146%, бардак полнейший. Полис ОМС у россиянина один на всю жизнь. А тут ТС даже структуры базы нормально показать не может. Трудно ей будет у нас ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:06 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_зая, Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:09 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Док, сложно, я просто не знаю как объяснить по-нормальному, чтобы и ненужных вещей не говорить и в тоже время суть. А насчет id пациента, никакого бардака нет. Такую информацию передает Фонд ОМС, а связано с тем, что пациенты выгружаются помесячно - счетами, и соответственно в каждом счете id пациента уникально, а счетов мб много. Такая структура. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:31 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов ДенисYuRockЕсли есть возможность, лучше заменять их на left/right [outer] join'ы - они работают "в один проход" при чем "с нужной стороны", в отличие от inner. Например, если к основной таблице чз left join присоединить другую с записями по ключу - такое соединение пройдет наиболее безболезненно по времени. А давай ты не будешь говорить о том в чём совсем не смыслишь. Оба твоих сообщения полнейшая чушь Окей, чушь, но я написал всё это исходя из своего опыта и своего понимания, как это всё работает. P.S. Ты утверждаешь, что inner и left join'ы -одинаковы по быстродействию, т.е. для сервера работы одинаковое количество для этих двух видов соединения таблиц? Я считаю, что нет, и left легче, а ты написал - что это полная чушь. Так вот, повторяю вопрос: "Ты утверждаешь, что inner и left join'ы -одинаковы по быстродействию, т.е. для сервера работы одинаковое количество для этих двух видов соединения таблиц?" ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:37 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
авторПолис ОМС у россиянина один на всю жизнь. За свою недолгую жизнь я в прошлом году получил уже третий полис. Так шта... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:37 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRock, твой опыт весьма поверхностный. Я привык доверять оптимизатору и только если меня не устраивает быстродействие, то рассматриваю как можно самостоятельно оптимизировать запрос. Золотое правило не пытаться преждевременно оптимизировать. И да в случае inner join вариантов выполнения много больше. Оптимизатор может принять лучшее решение и только если он это делает неправильно нужно рассматривать другие варианты. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:43 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов ДенисYuRock, Я привык доверять оптимизатору и только если меня не устраивает быстродействие, то рассматриваю как можно самостоятельно оптимизировать запрос. Золотое правило не пытаться преждевременно оптимизировать. И да в случае inner join вариантов выполнения много больше. Оптимизатор может принять лучшее решение и только если он это делает неправильно нужно рассматривать другие варианты. Именно так я и поступаю тоже всегда. Сдесь же ТС обратился с просьбой дать идеи, как попробовать оптимизировать запрос, который выполняется "оооочень долго". Я дал свои советы, исходя из своего опята. Симонов ДенисОба твоих сообщения полнейшая чушь. Симонов Дениствой опыт весьма поверхностный. Тут можешь продолжать и дальше, меня подобные высказывания не трогают. Только ты ответь: Ты действительно считаешь чушью (как ты и написал), что left легче inner? Или просто у самого чушь вырвалась случайно? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:49 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockсчитаешь чушью (как ты и написал), что left легче inner? что значит "легче"? "тяжесть" выполнения запроса зависит от плана. left/right приводят к принудительному порядку объединения таблиц. А у inner или неявных join сервер может сам определить порядок объединения таблиц. Так что да - про "легче" это если не чушь, то собственная терминология, которая далека от реальности. Сравнивать принудительный порядок и произвольный? Да еще учитывая, что планы могут оказаться одинаковыми. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:59 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockЕсли есть возможность, лучше заменять их на left/right [outer] join'ы - они работают "в один проход" при чем "с нужной стороны", в отличие от inner. например, вот это чушь. То есть, inner работает "в два прохода", что-ли? Одинаково они работают, просто генерируют разные планы (а иногда и одинаковые). Через left/right ты просто можешь принудительно "задать план", который "работает быстрее". p.s. про "работает быстрее" - зависит от того, выбирается несколько первых записей, или fetch all. Один и тот же массив записей может выбираться разное время, в зависимости от плана запроса (методов доступа). рекомендую перечитать http://www.ibase.ru/dataaccesspaths/ как минимум пункт 3.1 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:05 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockСдесь же ТС обратился с просьбой дать идеи, как попробовать оптимизировать запрос, который выполняется "оооочень долго". Ты план запроса видел? Вполне возможно надо просто где-то индекс создать, может +0, а может и вовсе запрос переписать. А ты свои left join без причины пытаешься воткнуть. То что starting with не может использовать индекс тоже чушь. И то что left "легче" inner я действительно считаю чушью. З.Ы. Тут никто не пытается тебя оскорбить или ущемить твоё самолюбие, но ты действительно не сечёшь фишку. Почитай приведённую kdv статью. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:22 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
На данный момент вот такой запрос, он отрабатывает быстрее чем с exists, но совсем неправильно Например один человек сходил 3 раза в поликлинику, 28.03 - sl.id = 1, 10.04 -sl.id = 2, 13.04 - sl.id = 3. Запрос отрабатывает таким образом, что в результате находятся пары 1 - 2, 2 - 3. То есть вместо трех отбираются четыре 1,2,2,3. Это можно как-то исправить? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:24 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_зая, версия сервера какая? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:36 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов Денис, 2.1. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:00 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
kdvнапример, вот это чушь. То есть, inner работает "в два прохода", что-ли? Одинаково они работают, просто генерируют разные планы (а иногда и одинаковые). Через left/right ты просто можешь принудительно "задать план", который "работает быстрее". Как минимум я отключаю работу оптимизитора (для этого момента), а так же страхуюсь от его возможных ошибок. Кстати, сейчас провел некоторые тесты своих запросов 14-летней давности на тройке, поменял LEFT на INNER. И, да, план и быстродействие оказались одинаковыми. В то время такого щастья не было, отсюда и привычка "заранее отсекать неверный план". Вот честно, мне сейчас очень сложно будет перестроиться и НЕ писать LEFT там, где я уверен, что он будет оптимален. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:09 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRock, не ну 14 лет назад оптимизатор был так себе. Сейчас намного лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:15 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов ДенисТы план запроса видел? Вполне возможно надо просто где-то индекс создать, может +0, а может и вовсе запрос переписать. А ты свои left join без причины пытаешься воткнуть. Как оказалось, версия 2.1, а на ней оптимизатор еще не тот, что сейчас. План, конечно, смотреть надо. Симонов ДенисТо что starting with не может использовать индекс тоже чушь. Ты цитируешь то, что я НЕ писал. Я писал: " not starting with" а так же "индекс сомневаюсь, что получится использовать". Симонов ДенисИ то что left "легче" inner я действительно считаю чушью. Возможно сейчас, когда оптимизатор стал достаточно хорош, это и так. А раньше план мог измениться в "неправильную сторону" просто при накоплении данных в базу, и приходилось его "направлять", и поэтому лучше было сразу так делать. Симонов ДенисЗ.Ы. Тут никто не пытается тебя оскорбить или ущемить твоё самолюбие Это я понимаю прекрасно, тут все на нервах постоянно) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:17 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockСимонов ДенисТо что starting with не может использовать индекс тоже чушь. Ты цитируешь то, что я НЕ писал. Я писал: " not starting with" а так же "индекс сомневаюсь, что получится использовать". Уже и не сомневаюсь. Проверил только что на 3.0.1, который у меня в продакшене: Код: sql 1. 2. 3.
Планы такие: PLAN (C NATURAL) и если NOT убрать: PLAN (C INDEX (PK_COMMANDS)) есть PRIMARY KEY (COMMAND_ID), COMMAND_ID CHAR(4) NOT NULL ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:23 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRock, not я проглядел, там в принципе индекс проблематично использовать ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:27 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_зая, Мда, тут уже проще выполнить в процедуре наиболее простой запрос с этими страшными условиями, отстртировав по "НомеруПолиса,Дате", и затем в цикле инсертить, если надо. Так хотя бы наглядно будет. Другое дело, как в процедуру эти условия передавать трёхэтажные.. Их лучше в отдельной таблице хранить - как "настройки отчета". ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 14:07 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов Денисне ну 14 лет назад оптимизатор был так себе. Сейчас намного лучше."Так себе" только по сравнению с новым. Работал и ладно. Всегда как-то хватало псевдо-хинтов, да и то нечасто. Вот чтобы LEFT приходилось писать - это только когда с процедурой соединение, других случаев не припоминаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 15:20 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1561558]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
141ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 262ms |
0 / 0 |