Comments 22
SQL имеет весьма низкий порог вхождения и подкупает простотой, отсюда такие "перлы". А какой-нибудь Oracle за счёт мощного оптимизатора ещё и "прощает" подобное. До поры до времени.
Сам ни раз писал видел запросы, от которых волосы на спине начинают шевелиться.
А какой-нибудь Oracle за счёт мощного оптимизатора ещё и "прощает" подобное.
Сейчас все оптимизаторы примерно одинаковы, и вряд ли современный SQL сервер вообще уступает Ораклу, возможно даже наоборот. Оракл это тоже набор костылей - не знаю как сейчас а в версии 9 по моему, сделать запрос SELECT TOP 10 с условиями и сортировкой приходилось через одно место - деталей уже не помню но если надо могу поднять.
Это вы легаси проектов живущих на каком-нибудь mysql 5.5 еще не видели.
Их и мигрировать на более новый mysql сложно, и оптимизатора запросов там по сути нет. Вот и приходится поднимать пыльные архивы so и вспоминать как же построитель запросов работал в те годы. А работал он иногда очень неочевидным образом.
Это вы легаси проектов живущих на каком-нибудь mysql 5.5 еще не видели.
Видел и работал даже с версией и 3 и 4. Но вообще MySQL не любил никогда. В версии 3 кажется, некторые типы таблиц (ISAM кажется) даже не умели ACID нормально, а InnoDB были экспериментальными и дико тормозили на чтение. После 4 версии к счастью не сталкивался с этой СУБД более.
вряд ли современный SQL сервер вообще уступает Ораклу
Насколько я в курсе, MS SQL никогда не ругали за плохой оптимизатор, как раз наоборот, хвалили, как и Oracle.
Удивляться люди начинают, когда тащат "ораклячие" запросы например на PostgreSQL - на малых данных подвоха не заметно, зато на проде все внезапно встаёт колом. Хотя на Oracle работало. Такое видел, хотя Pg активно развивается, может, уже и такого не бывает.
сделать запрос SELECT TOP 10
В Oracle, если не изменяет память, версии так с 12-ой (которая 2013 года), добавили limit и offset, так что можно обойтись без извращений с rownum. 9-ка это что-то совсем уж старое.
В Oracle, если не изменяет память, версии так с 12-ой (которая 2013 года), добавили limit и offset, так что можно обойтись без извращений с rownum. 9-ка это что-то совсем уж старое.
Да все верно. А максимальная версия с которой я работал - была как раз 10-ка и там приходилось делать такой изврат.
Удивляться люди начинают, когда тащат "ораклячие" запросы например на PostgreSQL
Тут в общем то не зависит ничего от того куда чего тащат - тут важно фундаментальное понимание того как все работает, а не конкретный диалект СУБД. Если человек не понимает что такое индекс, что такое FULL SCAN, не умеет делать и читать планы построения запросов - везде будет плохо
SQL имеет весьма низкий порог вхождения
Смотря с какой стороны входить. Если со стороны «настольных» файловых БД (Clipper, FoxPro, Paradox и им подобных), да на Delphi, то MS SQL не прощал принятый в них стиль работы: «встать» на какую-нибудь запись, вывести ее на интерфейс и не спеша менять: MS SQL (точнее, его драйвер в BDE) вешал на эту запись блокировку, и у всех других, кто на нее натыкался, программа показывала песочные часы.
А вот Interbase, который в комплекте с Delpi шел, такое прощал — потому что поддерживал версионность, наверное в те времена — единственный: и в MS SQL некая поддержка версионности появилась сильно позже, и PostgreSQL тогда в версионность не умел…
Низкий порог в SQL эти иллюзия. Недавно разговаривал за жизнь с преподавателем курсов по DBA/SQL PostgreSQL - все кто приходил к нему "со знаниями SQL" очень быстро понимали, что весь объем их знаний рассказывается в первые три часа до обеда и не стоит ничего.
Не надо путать «порог вхождения» и «эффект Даннинга-Крюгера» :)
Низкий порог в SQL эти иллюзия
Порог вхождения != знание языка в целом. Легкие запросы научиться писать легко, языковых конструкций и ключевых слов не много, синтаксис тривиальный. Сложности начинаются много позже.
с преподавателем курсов по DBA/SQL PostgreSQL
Вашего преподавателя зовут Том Кайт Майкл Стоунбрейкер? Отдает каким-то бахвальством, честное слово.
Все зависит от того, какие таблицы образуют базу данных
'$123.45' - это действительно удобно!
Сам так часто делаю, если чмсло 123,45 является "финишным" :)
Попутно дата-время хранилось не в datetime, а в двух колонках - одна дата в datetime с уcеченным временем, а время по моему в виде текста
Так а что в этом плохого? Т.е. ваш пример(найти все документы после какой-то даты и времени) наверное будет не очень оптимален, но как правило документы ищут просто по конкретной дате. В этом случае хранение даты будет как раз более оптимальным.
Хранение номеров документов в char является с лидирующими нулями, это как бы тоже типовое и оптимальное решение(т.е. номер накладной у вас будет что-то вроде Накл0001), нужно как раз для сортировки
Жаловаться на "утечки памяти SQL", что он "занимает всю память" и перезапускать его все время
В те времена MS SQL имел багу в Notification Service, время от времени не завершалась какая-то транзакция от этого сервиса. В результате auto shrink не работал, база росла на диске, а процесс сервиса в памяти. Периодическое прибивание сервиса, но не самого SQL, спасало ситуацию.
Насчет первой истории. Никогда не понимал в чем смысл тестовые записи пытатся делать прикольно-осмысленными. Пусть один клиент будет клиент1 а второй клиент2 и у них будут заказы заказ1 заказ2. по числам проще орьентироватся чем по записи что у свиньи должно быть хрюк и гав а у котяры мяу и хрюк
Проверять схему базы и отказываться запускаться - не такая уж и плохая идея. Только все же явным списком, а не чексуммой.
Сказки старого DBA