И как вы собираетесь решать через rank() без подзапросов? Без подзапросов я только одно решение в комментах видел и оно было вовсе не через rank(). И да, с ужасной производительностью.
Ваш первый вариант, грубая ошибка. Допустим у одно сотрудника максимальная зарплата по отделу 200. А у другого такая же зарплата, но он в другом отделе и у него зарплата там не максимальная. У вас второго тоже выведет. Второй вариант, там ошибка еще грубее. Вы выведите сотрудников с минимальной зарплатой в отделе. Третий. Да, это первое, что приходит в голову и на проверку оказалось что лучший вариант. У меня такой же, только первый, под именем max.
Ох, distinct on() это не функция. Это во первых. Во-вторых ваш запрос не работает. В третьих при его написании вы допустили грубые ошибки. В четвертых вариант решения с помощью distinct, действительно, существуют, но они выдают только одного сотрудника с максимальной зарплатой, а в случае если в отделе несколько сотрудников с максимальной зарплатой, их надо вывести всех.
Если у двух разных сотрудников одинаковая зарплата, то это уже не дубликаты. Более того, если вы имели хоть какое-то отношение к математике и решали, например, уравнения, то ответом решения задачи будет все возможные решения. Написать только одно - грубая ошибка.
Похожее было, но у вас есть отличия. Во первых left join в employees left join departments не нужен, потому что я авторским произволом в DDL прописал NOT NULL. Второе ваше отличие, если я получаю все максимальные зарплаты по отделам за один запрос, у вас на каждый отдел будет подзапрос. Hash Left Join (cost=38.58..89.43 rows=1 width=30) (actual time=0.161..21.505 rows=20 loops=1) Hash Cond: (employees.department_id = dep.department_id) Filter: (employees.salary = (SubPlan 1)) Rows Removed by Filter: 1980 -> Seq Scan on employees (cost=0.00..37.00 rows=2000 width=30) (actual time=0.007..0.087 rows=2000 loops=1) -> Hash (cost=22.70..22.70 rows=1270 width=4) (actual time=0.007..0.007 rows=20 loops=1) Buckets: 2048 Batches: 1 Memory Usage: 17kB -> Seq Scan on departments dep (cost=0.00..22.70 rows=1270 width=4) (actual time=0.004..0.005 rows=20 loops=1) SubPlan 1 -> Aggregate (cost=4.28..4.29 rows=1 width=8) (actual time=0.010..0.010 rows=1 loops=2000) -> Index Scan using d on employees employees_1 (cost=0.28..4.03 rows=100 width=8) (actual time=0.001..0.006 rows=100 loops=2000) Index Cond: (department_id = dep.department_id) Planning Time: 0.127 ms Execution Time: 21.528 ms
В результате 21.52 ms вместо 0.52 ms у очень похожего (тоже через агрегатную функцию max()) запроса у меня. Где-то в сорок раз медленнее.
Да, так работает pg_dump, только он не констрейнты отключает, а триггеры, которые их проверяют. Вообще все триггеры. Но вы это даже не заметите. А если даже вы это заметили, значит ваш сотрудник уже облажался.
Любое "удивите и продемонстрируете экспертизу" - ответ неправильный. Хуже ситуация получается, когда собеседуют двое: тех.специалист и эффективный менеджер. И когда их тех.специалист начинает отчаянно вешать лапшу на уши, вообще не понимая, как это работает (так было с проектом NRD), он ни за что не признается, что облажался и будет всяческий подтасовывать информацию в спорных вопросах, лишь бы его начальник не узнал, какое он дно. А эффективный менеджер оценивает только кто говорит более уверенным голосом. :) Если ты вешаешь лапшу на уши очень уверенно - получишь работу.
Там мысль еще глубже.На собеседовании предоставляют машину, подключенную к базе данных и как следствие имеющую на своём борту весь комплект документации от Микрософт SQL. Т.е. там собеседуемые работают в привычной среде с привычными инструментами и комфортно работают. У российских фирм до короновируса запросы нужно было писать на огрызке бумажки напрягая фантазию, а сейчас так тебе просто дают видео скриншота, который даже не скопипастишь, а ответ надо называть устно, проделывая всю работу в уме. Это настолько непривычно, что хочешь-не хочешь, а начинаешь стрессовать.
О, и не такие бывают. Как-тот раз, лет пять назад, проходил собеседование в одну контору, которая работала на правительство. Собеседовало меня два человека, тех.специалист и эффективный менеджер. У тех. специалиста претензий ко мне не было. Отшил эффективный менеджер, который сделал психологическое наблюдение, что я говорю не достаточно твёрдым и уверенным голосом.
Я уже отвечал на подобный коммент. https://habr.com/ru/articles/828728/comments/#comment_27040670 Подчеркну, мы же не рассматриваем реальную продовую базу данных с реальными задачами. Речь тут идёт о том, чем собеседование отличается от реальной работы.
Ну и? А вы с кем и о чем тут спорите? Мне кажется вы даже не поняли в чем тут суть и уже начали набивать коммент "со скоростью и позитивом свежей батарейки". Как вы и написали, начали писать ответ даже не разобравшись, а в чем было задание. :)
Смотрите. Все же задача собеседования выявить что специалист опытный и рукастый и он сможет решать поставленные перед ним задачи самостоятельно. Например начав с предварительного чтения документации, если он подзабыл эту тему, главное помнить, где что есть и куда смотреть. Например я за 25 лет ни разу не сталкивался с задачами, которые требовали бы оконных функций, по крайней мере, с момента их появления в PostgreSQL. И это не моя вина, просто специфика работодателя их не требовала, они больше ориентированы на каких-то финансистов. И за последние пять лет мне потребовался рекурсивный поиск только один раз (его тоже часто спрашивают на собеседовании), потому что веб программисты микросервисов не заморачиваются таблицами со ссылками на самих себя. Но это же не значит, что я не смогу справиться с работой, пролистав документацию в течении 15 минут, просто, чтобы освежить это в памяти.
У слову ваша 2 задача это явный bad design. Не стоит на собеседовании спрашивать как костылить вашу систему, вредно для репутации компании.
Ну на самом деле задача вывести строку содержащую максимальное или минимальное значение вполне себе реальная. Я смутно припоминаю, что что-то подобное приходилось решать по работе. Поэтому я интуитивно сразу написал вариант, который уже был в подкорке, ничего на ходу не придумывал. И в этом смысле эта задача, как и другие задачи от JitBit вполне себе полезная, как у них и написано, позволяет выявить людей у которых уже есть реальный опыт работы. Но вот когда собеседователь начинает требовать, чтобы я угадал его мысли и написал "единственный правильный и крутой" ответ, который на проверку оказывается худшим, это в первую очередь говорит, что у потенциального начальника нет никакого практического опыта работы.
Но все же в 10 раз тормознутее худших вариантов, я выше выкладывал статистику с индексом только по delivery_id. Но с точки зрения потенциального работодателя, я думаю вы произведёте впечатление, это единственный мне известный вариант без вложенных запросов.
Смотрите, в вашем варианте если в подразделении у двух сотрудников будет максимальная зарплата, то выведет только одного. Это уже неправильно.
Это просто копипаст с экрана. Весь код я привел.
И как вы собираетесь решать через rank() без подзапросов? Без подзапросов я только одно решение в комментах видел и оно было вовсе не через rank(). И да, с ужасной производительностью.
Ваш первый вариант, грубая ошибка. Допустим у одно сотрудника максимальная зарплата по отделу 200. А у другого такая же зарплата, но он в другом отделе и у него зарплата там не максимальная. У вас второго тоже выведет.
Второй вариант, там ошибка еще грубее. Вы выведите сотрудников с минимальной зарплатой в отделе.
Третий. Да, это первое, что приходит в голову и на проверку оказалось что лучший вариант. У меня такой же, только первый, под именем max.
Ох, distinct on() это не функция. Это во первых. Во-вторых ваш запрос не работает. В третьих при его написании вы допустили грубые ошибки. В четвертых вариант решения с помощью distinct, действительно, существуют, но они выдают только одного сотрудника с максимальной зарплатой, а в случае если в отделе несколько сотрудников с максимальной зарплатой, их надо вывести всех.
Если у двух разных сотрудников одинаковая зарплата, то это уже не дубликаты. Более того, если вы имели хоть какое-то отношение к математике и решали, например, уравнения, то ответом решения задачи будет все возможные решения. Написать только одно - грубая ошибка.
Похожее было, но у вас есть отличия. Во первых left join в employees left join departments не нужен, потому что я авторским произволом в DDL прописал NOT NULL. Второе ваше отличие, если я получаю все максимальные зарплаты по отделам за один запрос, у вас на каждый отдел будет подзапрос.
Hash Left Join (cost=38.58..89.43 rows=1 width=30) (actual time=0.161..21.505 rows=20 loops=1)
Hash Cond: (employees.department_id = dep.department_id)
Filter: (employees.salary = (SubPlan 1))
Rows Removed by Filter: 1980
-> Seq Scan on employees (cost=0.00..37.00 rows=2000 width=30) (actual time=0.007..0.087 rows=2000 loops=1)
-> Hash (cost=22.70..22.70 rows=1270 width=4) (actual time=0.007..0.007 rows=20 loops=1)
Buckets: 2048 Batches: 1 Memory Usage: 17kB
-> Seq Scan on departments dep (cost=0.00..22.70 rows=1270 width=4) (actual time=0.004..0.005 rows=20 loops=1)
SubPlan 1
-> Aggregate (cost=4.28..4.29 rows=1 width=8) (actual time=0.010..0.010 rows=1 loops=2000)
-> Index Scan using d on employees employees_1 (cost=0.28..4.03 rows=100 width=8) (actual time=0.001..0.006 rows=100 loops=2000)
Index Cond: (department_id = dep.department_id)
Planning Time: 0.127 ms
Execution Time: 21.528 ms
В результате 21.52 ms вместо 0.52 ms у очень похожего (тоже через агрегатную функцию max()) запроса у меня. Где-то в сорок раз медленнее.
Да, так работает pg_dump, только он не констрейнты отключает, а триггеры, которые их проверяют. Вообще все триггеры. Но вы это даже не заметите. А если даже вы это заметили, значит ваш сотрудник уже облажался.
Любое "удивите и продемонстрируете экспертизу" - ответ неправильный. Хуже ситуация получается, когда собеседуют двое: тех.специалист и эффективный менеджер. И когда их тех.специалист начинает отчаянно вешать лапшу на уши, вообще не понимая, как это работает (так было с проектом NRD), он ни за что не признается, что облажался и будет всяческий подтасовывать информацию в спорных вопросах, лишь бы его начальник не узнал, какое он дно. А эффективный менеджер оценивает только кто говорит более уверенным голосом. :) Если ты вешаешь лапшу на уши очень уверенно - получишь работу.
Там мысль еще глубже.На собеседовании предоставляют машину, подключенную к базе данных и как следствие имеющую на своём борту весь комплект документации от Микрософт SQL. Т.е. там собеседуемые работают в привычной среде с привычными инструментами и комфортно работают. У российских фирм до короновируса запросы нужно было писать на огрызке бумажки напрягая фантазию, а сейчас так тебе просто дают видео скриншота, который даже не скопипастишь, а ответ надо называть устно, проделывая всю работу в уме. Это настолько непривычно, что хочешь-не хочешь, а начинаешь стрессовать.
Ну, если у него вылетали ошибки целостности данных и именно поэтому он убрал внешние ключи, так значит целостность данных он уже не обеспечил.
О, и не такие бывают. Как-тот раз, лет пять назад, проходил собеседование в одну контору, которая работала на правительство. Собеседовало меня два человека, тех.специалист и эффективный менеджер. У тех. специалиста претензий ко мне не было. Отшил эффективный менеджер, который сделал психологическое наблюдение, что я говорю не достаточно твёрдым и уверенным голосом.
Я уже отвечал на подобный коммент.
https://habr.com/ru/articles/828728/comments/#comment_27040670
Подчеркну, мы же не рассматриваем реальную продовую базу данных с реальными задачами. Речь тут идёт о том, чем собеседование отличается от реальной работы.
Ну и? А вы с кем и о чем тут спорите? Мне кажется вы даже не поняли в чем тут суть и уже начали набивать коммент "со скоростью и позитивом свежей батарейки". Как вы и написали, начали писать ответ даже не разобравшись, а в чем было задание. :)
Смотрите. Все же задача собеседования выявить что специалист опытный и рукастый и он сможет решать поставленные перед ним задачи самостоятельно. Например начав с предварительного чтения документации, если он подзабыл эту тему, главное помнить, где что есть и куда смотреть. Например я за 25 лет ни разу не сталкивался с задачами, которые требовали бы оконных функций, по крайней мере, с момента их появления в PostgreSQL. И это не моя вина, просто специфика работодателя их не требовала, они больше ориентированы на каких-то финансистов. И за последние пять лет мне потребовался рекурсивный поиск только один раз (его тоже часто спрашивают на собеседовании), потому что веб программисты микросервисов не заморачиваются таблицами со ссылками на самих себя. Но это же не значит, что я не смогу справиться с работой, пролистав документацию в течении 15 минут, просто, чтобы освежить это в памяти.
У слову ваша 2 задача это явный bad design. Не стоит на собеседовании спрашивать как костылить вашу систему, вредно для репутации компании.
Весь код я выложил. Если вам и правда интересно, вы перепроверите на больших данных. Главное не уйдите в работу с винчестером.
Вполне разумный подход. Хм, а вам программист PostgreSQL не нужен? Ответ на эту задачку я уже знаю. :)
Ну на самом деле задача вывести строку содержащую максимальное или минимальное значение вполне себе реальная. Я смутно припоминаю, что что-то подобное приходилось решать по работе. Поэтому я интуитивно сразу написал вариант, который уже был в подкорке, ничего на ходу не придумывал. И в этом смысле эта задача, как и другие задачи от JitBit вполне себе полезная, как у них и написано, позволяет выявить людей у которых уже есть реальный опыт работы.
Но вот когда собеседователь начинает требовать, чтобы я угадал его мысли и написал "единственный правильный и крутой" ответ, который на проверку оказывается худшим, это в первую очередь говорит, что у потенциального начальника нет никакого практического опыта работы.
Т.е. надо зубрить самые бессмысленные решения широко распространённых в Интернете задач? Ну да, победная стратегия.
Ну да, тут вся статья про неэффективные, но прикольные способы. :) Поставил респект за изобретательность. QUERY PLAN
Hash Left Join (cost=62.00..2854.00 rows=1 width=30) (actual time=0.337..8.945 rows=20 loops=1)
Hash Cond: (e1.department_id = e2.department_id)
Join Filter: (e2.salary > e1.salary)
Rows Removed by Join Filter: 101000
Filter: (e2.employee_id IS NULL)
Rows Removed by Filter: 99000
-> Seq Scan on employees e1 (cost=0.00..37.00 rows=2000 width=34) (actual time=0.007..0.078 rows=2000 loops=1)
-> Hash (cost=37.00..37.00 rows=2000 width=16) (actual time=0.273..0.273 rows=2000 loops=1)
Buckets: 2048 Batches: 1 Memory Usage: 110kB
-> Seq Scan on employees e2 (cost=0.00..37.00 rows=2000 width=16) (actual time=0.002..0.125 rows=2000 loops=1)
Planning Time: 0.088 ms
Execution Time: 8.961 ms
(12 строк)
Но все же в 10 раз тормознутее худших вариантов, я выше выкладывал статистику с индексом только по delivery_id. Но с точки зрения потенциального работодателя, я думаю вы произведёте впечатление, это единственный мне известный вариант без вложенных запросов.