Что не так с SQL: как должен выглядеть современный язык запросов
Things I want in a modern relational query language
Автор, имеющий опыт работы с MySQL, Db2, SQLite, SQL Server, Oracle и Postgres, размышляет о недостатках SQL и предлагает идеи для нового языка запросов. Среди ключевых улучшений — синтаксис, основанный на C или Python, поддержка функционального программирования, более понятные планировщики запросов, расширенные пользовательские типы данных, алгебраические типы данных с pattern matching и внешние ключи, поддерживающие несколько типов. Статья вдохновлена недавними обсуждениями новых языков запросов, таких как Acadia.
Я думаю, что одной из главных причин появления NoSQL является то, что SQL — мощный язык благодаря заложенным в него идеям, но он часто реализован неуклюже и архаично.
- scythmic_waves
Здесь есть пересечение с некоторыми из моих любимых эссе о том, почему SQL несовершенен:
https://www.scattered-thoughts.net/writing/against-sql
Этот конкретный пост заканчивается списком пожеланий, так что он наиболее похож на пост автора. Но на сайте есть и другие, которые мне очень нравятся (нажмите на иконку дома и поищите "SQL" на странице).
Мое личное мнение: SQL будет править еще долго, потому что задача его замены колоссальна из-за inherent сложности баз данных. LLM усугубляют ситуацию, потому что они отлично переводят прозу в SQL. Теперь, когда то, насколько SQL раздражает программистов, имеет меньше значения, SQL со временем станет чем-то вроде ассемблера: тем, что в основном пишут компьютеры, потому что людям сложно работать с ним напрямую. Это глубоко иронично, учитывая, что SQL якобы был создан, чтобы читаться как проза, то есть быть удобным для людей.
- burakemir
Мне было бы искренне интересно, что думают автор поста и другие здесь о Mangle Datalog в этом контексте. Реализация на Go здесь: https://codeberg.org/TauCeti/mangle-go, а реализация на Rust здесь: https://codeberg.org/TauCeti/mangle-rs.
Реализации не отличаются высокой производительностью, но если все помещается в память или вы можете организовать свои данные и интегрировать их через внешние запросы, вы получите рабочее решение для многих случаев использования.
Я не ставил целью заменить SQL, и хотя я не против принятия, это не причина, по которой я делюсь этим здесь. Открытие исходного кода было мотивировано желанием сделать datalog более известным. Я провел небольшое исследование и обнаружил, что мне нужна реализация datalog с определенными характеристиками; я точно знал, что не хочу использовать SQL для того, что мне нужно.
Здесь есть структурированные типы, рекурсия, возможность именовать предикаты и компоновать запросы... У Mangle есть пользователи, и есть несколько приложений, которые используют подход "запросы как логическое программирование".
Я думаю, что из этого обсуждения можно извлечь понимание: язык запросов и система (реализация СУБД), частью которой он является, вряд ли могут быть разделены, когда речь идет о неизбежных требованиях к производительности.
- bastawhiz
Как мета-комментарий: я могу воспринимать блоки кода без подсветки синтаксиса, и я могу воспринимать блоки кода с переносами. Но и то и другое вместе с длинными комментариями превращается просто в шум из строк. Больше нет полезного визуального сигнала, как их читать. На моем телефоне блоки кода просто невозможно осмысленно разобрать.
- justanothersnek
Я обычно использую и SQL, и библиотеку для работы с датафреймами. Думаю, это своего рода лучшее из двух миров. SQL для высокоуровневых, крупных агрегаций, библиотека датафреймов для случаев, когда эквивалентный SQL-запрос был бы очень утомительным или трудным для отладки.
- mcc1ane
https://www.geldata.com/blog/we-can-do-better-than-sql
(https://news.ycombinator.com/item?id=24106608, https://news.ycombinator.com/item?id=19871051)
- weitendorf
Это очень похоже на Spark до того, как он стал таким ориентированным на предприятия. В мое время мы писали на Scala для выполнения запросов, и когда мы разобрались, как настроить компилятор и среду выполнения, нам это понравилось!
Недавно я начал изучать Postgres и был очень удивлен, как легко вводить новые типы/операторы и т.д. через код на C. Я не говорю о доменах. Просто напишите немного C, и вы можете получить любой тип, какой захотите. Это действительно демистифицировало для меня "расширения"; я думаю, что это активно вредное название (оно звучит громоздко, отталкивающе, исходя из моего опыта работы с "расширениями" и "плагинами" в других местах) для того, что по сути является просто пользовательскими типами и функциями. Больше людей должны попробовать писать свои собственные расширения Postgres. Это совсем не сложно!
Я давно варюсь в этой области (HDFS/spark, Apache Pinot, проприетарные вещи, экспериментальная функциональная ORM поверх SQLite). Самая большая проблема, я думаю, — это интерфейс между уровнями управления/администрирования, приложения и "запросов". Я думаю, что-то вроде grpc/protoc (или, действительно, то, как Spark использовал JVM) необходимо, чтобы обеспечить непротекающие абстракции и более программные/структурированные интерфейсы от БД к ее клиентам. С радостью поделюсь подробнее, но в основном, я думаю, база данных должна стать способной к общему (мета-)парсингу с рефлексивной системой типов.
- mikewarot
Мой запрос 15-летней давности[1] — живое расширение SQL. Позвольте запросу быть подпиской на базу данных, чтобы любые обновления передавались в виде дельт слушающему клиенту. В моей практике использования SQL было множество случаев, когда один и тот же запрос выполнялся снова и снова, просто чтобы получить/обработать эту дельту.
Разве не было бы гораздо эффективнее работать так с самого начала?
[1] http://livesql.org/ <--- всего несколько абзацев текста из 2011 года
- nylonstrung
PRQL — одна из лучших попыток создания нового языка запросов, на мой взгляд.
Я работаю над языком запросов на основе Lean4, который компилируется в substrait; я думаю, что его мощь в отношении типов и функционального программирования может значительно улучшить эргономику SQL.