Международная организация по стандартизации (ISO) утвердила и опубликовала международный стандарт SQL:2023 (ISO/IEC 9075), определяющий девятую редакцию спецификации по языку SQL, применяемом для манипуляции данными в реляционных СУБД. Прошлое обновление спецификации было выпущено в 2016 году (SQL:2016)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59239
SQL -- это манястандарт. Стандарт де-факто -- это документация реализаций. Вот ее и надо читать.
Примерно как с сишечкой - угадай скомпилится оно на другом компиляторе, а если скомпилится - будет ли работать также.
У сишечки по крайней мере есть из чего выбрать.
Очень жаль что выбор из сортов вы считаете выбором и радуетесь ему))
другое дело когда единственное и то не допилили
ой тут бы старые стандарты доучить + популярные спец. выражения базы, которую использую, в голове места не осталось
в кривых руках только жабаскрип или просто жаба, даже до раста подпускать нельзя
Но-но-но!Java, SQL и XML это столпы развития ИТ-индустрии (в нулевые, а в заскорузлых банках и сейчас), попрошу не гнать!)
внезапно поведение java отличается на разных jvm, хоть и не сильно, а поведение js отличается в браузерах (включая скорость работы), а на js вообще писать не нужно, только TypeScript
Как полный нуб в SQL с этим столнулся. Читаешь введение в SQL, всё красиво и логично, пытаешься просто скопипастить пример с CREATE FUNCTION - и внезапно ни в одной реальной СУБД это не работает. Везде свои костыли и колдунство, ни одна не реализует стандарт.
А зачем FUNCTION в запросах? это стандарт выборки или обработки, то что всякие ораклы реализуют всю логику на sql вовсе не значит что это правильно, они и на брейфаке реализуют если будет возможность продать, только на нем никто не купит, а купить продукт написанный на одном sql это ведь так соблазнительно, не надо заморачиваться с чем-то еще, только потом локти кусают, и прикручивают всякие костыли, чтобы интегрироваться с чем-то еще.
>А зачем FUNCTION в запросах?Потому что это очень удобно для сложных запросов.
Молодцы, ребята, не отличаете DML от DDL
Т.е. создатели конкретных БД тоже не различают ?
самобытность оракла идет потому, что там фичи многие еще до появления их в стандарте были
А зачем функциональное программирование? Если логика работы с базой чуть сложнее, чем select * from TABLE1, то без функций там делать нечего.
интересно, узнал ли BorichL уже что функциональное программирование это не когда ты функции в SQL определяешь чтоб там логику императивно запилить?
Каждая субд реализует свой стандарт
Не лучше или хуже - просто свойЧтоб не соскочили)
Справедливости ради, постгря реализует ближе всего к стандарту.
жырно.
Стандарт нужен, чтобы маняреализации не слишком расходились между собой.
Что эта проприетарщина делает на опеннете?
> ISO/IEC 9075А чем оно принципиально отличается от ISO/IEC 9899:2018 или ISO/IEC 14882:2020?
Оно тоже проприетарщиана или нет?
А кто сказал, что оно отличается?
Свободно читать и распространять нельзя - значит проприетарщина.
А что ты тут делаешь? Как ты вырвался от санитаров?
Это круто, сейчас как раз пишеться прокси через sql через вк
А чтобы прикрыть такой прокси нужны будут космические ресурсы - тоесть это невозможно
главное бюджет. если очень захотеть можно в космос полететь
что за чушь я прочитал?
> Property Graph QueriesГодно. Посмотрим как это будет в реализациях работать, конечно же, но может хоть не придётся для простых небольших графов отдельную БД поднимать.
Наконец-то нормальный стандарт.
Стандарт-то может и нормальный, но всем наплевать на него. Главное, реализация в конкретной СУБД.
Стандарт позволяет поумерить творческую энергию создателей конкретных СУБД.
Как? Их накажут, да?
особенно когда создатели создали конкретные СУБД до рождения половины самых осведомленных и опытных анонимов и создания стандарта тоже
Это в NoSQL даже стандарта нет и там треш трешовый.
что там стандартизировать? избыточные агрегаты JSON в качестве значений?
эт вражеский стандарт
нужен ГОСТ.
Звучит как "опубликован новый стандарт латыни, наконец-то все проблемы коммуникации среди граждан Римской Империи будут решены".
Скорее новая версия Эсперанто и скоро все люди не шаре будут говорить на одном языке.
Расширены возможности выполнение операции "ORDER BY"Ну не может постгря такое, почему, написано, что есть то?
Ты понимаешь разницу между стандартом и реализацией стандарта?
Ты понимаешь, что этот стандарт только утверждён и пока ни одна РСУБД на планете его не поддерживает?
Не хватает функций для частичного обновления поля. Например если я хочу одним запросом обновить содержимое поля с n по n+m байта, или если ключа нет, вставить данные с n по n+m байт, а остальное занулить, такого нет.
Не хватает возможности массового обновления разных полей во сножестве строк - приходится либо много строк обновлять одинаково, либо все по-разному, но только по одной :D
Давно IF и CASE отменили?
С графами что-то заложить давно напрашивалось, но получившийся синтаксис реально удолбищный и вырвиглазный.
И что там напрашивалось?! Если тебе нужны графы, то используй графовую бд, а не клюй всем моск.
У поколения лефтпада построить граф на реляционке уже рокет сайнс?
Бегать по графу на SQL — чистой воды мазохизм, где даже примитивный запрос легко превращается в пару страниц SQL. Нет, конечно же это не рокет сайнс, всё можно. Но потом обслуживать это тяжело, новых людей в проект вводить тяжело, любые изменения даются лишним трудом. Поэтому проще и дешевле поднять рядом специализированную БД и общаться с ней. Для больших проектов придётся это делать в любом случае, а вот для небольших эти операционные накладные расходы немного жмут. А то, что тебе синтаксис показался не таким, так это от того, что опыта работы с такими системами у тебя нет, и проблематику ты если и представляешь, то в лучшем случае по картинкам из учебника. Так что, Вася, ты бы мел поупырил.
Ну я и говорю - рокет сайнс. На деле-то примитивная операция, не требующая специализированных БД, под каждую из которых надо отдельного DBA.
Да и вообще эти ваши "бд" с DBA странная какая-то понь-цепция - что нельзя было простыми регулярками по текстовому файлу обойтись? Ох уж это новое поколение, все им "рокет сайнс"...
В ряде случаев регулярки по исходнику будут гораздо быстрее, чем сложить исходник в RDBMS и тягать оттуда.
Особенно когда исходник надо раз-два обработать, или он специфично RDBMS-не-кантуемый.
Поверь мне, в этом случае я RDBMS тянуть не буду.
Но у поколения смузи по ходу две крайности.
Ну вот и тут так же - один-два запроса можно и на рСУБД сделать, но если в проекте появляется пул задач связанный с обработкой графов - лучше (проще, быстрее, дешевле) затащить в периметр что-то более специализированное. Молоток конечно хороший инструмент и при желании им можно забить пару шурупов - но бояться отвертки ей-ей не нужно )
Ну вот у меня тот случай, когда графы обходить нужно, но лепить для этого какую-то отдельную херню не требуется.
Тем более, что для обхода достаточно просто рекурсивного запроса.
Ну вот в postgresql для подобных применений можно использовать ltree - edgedb\apache age прям перебор, а ltree обычно быстрее (и удобней) recursive cte.
А синтаксис говно, потому что к нему пустили растОманов.
Расскажи, как злые рестомане тебя обижают и унижают, покажи на алфавите, какими буквами сделали тебе больно
Незапоминаемые закорючки в стандарт sql ещё с json пришли (((
какой смысл в этих стандартах, если все равно каждая СУБД использует свой диалект?
Иллюзия контроля во все поля. Некоторым трудно признать, что есть несколько конкурирующих диалектов созданых в рамках работы над реальными проектами. Надо непременно один стандарт включающий все на свете, чтобы их не изучать. Такая попытка унифицировать буйство рельного мира.
SQL хорош для своих лет - в смысле для 197* годов. Сегодня системы стали настолько сложными и такие сложные данные внутри (напр JSON), что SQL с его у6людcким, неуклюжим синтаксисом и возможностями отстал на те же 50 лет.Миру нужны новые возможности или хотя бы вразумительный доступ к данным. Например, в стиле FoxPro - когда программист сам ходит по таблице, запрашивает подчинённые записи, агрегирует поля и т.п. Скажем, нет ничего проще, чем пройтись по таблице, собрав и по-недельные суммы и помесячные ЗА ОДИН ПРОХОД, попутно сосчитав баланс отрицательных чисел. Мы 100% придём к такой технологии, но не сейчас - слишком заскорузлые мозги у нынешних "профи".
Зачем?
Ваш текст все равно планом будет преобразован.
В конце концов powerBi или другая херовина пишет запросы, или клиенты фильтры в ui выбирают
Ты не понял. Вместо формулировки "что я хочу" на неуклюжем SQL, я буду "алгоритмически" писать, что мне нужно от таблиц. Потому что даже в простых системах есть неординарные запросы, которые легче сказать, чем написать (особенно с агрегированием, сортировкой и т.п.). SQL потому и сложен, что он ДЕКЛАРАТИВНЫЙ (что ещё раз подчёркивает его неуклюжесть для использования "императивным мозгом").
Поэтому старый подход а-ля FoxPro вполне может быть востребован, заодно сильно упрощая жизнь разрабам.