про умных бекендеров не умеющих MySQL

Шут знает откуда это повелось. Почему-то БД, которая по-хорошему должна бы быть фундаментом здания, от характеристик и особенностей которого зависит всё остальное строительство - считается какой-то необязательной фигней, которую можно прилепить позже и сбоку, или вообще заменить полностью. Вполне приличные дядьки абсолютно искренне так считают.

Повелось это от веб-я-тоже-программист.

с какого уровня не умение?

sql это буквально ассемблер

почему тогда не stored на любом для данной рсубд допустимом языке?

если скорость то всяко привязка к специфике субд

то что люди до сих пор отрпавляють с клиентов на сервер sql-запросы - и не интерактивности а именно ручной код вшитый в сырцы ( иногда с раскрытием параметров)

и почни ни когда недёргают сторед или методы объекты на стороне базы - вот это вот впечатляет

и при этом считают письмо на асме на клиенте отсталыми технологиями

забавно это

SQL это не ассемблер. Это скорее хаскель чем ассемблер, язык супервысокого уровня придуманный специально для операций над множествами, за ним стоит вся мощь реляционной алгебры. За счет этого БД могут в оптимизации, одинаковые для совершенно разных задач.

А хранимки это как раз попытка притащить в операции с бд императивщину, тот самый ассемблер.

ХОРОШИЙ вопрос

имхо Программист Навигатор Бахмана содержит(частично) понимание того почему БД нечто инородное обычно

более содержательный ответ в чём причины вами замеченной ситуации в

Вирта Никалуаса Структуры Данных + Алгоритмы == Программы

и знаменитой цитаты

покажите ваши алгоритмы и я не пойму;покажите структуры данных и я пойму

(как то похоже)

люди настолько «не затрудняются» с навыками в структуры данных что им потребовалась анимализация через ООП - что всё равно не дало ожидаемого результата /

прогресс в росте вычислительных(и обьёмах хранения) настолко выше возможностей современной подготовки что «хоть-както» достаточно

то что там алгебра множеств не отменяет факта

что язык реляций это язык достаточно далёкий от проблемной области прикладного проггера

ОРМ обычно тоже кривизна ибо течка абстракций

нет хранимки это инкапсуляция в «модуле» деталей реализации

сама хранимка вполне может быть чистой функией - по факту вьюшки изобрели ибо эволюция субд тот ещё попкорн

sql это реляционный ассемблер ( возможно прям цитата из Дэйты)

Сто пудов лид переадресует тикет кому-то ещё, ибо сейчас такие лиды пошли...

Поэтому лучше сразу ДБА писать.

Просто с ним не умеют работать, и не понимают, потому что нигде этому не учат, а учат паскалю, и в результате все что без циклов и присваиваний считают недоязычками. А труд Дейта самостоятельно не каждый способен не то что осились, а даже дочитать до половины.

А так SQL, максимально возможная нормализация и отказ от хранимок, особенно от тех которые мутируют данные, очень сильно облегчают работу программиста и поддержку БД. Хранимка - значит оптимизатор БД не может составить нормальный план запроса. Если в хранимке или триггере так или иначе проверятся целостность данных - значит можно ее нарушить другим запросом или отключить триггер и база останется неконсистентной.

От денормализации обычно больше проблем чем пользы. Вон выше по треду пример с агрегатами и группировкой, который перестанет работать как только понадобятся похожие данные, но в разрезе «в выходные, праздничные и приравненные к ним дни», или «в первый понедельник месяца в рабочее время с 9:30 до 18:00 с учетом часового пояса». И окажется что таблички и двух триггеров хватало на оптимизацию одного конкретного запроса, а на самом деле нужна была timeseries бд. Но т.к. изначально пошли по неверному пути, так и дальше будут руками писать оптмизацию для каждого отдельного запроса, забыв уже с чего все начиналось, в 90% это будет так.

Аллах смилостивился над страданими своих сыновей, и руками своих ученых пророков послал им реляционную теорию и Б-жественный SQL, чтобы несчастные утерли кровавые слезы и могли наконец ложиться спать спокойно, зная что самое сложное за них уже сделано. Но неразумные это не оценили, и как в старой пасте не видя двери стали биться головой о стену и выпиливать там люки. Отказываться от Схемы, Реляций и замещать это бесмысленным NoSql и писать циклы. Теперь Аллах руками своих пророков шлет им всякое говно вроде Go, ибо сказано в Писании - не мечите бисера пред свиньями.

Бахман vs Кодд очень пользительно

дисскусия так то они кореши

а и не нужно (учить)

ибо (без шуток)

нечто вообще за рамками(осо знания) имяряка, имяряк знает что нечто существует(т.е 1 и допуская не существование(какого цвета не существующий дракон) 0), количества возможны - много

обычный счёт(то что в началке) это резултат многих тысяч лет общественного развития

не столько сам счёт - сколько наличие задач требующих этот навык массово

поэтому закономерно что бд(практика(массовая) их использование а не иная) такие какие есть ( «а что у верблюда не кривое» такс сказать)

Хранимка - значит оптимизатор БД не может составить нормальный план запроса.

Упс. Это где такое? Есть пример?

Или вы имеете в виду хранимки на курсорах и прочих форах?

Про MySql не знаю, но в постгресе функция может быть написана на c или питоне. Что там про нее планировщик может знать? Что он может знать про количество итераций если в хранимке PL/pgSQL с циклами? Ничего. Статистики нет, соответственно планировщик нормально не работает.

Статистики нет,

безусловно?! по факту (хранимка и не (procedure)SQL) выключает оптимизатор?

Не то чтобы выключает, но в целом делает менее предсказуемым. При этом на одних входных данных он без статистики составит нормальный план, а на других тоже без статистики - нет, и заранее предсказать на каких данных будет задница очень трудно. Соотвесттвенно и протестировать не получится.

upd. неправильно выразился. Планировщик даже не то что будет не предсказуемым, он просто будет делать одинаковые планы там, где при использовании SQL на основе входных данных и статистики он бы выбрал другой, более оптимальный план.

функция может быть написана на c или питоне...PL/pgSQL с циклами

А, так понятнее.

Если нет никакой острой нужды - хранимки вообще лучше писать на голом LANGUAGE sql, но и в LANGUAGE plpgsql что-то не замечал каких-то непредсказуемых особенностей.

Там больше вопрос в неудобстве их отлаживать. Искать в логах построенные планы - так себе удовольствие.

замечал каких-то непредсказуемых особенностей.

А их часто и невозможно заметить. Подумаешь оптимизатор выбрал поиск по индексу вместо sequential scan, который был бы на 15% быстрее, никак ты это не заметишь.

Без реального примера - это все-таки больше похоже на миф и страшилку.

Хранимки - прекрасны, если уметь ими пользоваться и не иметь неприязни.

Опять же - позволяют освободить тех же «бекендеров» из заголовка темы полностью от этих неприятных дум про SQL. Пусть там всякое БПФ или сортировку пузырьком у себя пишут. Любое, что не касается хранения данных.

если диапазон ключей (т.е мощность не велика) то сортировка на sleep самое async goрутинно

SQL это не ассемблер. Это скорее хаскель чем ассемблер, язык супервысокого уровня придуманный специально для операций над множествами, за ним стоит вся мощь реляционной алгебры.

Всё так, но сам SQL не очень удачный, да ещё и развалился на множество диалектов. Теоретики его не любят, тот же Дейт критиковал всю жизнь. Практики тоже не любят, всё норовят обвесить ормами, чтобы не связываться. Любят SQL только DBA, которые используют его тёмные стороны для алхимических таинств ради своей вечной жизни. Но конечно, когда смотришь на потуги изобразить реляционные запросы на цепочках методов, хочется всех кодеров расстрелять и заменить на DBA.

sql это буквально ассемблер

Его используют как ассемблер. Самый шик это генерить запросы ормом из императивной параши типа пхп. Сам орм при этом выглядит как упражнения пятиклассника, который не только про реляционную теорию не слышал, но и об ООП имеет самые смутные представления.

так как вы эти хранимки оптимизируете/траблшутите? insert into logs?

auto_explain.log_nested_statements = true и смотреть в лог.

Но если честно - так делать лень.

Обычно выковыриваю запрос из хранимки наружу, DBeaver умеет подставлять параметры в запрос, меняю передаваемые в хранимку параметры на вот эти DBeaver'овские переменные, выполняю с разными вариантами их, смотрю в планы. Когда всё устраивает - заковыриваю запрос обратно в хранимку.

Вероятно это слегка колхоз и есть какие-то инструменты.

А, ну изначально log_min_duration_statement = 1000 и следить глазами за логом - кто там дольше секунды появится, конечно.

В такой ситуации вариант всегда* один — искать новую работу. Ибо, с кем поведешься того и наберешся.

* Разве что ты уже матерый предпенсионный специалист и там тебе платят больше чем конкуренты.

Терабайт даных не так уж и много

Сделайте View с нужными вам оптимизациями. Пусть оттуда берут.

В крайнем случае Materialized View

Чесно говоря не совсем понятно почему с таким объемом данных нужно что-то оптимизировать.

Может архитектуру?

Как вариант положить все в базу оптимизированную для чтегия, к примеру Elastic Search.

И вообще SQL is dead!

Я уже лет 5 его только в legacy вижу ;)

И вообще SQL is dead!

Уже придумали что-то лучше?

У вас какой-то поток сознания прорвался.

Хранимка - значит оптимизатор БД не может составить нормальный план запроса.

Что именно по вашему мнению оптимизатор запроса может не осилить в операциях «insert/update/delete»?

Если в хранимке или триггере так или иначе проверятся целостность данных - значит можно ее нарушить другим запросом или отключить триггер и база останется неконсистентной.

Целостность данных имея необходимые полномочия можно нарушить всегда, но какое отношение это имеет к sp или триггеру?

И вообще SQL is dead!
Я уже лет 5 его только в legacy вижу ;)

Вы прочитали пост 15-ти летней давности.

Mongodb уже много лет

мечта Бахмана очучествилась?

поклёпсты: https://news.ycombinator.com/item?id=17497164

Целостность данных имея необходимые полномочия можно нарушить всегда, но какое отношение это имеет к sp или триггеру?

Самое прямое. Отключаем фк, заливаем мусор, включаем фк - БД ругается, понимаем что что-то не то. Отключаем триггер допустим занимающийся денормализацией, заливаем мусор, включаем триггер - БД не ругается, а целостность нарушена, но для этого хотя бы надо специально выключить триггер. Проверяем что-то в хранимке перед тем как вставить, пишем в таблицу в обход хранимки - целостность нарушена, никто про это не знает, и ничего отключать не надо. Поэтому все что касается логической целостности надо по максимумум контролировать реляционными ограничениями, а не императивными проверками. Если не получается - то хотя бы отделить логику изменения данных от логики поддержания целостности, перенеся поддержание целостности в триггер. И только в самых крайних случаях, когда уперлись в производительность, в легаси или в нехватку собственных мозгов использовать вариант с контролем в хранимке, и каждый раз делая подобное искренне чувствовать за собой грех ибо пошел против воли Его, и бежать искупать его постом, молитвою и помощью бедным. Так что в этом смысле индекс >>>>> триггер >> моча == говно >> хранимка.

Что именно по вашему мнению оптимизатор запроса может не осилить в операциях «insert/update/delete»?

При чем тут вообще это, последовательность неких рутинно выполняемых действий как раз нормально перенести в хранимку. Интересное начинается когда результат функции используется в select from или в еще в каком условии. Постгрес например не умеет использовать статиcтику по функциональным индексам, он вместо этого использует статистику по полям - параметрам функции, с понятным результатом если функция считает что-то типа хэша. А по чему-то более сложному типа пользовательской функции он вообще будет выбирать план тыкая пальцем в небо.

Плюс если в хранимке есть сложная бизнес-логика или математика она так или иначе нагружает сервер БД, чудес то ведь не бывает, а реляционная БД плохо физически масштабируется, если хочется оставаться в рамках реляционной нормализованной модели. Это тоже аргумент за перенос части такой логики на клиент, там где это возможно.

проблема практики что sql не очень то и реляционен

ибо mapreduce - которое кста очень хорошо маштабируется вполне реляционен

и в sql mapreduce вполне маштабируем

но вот эволюция всей этой машинении не позволяет удерживаться вендорам в чистых реляциях поэтому и существует отдельная подкатегория гремлинов IT - DBA не читать как DеBилА

Постгрес например не умеет использовать статиcтику по функциональным индексам, он вместо этого использует статистику по полям - параметрам функции, с понятным результатом если функция считает что-то типа хэша. А по чему-то более сложному типа пользовательской функции он вообще будет выбирать план тыкая пальцем в небо.

Тоже какая-то страшилка детям на ночь. Есть же COST, IMMUTABLE, STABLE для функций, есть GENERATED ALWAYS поля для каких-то страшно хитрых вычисляемых функциями индексов.

Про «БД плохо масштабируется» - это прям страшилка-покер ) Мне её мои шарписты почти каждый день рассказывают. БД и не надо масштабировать в том смысле, в котором масштабируются питоны и прочие бэки, методом запуска 100500 экземпляров.

Я ННП

оставаться в рамках реляционной нормализованной модели

Друг, они пихнули json в тип, накрутили вокруг него dsl и сделали из реляционной нормализованной модели (тут еще слово «строгой» пропущено) k-v. Это все вместо fs. А твой пост 99% читающих воспинимают как что-то на шумерском.

Есть же

Есть много чего, но факт остается фактом - статистика для immutable функций точно так же не собирается как и для mutable, соответственно планировщик не может ее использовать, и понять насколько это влияет на план трудно если вообще возможно.

Хранимки с побочными эффектами - ад для поддержки, если в них что-то чуть сложнее последовательного выполнения скрипта. Функции возвращаюшие датасеты из которых потом идет выборка - аналогично. С проверками логической целостности данных внутри - аналогично. Короче избегать по возможности, стремиться к тому, чтобы работать с БД декларативно.

БД и не надо масштабировать в том смысле, в котором масштабируются питоны и прочие бэки, методом запуска 100500 экземпляров.

Не «не надо», а дорого и сложно из-за наличия связей и стейта. Потому как масштабируется БД или покупкой все более и более мощного и дорогого железа или отказом от связей и соответственно от контроля целостности средствами БД или хитрым шардированием, что тоже не всегда возможно. А так никто бы не отказался взять прикупить еще один сервачок, поставить рядом и располовинить нагрузку. И не стал бы тогда 1с хвастаться запуском 1с/постгрес на 192-процессорном сервере или типа того.

а, ну да. Хранимки хранимкам рознь, это факт.

T-SQL-вые процедуры вызывающие другие процедуры, которые вызывают третьи процедуры, и у каждой свои тараканы с откатами. Жуть жуткая.

Не, у меня всё просто обычно. Если смогу запихать в один CTE все SELECTы, INSERTы и UPDATы одновременно - обязательно запихаю. Такое.... «оформленные как процедуры скрипты в один запрос».. Наверное, так как-то.

О, про json это отдельная история, хорошо что напомнил

Если вспомнить как все начиналось - лет 25 назад или типа того внезапно у множества молодых людей возникла идея, что все их беды от схемы, и если отказаться от схемы сразу же наступит всеобщее счастье. NoSQL базы стали появляться как грибы после дождя, помню был блог чувака с румынской фамилией, там чуть ли не каждые пару недель появлялся пост о новой NoSQL БД или об очередном раунде финансирования на миллионы. Постгрес в то время был таким гадким утенком, копались в нем какие-то задроты, правильные но простые пацаны использовали MySQL, пацаны посложнее DB2 c Oracle. И тут видимо возникла идея - а давайте добавим json в нашу РСУБД и получим как бы модную документоориентированность с key-value, и при этом с ACID и нормальной схемой, если вдруг кому-то приспичит реально работать. Попробуем хоть так продвинуть продукт. Продать это насколько помню все равно не удалось, контачиться об реляции, SQL и схемы было nekulturna и с json и без него, да и с евангелизмом у задротов вообще было не очень.

В конце концов наиболее умные из молодых людей прозрели, что схема это благо, что она всегда существует если не в БД, то как минимум в голове у менеджера, добавляющего в описание продукта новое поле, что целостность данных удобно контролировать схемой, придумали схемы для json, поняли что если нет одной схемы значит есть много схем и сложность работы с ними растет квадратично с учетом всех возможных комбинаций, и хайп затих сам собой.

Прошло немало лет, иных тех NoSQL баз уж нет, а те далече. От хайпа в наследство остался совершенно на мой взгляд чудовищный стек NodeJS + Монга, который одно время всерьез пытались пиарить как универсальную замену LAMP, теми же методами как вот сейчас пиарят Rust, и всякое специализированное типа S3 и rocksdb.

Постгрес тем временем возмужал, оброс жирком и пользователями, подвинул MySQL, и даже начал импортозамещать Оракл в одной далекой северной стране. На реляционки опять смотрят с уважением, потому что фундамент на котором они основаны придумали умные люди.

И вот к чему я это все. Если бы сейчас встал вопрос добавлять поддержку json в postgres или не добавлять - я думаю оппозиция этому среди разработчиков была бы куда серьезнее чем 25 лет назад. При том что иметь json конечно лучше чем не иметь.

Но сама идея добавить структуру в структуру, чтобы была возможность работы со структурой, пока работаешь со структурой, величайше великая. И я не согласен с оценкой. Хайп вышел в продакшен и таки их тьма. Куда ни плюнь, везде jsonb - прямо мания. Настолько, что пихнуть json в k-v днище.

Если вспомнить как все начиналось - лет 25 назад или типа того внезапно у множества молодых людей возникла идея

Идее «NoSQL» сто лет в обед. Я большую часть жизни просидел на продуктах PickSystems родом из 60х годов. Там те же json'ы по сути. Просто тогда их так не называли.

Ну да, идея не новая, реляционки и придумали, чтобы упростить людям жизнь, заменив иерархические базы данных. Но 25 лет назад NoSQL придумали во второй раз, наступив на те же грабли.

Я вот упорно гоню от себя конспироложескую мысль, что это была спланированная диверсия от крупных контор, чтобы всякая мелочь зарылась носом в сложность и не мешала им делить быстрорастущий рынок. Иначе непонятно как могло произойти такое массовое помешательство.

Зачем нужны погроммисты, которые не умеют в бд? Они точно бекендеры, а не курьеры?

Расово верно ли открывать тикет Лиду пеаписать каждый запрос?

Зачем нужны погроммисты, если лид и так за них работает?

Или вообще может быть эти проклятые запросы скидывать на написание какому-то dba?

У погромистов орм выполняет один тупой запрос в цикле. Чем тут поможет им дба?

Отключаем триггер допустим занимающийся денормализацией, заливаем мусор, включаем триггер - БД не ругается, а целостность нарушена

Ну это предумышленное действие которое выполняет DBA и как таковой проблемы в использовании триггера нет.

Проверяем что-то в хранимке перед тем как вставить, пишем в таблицу в обход хранимки - целостность нарушена

Или другой вариант, у вас универсальный двух и более уровненный справочник, консистентность обеспечена на логическом уровне и никакой FK не спасет от возникновения противоречивых данных, а вот на уровне триггера как раз таки можно и матом послать.

Плюс если в хранимке есть сложная бизнес-логика или математика она так или иначе нагружает сервер БД

Нагружает, но вроде как на то он и сервер, а не *.dbf файлопомойка, «ему за это деньги платят».

А по чему-то более сложному типа пользовательской функции он вообще будет выбирать план тыкая пальцем в небо.

Приведите пример тыканья в небо плиз. Я не оспариваю ваше мнение, но хотелось бы пруфа.

Плюс если в хранимке есть сложная бизнес-логика или математика она так или иначе нагружает сервер БД

Повторю: Нагружает, но вроде как на то он и сервер, а не *.dbf файлопомойка, «ему за это деньги платят».

Напишите пожалуйста ваш опыт в годах и стек используемых технологий.

Если вы «часть команды - часто корабля», то поднимать вопрос, вырабатывать решение, идти по намеченному пути.

Если «один за всех и каждый сам за себя» - то и так сойдет.