Здравствуйте, avpavlov, Вы писали:
A>Я тебе наверное скажу новость, но SQL не прощает такого подхода. Если ты не понимаешь как работает запрос, то всё закончится тупым подбором каких-то магических операторов, которые на текущей тестовой базе дадут правильный ответ. И неправильный на продакшн.
За пять лет использования sql у меня не было ни одной ошибки ни с возвращением не того результата, который ожидался, ни с производительностью. И достигается это как раз за счет использования сложных запросов только в крайних случаях, когда без них действительно нельзя обойтись. А наворачивать сложность в надежде, что ты ее правильно понимаешь это путь гарантированных ошибок.
U>>3) В вопросах имеется куча экзотики, мало применимая или и вовсе бесполезная на практике. U>>select * from t1, t2
A>ОФИГЕТЬ
Так зачем вы используете этот код в реальном коде? Чтобы на двух жалких табличках по тысяче записей получить приятный сюрприз в виде OutOfMemory?
A>Если ты не знаешь джойны, то ты не сможешь решить задачу, ни мою ни свою.
Так какие реальные задачи нельзя решить не используя join?
U>За пять лет использования sql у меня не было ни одной ошибки ни с возвращением не того результата, который ожидался, ни с производительностью. И достигается это как раз за счет использования сложных запросов только в крайних случаях, когда без них действительно нельзя обойтись. А наворачивать сложность в надежде, что ты ее правильно понимаешь это путь гарантированных ошибок.
... U>Так зачем вы используете этот код в реальном коде? Чтобы на двух жалких табличках по тысяче записей получить приятный сюрприз в виде OutOfMemory?
... U>Так какие реальные задачи нельзя решить не используя join?
Собственно из этих твоих ответов становится очевидно, что "5 лет СКЛ" — это 5 лет использования простейшего КРУД с выносом всей логики в приложение. Так тоже можно, и многие так и работают. Просто не надо обижаться, когда твой 5-летний опыт сочтут ничтожным и неподходящим для конкретной компании.
A>select
A> breakdown.*
A> ,count(*)
A>from
A> (
A> select gender.code gender, ethnic.code ethnic from gender,ethnic
A> ) breakdown
A> left join people on people.gender = breakdown.gender and people.ethnic = breakdown.ethnic
A>group by
A> breakdown.gender
A> ,breakdown.ethnic
A>
Припоминаю, писал такую муть на заре своей программистской жизни. В чем проблема такого кода? В том, что этот код невозможно повторно использовать. Если нужно почти тоже самое, но чуть-чуть по другому, приходиться писать почти тоже самое еще раз. А невозможность повторного использования кода и необходимость постоянного дублирования кода с внесением небольших изменений является одним из главных признаков говнокода. К счастью я осознал это достаточно быстро и от такого подхода отказался.
U>Если нужно почти тоже самое, но чуть-чуть по другому, приходиться писать почти тоже самое еще раз.
Или использовать генерацию СКЛ или прогонять СКЛ через движок разметки, чтобы внести изменения перед исполнением, например через velocity.
U>К счастью я осознал это достаточно быстро и от такого подхода отказался.
К счастью я осознал быстро, что любые догматические взгляды мешают в жизни вообще и в программировании в частности.
Например, повторное использование кода — это не священная корова, ради которой нужно пожертвовать всем.
Проиллюстрирую: есть задача получения списков людей — обычных операторов и администраторов.
Человек, слепо следующий догмам скажет — а вдруг потом понадобится получить какой-то 3й список? А вдруг условий будет больше? И ещё много других "вдруг". И навернёт здесь такую жопу, что волосы дыбом будут вставать. Но зато ни строчки не будет продублировано, ага.
Человек, который каждую методику рассматривает как подоходящий или неподходящий инструмент, и поэтому свободен от предрассудков просто напишет 2 запроса (и ему будет плевать что 70% символов продублированы)
select * from Users where isOperator=1
select * from Users where isAdministrator=1
Но зато эти запросы будут
1) легко читаться
2) легко отлаживаться. Даже не так. ЛЕГКО ОТЛАЖИВАТЬСЯ
Короче, избавление от дублирования кода должно иметь цель ОБЛЕГЧЕНИЯ СОПРОВОЖДЕНИЯ КОДА. Когда вместо этой цели используется избавление ради избавления, и в жертву приносится всё остальное — вот это и есть проблема, которую не каждый способен осознать.
Здравствуйте, avpavlov, Вы писали:
U>>Если нужно почти тоже самое, но чуть-чуть по другому, приходиться писать почти тоже самое еще раз. A>Или использовать генерацию СКЛ или прогонять СКЛ через движок разметки, чтобы внести изменения перед исполнением, например через velocity.
Это еще больший кошмар.
A>Человек, который каждую методику рассматривает как подоходящий или неподходящий инструмент, и поэтому свободен от предрассудков просто напишет 2 запроса (и ему будет плевать что 70% символов продублированы)
A>select * from Users where isOperator=1 A>select * from Users where isAdministrator=1
Я бы примерно так и сделал. Но зачем для написания подобных запросов мега знание sql'а?
A>Короче, избавление от дублирования кода должно иметь цель ОБЛЕГЧЕНИЯ СОПРОВОЖДЕНИЯ КОДА. Когда вместо этой цели используется избавление ради избавления, и в жертву приносится всё остальное — вот это и есть проблема, которую не каждый способен осознать.
Сложные sql запросы и плохо читаются, и плохо отлаживаются. Соответственно использовать их надо только тогда, когда других вариантов решения задачи нет. А такое бывает редко.
Ты судишь не разу не воспользовавшись этим подходом, и скорее всего даже ни разу не видав, как оно выглядит.
A>>Человек, который каждую методику рассматривает как подоходящий или неподходящий инструмент, и поэтому свободен от предрассудков просто напишет 2 запроса (и ему будет плевать что 70% символов продублированы)
A>>select * from Users where isOperator=1 A>>select * from Users where isAdministrator=1
U>Я бы примерно так и сделал. Но зачем для написания подобных запросов мега знание sql'а?
Это же иллюстрация была. Для этих конечно не надо. А вот если сюда роли приджойнить, то надо уже понимать разницу между left и inner чтобы использовать тот или другой в зависимости от логики приложения.
И обращаю твоё внимание: джойны — это не мега знание, это базовое знание.
U>Сложные sql запросы и плохо читаются, и плохо отлаживаются. Соответственно использовать их надо только тогда, когда других вариантов решения задачи нет. А такое бывает редко.
Сложный СКЛ запрос воспроизведённый в приложении будет читаться и отлаживаться ещё хуже. Так что не надо передёргивать.
Здравствуйте, avpavlov, Вы писали:
H>>Приведите какой-нибудь примерчик жизненный для такого запроса, для чего H>>он у вас используется. А то с остальным в целом согласен, а вот тут не H>>могу сообразить для чего бы такой запрос мог понадобиться. Хотя с SQL H>>лет уж 10 минимум опыта, не вспоминается похожего.
A>ну, например, есть люди. У них 2 признака — пол и национальность. Построить отчёт с группировкой по полу и национальности, включая нулевые значения.
A>
A>select
A> breakdown.*
A> ,count(*)
A>from
A> (
A> select gender.code gender, ethnic.code ethnic from gender,ethnic
A> ) breakdown
A> left join people on people.gender = breakdown.gender and people.ethnic = breakdown.ethnic
A>group by
A> breakdown.gender
A> ,breakdown.ethnic
A>
Может я что-то не понимаю, но нормальный человек напишет
select g.code as gender, e.code as ethnic, count(*)
from people p
right join gender g on g.code=p.gender
right join ethnic e on e.code=p.ethnic
group by g.code, e.code
Здравствуйте, avpavlov, Вы писали:
G>>Может я что-то не понимаю, но нормальный человек напишет
A>Выпады про нормальность при неумении читать постановку задачи смотрятся забавно
A>ну, например, есть люди. У них 2 признака — пол и национальность. Построить отчёт с группировкой по полу и национальности, включая нулевые значения.
select g.code as gender, e.code as ethnic, count(p.id)
from
(
select 1 id, 'M' gender, 'W' ethnic
)p
right join (select 'M' code union select 'F' code) g on g.code=p.gender
right join (select 'W' code union select 'B' code) e on e.code=p.ethnic
group by g.code, e.code
--------------------------------
gender ethnic (No column name)
NULL B 0
M W 1
--------------------------------select
breakdown.*
,count(people.id)
from
(
select gender.code gender, ethnic.code ethnic from (select 'M' code union select 'F' code) gender, (select 'W' code union select 'B' code) ethnic
) breakdown
left join (select 1 id, 'M' gender, 'W' ethnic) people on people.gender = breakdown.gender and people.ethnic = breakdown.ethnic
group by
breakdown.gender
,breakdown.ethnic
--------------------------------
gender ethnic (No column name)
F B 0
M B 0
F W 0
M W 1
--------------------------------
Здравствуйте, avpavlov, Вы писали:
U>>Так какие реальные задачи нельзя решить не используя join?
A> твой 5-летний опыт сочтут ничтожным и неподходящим для конкретной компании.
Не, я понимаю, круче — только яйца и горы (и то не все, а только эверест). Но таки нельзя ли ответить на вопрос? А то сей холивар сильно напоминает сходку сторонников написания квиксорта на бумажке во время интервью.
Здравствуйте, avpavlov, Вы писали:
U>>>>Так какие реальные задачи нельзя решить не используя join? A>Сходу не приходят в голову. Путём большого огромного кол-ва подзапросов наверное можно съэмулировать любой джойн. A>Правда выходит, что джойны упрекают за сложность и тут же готовы раздуть запросы многократно, чтобы от них отказаться?
Не правда Основная идея — не городить чего либо сложнее необходимого, что б работало. Это частный случай выбора между шашечками и ехать. По моему скромному опыту на интервью часто гоняются за шашечками в ущербу ехать, а потом удивляются, когда на работе шашечки, но проект не едет. Вообще ситауция, когда в конторе все гении, а работать некому — весьма печальная.
Здравствуйте, avpavlov, Вы писали:
A>Сложный СКЛ запрос воспроизведённый в приложении будет читаться и отлаживаться ещё хуже. Так что не надо передёргивать.
Проще он будет читаться, причем намного. Так как объединение разнородных сущностей через словари намного проще и понятнее результата заталкивания разнородных сущностей в одну таблицу.
U>>Это еще больший кошмар. A>Ты судишь не разу не воспользовавшись этим подходом, и скорее всего даже ни разу не видав, как оно выглядит.
Не видел. Но знаю какова цена дополнительных абстрактных слоев. Эта цена очень велика.
B>Не правда Основная идея — не городить чего либо сложнее необходимого, что б работало. Это частный случай выбора между шашечками и ехать. По моему скромному опыту на интервью часто гоняются за шашечками в ущербу ехать, а потом удивляются, когда на работе шашечки, но проект не едет. Вообще ситауция, когда в конторе все гении, а работать некому — весьма печальная.
Ну и от тебя тогда пример, когда с джойном это "городить лишнего", а без джойна — божья роса.
U>>>>Так какие реальные задачи нельзя решить не используя join? A>Ну чего я один всё примеры пишу и пишу. Может ты чего покажешь? Сложный СКЛ и простой аналог на каком-нибудь языке программирования?
B>>Не правда Основная идея — не городить чего либо сложнее необходимого, что б работало. Это частный случай выбора между шашечками и ехать. По моему скромному опыту на интервью часто гоняются за шашечками в ущербу ехать, а потом удивляются, когда на работе шашечки, но проект не едет. Вообще ситауция, когда в конторе все гении, а работать некому — весьма печальная.
A>Ну и от тебя тогда пример, когда с джойном это "городить лишнего", а без джойна — божья роса.
Про джойн — не скажу. Про С/С++ — писание квик сорта на бумажке и рассуждения о важности написать оный будучи разбуженным ночью с пятницы на субботу, после пьянки, и, потом на работе пользование стандартного квиксорта (один раз за два года).
B>Про джойн — не скажу. Про С/С++ — писание квик сорта на бумажке и рассуждения о важности написать оный будучи разбуженным ночью с пятницы на субботу, после пьянки, и, потом на работе пользование стандартного квиксорта (один раз за два года).
Знаешь, если человек заявляет, что он 5 лет писал квик сорт — то на собеседовании он его должен тоже написать.
Основная идея — не городить чего либо сложнее необходимого, что б работало. Это частный случай выбора между шашечками и ехать. По моему скромному опыту на интервью часто гоняются за шашечками в ущербу ехать, а потом удивляются, когда на работе шашечки, но проект не едет. Вообще ситауция, когда в конторе все гении, а работать некому — весьма печальная.
