https://www.opennet.me/openforum/vsluhforumID3/130668.html Международная организация по стандартизации (ISO) утвердила и опубликовала международный стандарт SQL:2023 (ISO/IEC 9075), определяющий девятую редакцию спецификации по языку SQL, применяемом для манипуляции данными в реляционных СУБД. Прошлое обновление спецификации было выпущено в 2016 году (SQL:2016)...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59239<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#82 Sat, 06 Jan 2024 04:10:43 GMT Ты не понял. Вместо формулировки "что я хочу" на неуклюжем SQL, я буду "алгоритмически" писать, что мне нужно от таблиц. Потому что даже в простых системах есть неординарные запросы, которые легче сказать, чем написать (особенно с агрегированием, сортировкой и т.п.). SQL потому и сложен, что он ДЕКЛАРАТИВНЫЙ (что ещё раз подчёркивает его неуклюжесть для использования "императивным мозгом").<br>Поэтому старый подход а-ля FoxPro вполне может быть востребован, заодно сильно упрощая жизнь разрабам.<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#81 Fri, 15 Sep 2023 10:07:48 GMT интересно, узнал ли BorichL уже что функциональное программирование это не когда ты функции в SQL определяешь чтоб там логику императивно запилить?<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#80 Sat, 10 Jun 2023 09:00:31 GMT жырно.<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#79 Fri, 09 Jun 2023 10:16:34 GMT Зачем?<br>Ваш текст все равно планом будет преобразован.<br>В конце концов powerBi или другая херовина пишет запросы, или клиенты фильтры в ui выбирают <br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#77 Tue, 06 Jun 2023 20:42:51 GMT SQL хорош для своих лет - в смысле для 197* годов. Сегодня системы стали настолько сложными и такие сложные данные внутри (напр JSON), что SQL с его у6людcким, неуклюжим синтаксисом и возможностями отстал на те же 50 лет.<br><br>Миру нужны новые возможности или хотя бы вразумительный доступ к данным. Например, в стиле FoxPro - когда программист сам ходит по таблице, запрашивает подчинённые записи, агрегирует поля и т.п. Скажем, нет ничего проще, чем пройтись по таблице, собрав и по-недельные суммы и помесячные ЗА ОДИН ПРОХОД, попутно сосчитав баланс отрицательных чисел. Мы 100% придём к такой технологии, но не сейчас - слишком заскорузлые мозги у нынешних "профи".<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#76 Tue, 06 Jun 2023 13:40:22 GMT что за чушь я прочитал?<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#75 Tue, 06 Jun 2023 10:53:59 GMT Ну вот в postgresql для подобных применений можно использовать ltree - edgedb\apache age прям перебор, а ltree обычно быстрее (и удобней) recursive cte. <br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#74 Tue, 06 Jun 2023 05:26:45 GMT Тем более, что для обхода достаточно просто рекурсивного запроса.<br> https://www.opennet.me/openforum/vsluhforumID3/130668.html#73 Tue, 06 Jun 2023 05:24:57 GMT Ну вот у меня тот случай, когда графы обходить нужно, но лепить для этого какую-то отдельную херню не требуется.<br>