A>Знаешь, если человек заявляет, что он 5 лет писал квик сорт — то на собеседовании он его должен тоже написать.
A>Так что ты передёргиваешь
Нее — ты не внимательно читаешь. Или я — лень ткнуть мышью и проверить. Красавчег пишет что он пять лет писал этот ваш SQl. Про джоинты он ничего не писал. Я на С++ ваяю побольше чем он на этомвашем сикуеле, но ночью квиксорт таки не напишу. В общем, днем тоже не напишу. И долгим зимним вечером — не напишу. И на работе — пару раз использовал что то стандартное для сортировки. И вот живу же как то.
B>Красавчег пишет что он пять лет писал этот ваш SQl. Про джоинты он ничего не писал.
Ну вот тут и поспорили — я утверждал, что 5ний опыт на СКЛ без джойнов — это простейшие КРУД операции, на знание СКЛ не тянет.
Аналогия — 5 лет на С++ не используя классов, структур, заголовочных файлов и вся программа в одном файле — да так тоже можно писать, но называть себя человеком с хорошим знанием С++ и обижаться, что кто-то поставит это под сомнение — ну самому не смешно?
B>>Красавчег пишет что он пять лет писал этот ваш SQl. Про джоинты он ничего не писал. A>Ну вот тут и поспорили — я утверждал, что 5ний опыт на СКЛ без джойнов — это простейшие КРУД операции, на знание СКЛ не тянет. A>Аналогия — 5 лет на С++ не используя классов, структур, заголовочных файлов и вся программа в одном файле — да так тоже можно писать, но называть себя человеком с хорошим знанием С++ и обижаться, что кто-то поставит это под сомнение — ну самому не смешно?
Во-во! И ведь покажите мне задачу которую на С++ нельзя решить без этих ваших классов и наследования.
Я вот себя спецом по СКЛ (и по базам вообще) даже рядом не считаю, но и то понятно что JOIN (ну и понимания в чем разница между разными видами джойнов) — это базовое знание.
Здравствуйте, avpavlov, Вы писали:
A>Ну чего я один всё примеры пишу и пишу. Может ты чего покажешь? Сложный СКЛ и простой аналог на каком-нибудь языке программирования?
select
breakdown.*
,count(*)
from
(
select gender.code gender, ethnic.code ethnic from gender,ethnic
) breakdown
left join people on people.gender = breakdown.gender and people.ethnic = breakdown.ethnic
group by
breakdown.gender
,breakdown.ethnic
Вы всегда пользователю столько мусорной информации выводите? Представьте, решил начальник построить такой отчетик для отдела из 30 человек. Национальностей в России более 160, так уж и быть мировые брать не будем, полов слаба богу всего 2. И вот для этих 30 человек выводится отчет на десяток страниц с тремя сотнями с гаком строк, из которых процентов 95 это мусор. Как думаете сильно доволен будет начальник таким отчетом? И это нам еще повезло, что отчет строился по связке пол + национальность, а ежели бы начальник решил построить отчет для национальности + ВУЗ, то боюсь в офисе бумаги бы не хватило, чтобы его напечатать.
Если же отчет строить не для галочки, а для полезной деятельности, то весь мусор из него придется выкинуть и запрос сведется к тривиальному:
select gender, ethnic, count(*) from people group by gender, ethnic
U>Вы всегда пользователю столько мусорной информации выводите?
Нет, только нужную
U>Представьте, решил начальник построить такой отчетик для отдела из 30 человек.
Предстfвьте такой отчётик нужен для импорта куда-то, где требуются все строки, или для отображения на графике, где опять таки требуются все строки.
U>Национальностей в России более 160, так уж и быть мировые брать не будем, полов слаба богу всего 2.
В Англии многие системы учёта оперируют "национальностями" на верхнем уровне — White, Asian, Black, Mixed
Так что там такие отчёты — реальность, собственно это и был реальный пример.
Так тоже можно, если пользователь согласен, что нулевые строки не нужны.
Вообщем, ты проблему незнания СКЛ свёл к тому, что тебе не нравится пример запроса. Если честно, мне уже надоел этот спор. Добавить мне к тому что я сказал нечего. Примеров как можно сложный СКЛ сделать простым, перенеся в бизнес-слой, я скорее всего от тебя не дождусь.
Так что я сливаюсь из топика (если будут примеры — вернусь!).
Здравствуйте, avpavlov, Вы писали:
>>Но зато эти запросы будут >> 1) легко читаться >> 2) легко отлаживаться. Даже не так. ЛЕГКО ОТЛАЖИВАТЬСЯ
A>По обоим пунктам СКЛ выиграл.
Ты не так давно доказывал, что с sql может работать далеко не каждый даже ведущий программист. С кодом, который я привел, без всяких проблем работает любой вчерашний студент не шибко чуждый программированию.
B>>Красавчег пишет что он пять лет писал этот ваш SQl. Про джоинты он ничего не писал.
A>Ну вот тут и поспорили — я утверждал, что 5ний опыт на СКЛ без джойнов — это простейшие КРУД операции, на знание СКЛ не тянет.
A>Аналогия — 5 лет на С++ не используя классов, структур, заголовочных файлов и вся программа в одном файле — да так тоже можно писать, но называть себя человеком с хорошим знанием С++ и обижаться, что кто-то поставит это под сомнение — ну самому не смешно?
Осталось только узнать, у кого же выше зарплата. Потому что среди всех разговоров про классы и джойны ни разу не вспомнили про сумму денег. Хотя собеседования в основном про суммы денег.
U>Ты не так давно доказывал, что с sql может работать далеко не каждый даже ведущий программист.
Вот именно поэтому мы ищем тех кто может.
U>С кодом, который я привел, без всяких проблем работает любой вчерашний студент не шибко чуждый программированию.
Если честно, тот запрос что я привёл я считаю простейшим. Бывают запросы из многих десятков операторов на десятки килобайт текста — это если речь идёт об импорте данных из какого нибудь некачественного источника, поэтому требуется очистка, обработка, сопоставление — если переписать на С++, у вчерашнего студента мозг лопнет
U> RowLink people = people.FindRow(PeopleType.ByGenderAndEthnic, genderCode, ethnicCode);
Я вот ещё сразу не вчитывался, сейчас только внимательно посмотрел. Прокомментируй этот код, пожалуйста. Это на каждый вариант поиска придётся иметь ByXXX? А если условие хоть чуть более сложное чего делать? Например, поиск по OR(или).
Ещё жизненный случай — есть студент, у него указана планируемая дата начала и окончания учёбного курса. А есть ещё поле когда он реально начал. Когда это поле пусто, то используется планируемая дата.
Таким образом поиск получается что-то вроде where coalesce(actualStartDate,plannedStartDate) = ...
U> RowLink people = people.FindRow(PeopleType.ByGenderAndEthnic, genderCode, ethnicCode);
и в догонку — допусти есть поле spouseId (супруг) которое ссылается на эту же таблицу. Оно может быть НУЛЛ (не женат/не замужем). Как будет выглядеть запрос "получить список имён людей и имён их супругов, если супруг есть"?
Здравствуйте, avpavlov, Вы писали:
A>Если честно, тот запрос что я привёл я считаю простейшим. Бывают запросы из многих десятков операторов на десятки килобайт текста — это если речь идёт об импорте данных из какого нибудь некачественного источника, поэтому требуется очистка, обработка, сопоставление — если переписать на С++, у вчерашнего студента мозг лопнет
Писать очистку, обработку и сопоставление на sql это извращение, поэтому и получается сверх сложно, для этого нормальные языки есть, при использовании которых сложность резко снижается.
Проблема функционального подхода в общем и sql в частности в том, что на нем преобразование надо сразу записывать целиком, соответственно даже на средних задачах преобразование уже в голову влазит плохо. Достоинство императивного подхода, что мы можем зафиксировать состояние в любой удобный для нас момент, что позволяет разбить сложную задачу на небольшие и несложные части. Поэтому императивный подход для решения сложных задач подходит много лучше функционального.
Это даже по твоей задаче видно — при том что логически она выеденного яйца не стоит, sql уже получился довольно сложный. Императивное же решение достаточно объемно, но все преобразования примитивны, поэтому вполне понятны даже студенту.
G>Если бы это было правдой, то не существовало бы вакансии С++ программист, Java программист итд. Искали бы просто абстрактных программистов. Одна вхождение в новую технологию занимает ненулевое время.
Здравствуйте, Undying, Вы писали:
U>И что? Простота кода и лаконичность кода это не просто разные, а зачастую прямо противоположные вещи.
U> так еще и весь рекордсет будет поднят в память?
U>В память поднята одна строчка таблицы на одну строчку отчета. Бумага в офисе закончится значительно раньше, чем память.
Если у нескольких сотен пользователей вдруг возникает непреодолимое желание разглядывать отчеты на пару миллионов записей (нафига? но ведь хотят!) и вертеть их и так и эдак, причем каждый отчет специфичен для пользователя и так по двадцать отчетов одновременно, то опыт показывает, что при разгильдяйском отношении к памяти, память заканчивается раньше.
U>В память поднята одна строчка таблицы на одну строчку отчета. Бумага в офисе закончится значительно раньше, чем память.
Оно еще и по сети будет передаваться, если СУБД на другом сервере. Т.е. на самом деле этот код пытается выполнять задачу СУБД
вместо нее, едва ли эффективно, при этом.
А какие преимущества у этого кода, кроме того, что он понятен лично вам? Мне вот SQL понятен сразу, а приведенный код требует
вникания в каждую строчку (которых, повторюсь, еще и больше).
Здравствуйте, SE, Вы писали:
SE>Если у нескольких сотен пользователей вдруг возникает непреодолимое желание разглядывать отчеты на пару миллионов записей (нафига? но ведь хотят!) и вертеть их и так и эдак, причем каждый отчет специфичен для пользователя и так по двадцать отчетов одновременно, то опыт показывает, что при разгильдяйском отношении к памяти, память заканчивается раньше.
И чем тут поможет последовательная загрузка строк таблицы? Если отчет хранит данные, то он все равно сожрет немерянно памяти. Тут надо делать честный виртуальный режим, который будет подгружать только то, что видит пользователь на экране.