Подзаявка в условие ON за LEFT JOIN и в MySQL
Изрових всички stackoverflows и уморих Google, но все още не разбирам защо MySQL заявката (по-долу) не работи правилно. Моля, подайте ръка за помощ или я хвърлете в лицето на дока).Задача: Трябва да получим последната дата от таблицата със статистически данни за всеки потребител. ER диаграма (опростена):
Проблем: Защо LIMIT не работи с клауза WHERE в подзаявка? Възможно е да получа датата с проста подзаявка, но трябва да получа допълнителни полета, които не съм посочил в опростената схема. И такива полета
5, т.е. ще има 5 подзаявки. Какво ще бъде по-бързо, не съм сигурен, но засега съм склонен, че LEFT JOIN ще бъде по-бързо. Да, и въпросът вече е основен - убих половин ден.
Благодаря ви предварително за съдействието.
В резултат на това добавих сурогатен PK, вместо 3 съставни полета. Ако не вземете предвид денормализирането на базата данни, мисля, че това е най-доброто решение. Последна заявка:
Получавам данните, от които се нуждая - всички полета от последния запис на таблицата със статистики с произволен тип (можете да посочите конкретен тип) за всеки потребител. В този случай сортирането по ID ще бъде по-бързо, отколкото по дата. Записът за JOIN вече е недвусмислен, ситуацията с избиране на няколко записа на статистика с една и съща дата е разрешена. Остава да се работи с повече или по-малко реален набор от данни и да се оцени ефективността. Благодаря на всички за помощта.
Разбирам, че това не е отговорът, който очаквате, но ако не греша, тази заявка ще работи правилно:
WHERE U.id =1 - по избор :)
Съжалявам, може би не съм разбрал съвсем. Но според мен може да бъде някак по-просто:
Не съм проверявал, честно казано.
Вашата заявка не работи, защото сте избрали същия user_id от подзаявката, която сте „подали вътре“. другиС други думи, вашето запитване е идентично със следното:
Как да го направите правилно, вече е написано по-горе. IMHO, опцията за групиране би била най-добра и по-четлива. Въпреки че е по-добре да сравните производителността с реални данни. За всеки случай запазете самата заявка:
Прочетох: Вашата заявка не работи, защото сте избрали същия user_id от подзаявката, която сте „изпратили вътре“ Добре, предавам само число = потребителски идентификатор на условието за залепване:
Защо очаквам, че използвайки условието LIMIT 1 в подзаявката, само един запис от таблицата със статистически данни трябва да бъде „слепен заедно“? И с такава заявка всички записи от статистиката се присъединяват към всеки потребител.
Като цяло, помислих си тук, правилният начин е модифицирана версия на shedal:
По идея при такава заявка ще има само три селекции. И, разбира се, обвързването на user_id + дата трябва да е уникално, в противен случай записите ще се удвоят, но това може да се реши с помощта на DISTINCT или същата GROUP BY.
Въз основа на първоначалния проблем, не разбирам съвсем целта на втората статистика на LEFT JOIN AS присъединяване. В лабораторния пример не се изисква user_id + date да бъдат уникални, тъй като PK се състои от user_id + date + type. Но това изглежда не променя същността на задачата - трябва да получите _един_ последен запис на статистика.
1. Например, трябва да получите най-новото състояние за всеки тип (тип):
… има. Всичко се събира в данните от теста. Второто присъединяване не е необходимо.
2. Трябва да получите най-новата статистика, като вземете предвид вида:
Все още не виждам нужда от допълнително присъединяване. Може би идеите ни за условията на проблема не се сближават? Или в моята заявка (без това присъединяване) ще получим допълнителни полета от таблицата със статистически данни в произволен ред поради групиране?
И ако LIMIT бъде премахнат, ще се свърже ли с всички записи? В SQLite,например, може да се използва идентификаторът на вътрешния ред без ограничение, т.е. той ще бъде:
но изрично посочва, че (SELECT y . ) в израза връща първия съответстващ запис, а не всички; Не знам как с това в MySQL.
10 000, за всеки потребител се добавят до 2-3 хиляди статистически записа на ден. Тук въпросът е, че има ТИП запис в таблицата със статистики. И ще трябва да запазите последната дата за всеки тип. Типовете се добавят при необходимост, очакват се общо 10-20 вида. Оказва се, че в статистиката има например 3 полета с потребителски данни + дата + тип. Ако съхранявате най-новите исторически данни (статистика) в самата потребителска таблица: 1. Ако е необходимо, ще трябва да се добавят нови полета, когато се появи нов ТИП статистика; 2. В резултат на това ще има 3 * N типа полета, което е още един плюс от 30-60 полета към основните данни на потребителя. По някакъв начин също не е добре. Имате ли някакви мисли по този въпрос? Благодаря ти.
Ако не харесвате модела със създаване на статистически атрибути в клиентския обект, тогава опитайте в най-простия случай да запазите една таблица за действителните статистически стойности с PK [user_id, stat_type] + таблица с исторически стойности (одит таблица), която ще поддържате на тригери, ако първата се промени.
В още по-сложен случай тези таблици могат да се комбинират (както имате сега - първоначално), но за да ускорите заявките, добавете текущия флаг, който ще бъде или 1, или NULL + [current, user_id] съставен индекс. Задействащият gemmor от предишната версия ще изчезне, заменен от текущия флаг, придружаващ gemmor. Всички варианти за организиране на такива исторически справочници с "+" и "-" са описани в статията на Уикипедия по темата "бавно променящи се измерения".
Задайте си въпрос, различен от следи от грешки и редкиАнализатори, наистина ли е важно за вас да управлявате заявки за получаване на исторически и действителни данни в една таблица? Ако не, първият вариант е самото нещо + разделяне и изтриване на най-старите дялове в планировчика (на вкус).
полу годишно). И тук динамиката на видовете статистики е доста динамична. И съм объркан от крайния набор от + ". 30-60 полета към основните данни на потребителя." В същото време статистическите данни се актуализират за всеки запис.
веднъж на минута. Наистина ли е важно за вас да изпълнявате заявки за получаване на исторически и текущи данни в една таблица? Не, но обикновено денормализирам след проектиране на пълната структура на базата данни. Просто изчислявам, че броят на заявките за избор = заявки за вмъкване, добре, може би SELECT ще бъде с 20% повече. В оригинал това не са потребители, а прокси сървър и след заявка и обработка на проксито логваме резултата. Потребителите, може би, не трябва да се наричат лабораторни единици, твърде опростени. Оказва се, че за една таблица със статистика сме вмъкнали нов журнал и сме забравили. А в случай на допълнителна таблица с актуални данни, трябва всеки път да проверявате съществуването на запис и или да вмъквате нов, или да актуализирате съществуващия. Това е моментът, който ме обърква. Не мога да кажа веднага кое ще бъде по-бързо. И как най-добре да разпределите натоварването - върху пробата или върху вложката. Изглежда, че трябва да се тества върху среден обем данни. Благодаря за подсказката и за статията, не я прочетох.