Комментарии 109
Уже через год мы будем общаться с базами данных по-русски
А зачем ?
Кому от этого общения станет лучше ?
Профессия корректора получит новое дыхание. Филфак МПГУ вдвое увеличит приём студентов.
…Шутка про астрологов…
А вообще, конечно, тема интересная. Что в реальности вижу, например, я? Со стороны, как сейчас модно говорить, «кривозубых крестьян» есть огромный спрос на РСУБД (если бы они только такие слова ещё знали). Потому что в каждой программе заметок или ещё чего-нибудь миллион версий одних и тех же таблиц. Причём, обычный здравомыслящий бухгалтер иногда разбирается в нормализации лучше, чем даёт ему сделать программа, либо криво спроектированная, либо просто рассчитанная на усреднённый и крайне упрощённый юз-кейс. Он бы сам свои данные организовал, да кто ж ему даст. Учить SQL — не вариант. Пользоваться каким-нибудь MyClient или очередным утырочным якобы-GUI (где даже типы по-человечески не названы) — тоже.
Ну вот, а рынок ощупью пытается их удовлетворить. Но, конечно, в противоестественной форме. Если им дать по-настоящему дружелюбную РСУБД, может, в результате половина всего IT станет не нужна. Короче, вопрос в том, как дать юзерам РСУБД, не давая им контроль (ведь при этом потеряешь деньги). И тут кому-то приходит в голову: а давайте сделаем SQL-запросы на человеческом языке! С обработкой в нашем облаке, конеш. Хитры бобры, что тут скажешь. Ещё и под AI инвестиций можно срубить, пока нейрозима не настала.
Так это вижу я. Но я известный циник. А на самом деле благородные рыцари хотят облагодетельствовать человечество.
P.S. Очень интересно посмотреть, как будут дела обстоять с созданием и изменением таблиц. Этим будут заниматься разрабы и админы, а юзерам голый SELECT? Или система будет это делать по запросу на человеческом языке?
Обычный здравомыслящий бухгалтер иногда разбирается в нормализации лучше, чем даёт ему сделать программа... Он бы сам свои данные организовал, да кто ж ему даст. Учить SQL — не вариант.
Весьма иронично, что SQL изначально и создавался как язык для запросов к БД, которым мог бы овладеть любой желающий пользователь, даже без глубоких знаний программирования или математики.
Но в результате имеем то, что имеем.
Хотя SELECT-запросы средней сложности многие аналитики делать вполне себе умеют. Может и бухгалтера такие иногда попадаются?
Мы немного о разном. Я не про то, что некоторые бухгалтеры осиливают технические детали, в т.ч. синтаксис SQL, а про то, что они понимают, что неправильно номер телефона делать полем тикета (например), даже когда какая-нибудь программа им это навязывает. Культура данных, так сказать, у них есть.
А поясните, почему нельзя? Имеется ввиду разделение сущностей и создание реляций? Потому что если тикет представлять глазами как раз бухгалтера, то никаких реляций там нет и быть не может.
Не надо снобистски недооценивать бухгалтеров и прочий непрограммирующий люд. Среди них полно умных людей, являющихся специалистами в своей области. И понимающих, что телефон может быть только подстановкой из таблицы контрагентов (контактов). А кто не понимает, тот разок столкнётся с неактуальными номерами, по которым не дозвониться, перепашет всю базу, включая все тикеты, накладные, внутренние записи, и пр, и навсегда отучится свинячить.
Ну а если не отучится, есть прекрасные профессии, не связанные с уверенным владением компьютерами: психолог, гитарист, собачий парикмахер, промпт-инженер…
Тем, кто не умеет иначе работать с СУБД, не знает SQL, а также разработчика решений для таких людей и занимающимся из поддержкой.
что б не признали инагентом ;)
Запросы вроде «Найти рейсы с задержкой более 2 часов» или «Рассчитать среднюю загрузку автопарка» легко формализуются в SELECT и JOIN.
Вот только реальные запросы к реальной БД из десятков таблиц с десятками полей будут представлять промпты в пару абзацев сложного текста. И проблема будет проверить, насколько корректно:
А) сформулирован запрос (человеком, не знающим структуры БД часто!)
Б) реализован sql-код
И при этом каждая таблица и каждое поле и каждая связь должны содержать пару вбзацев качественного описания, зачем они, что в них и каковы ограничения и т.п., чего сейчас обычно нет в БД.
В статье как раз и говорится про необходимость сбора и систематизации метаданных, которые несут семантику так необходимую языковым моделям (и людям, кстати) для решения задачи. Мы уже сталкиваемся с этим и понимаем важность смыслового описания существующих моделей
Такой промп раньше звался ИЗ, разве нет?
И еще интересно: llm не быстры. Как компилятор из тз в SQL нормально, а как на каждый запрос звать модель...
Видимо хотят создать зазу данных с обёрткой из нейросети и представлять это как готовое решение, как сервис. Наверно, будет и прямой доступ к бд на техническом языке типа sql (должен же быть). Что ж, посмотрим на реализацию, насколько будет практично, будет ли она ошибаться и возвращать не то, будет ли устойчива к перегрузкам и атакам, что по производительности, и вообще получится ли сделать удобно. Верится с трудом, но при определенном таланте все возможно.
будет и прямой доступ к бд на техническом языке типа sql
М-м, Паскаль с асссемблерными вставками...
это ллм оператор ) тоесть придётся говорить о базе данных не как о существующем предмете как в магазине покажите вон ту штучку ), а понимать какую таблицу попросить, получается промптер с рисованием таблиц или спрятанные запросы и выведенные в язык, но вроде это костыльно
А почему бы и нет? Там всего лишь именования полей и отношения между полями (таблицами).
Почему бы и нет?
Изобретут заново язык 1С но для SQL, на сколько десятилетий опоздали то?
Раньше учили SQL, теперь будем учиться составлять промпты?
LLM играет в угадайку по вероятностям вместо понимания. Сложность и неоднозначность естественного языка превращают перевод запросов в SQL в лотерею.
Боюсь, основной проблемой станет то, что многие неспособны вменяемо сформулировать задание на своём языке. Почитайте вопросы на форумах - там порою ну такое спросят! И только после десятка уточнений более-менее становится понятно, что надо автору, и далеко не всегда удаётся найти нормальную корреляцию между задачей и исходным текстом вопроса.
А ведь LLM, в отличие от человека, уточнять пока не умеет, и вряд ли быстро научится. А с интуицией там вообще полный швах.
Так что по текущему состоянию - простейшие типовые запросы, и не более.
ИИ могут задавать уточняющие вопросы если их попросить, и это можно прямо в системный промпт добавить (лучше с критериями + модель думающая).
Могут. Но ой как не любят. Я несколько раз пытался сделать так, чтобы спрашивал, если что неясно/неполно. Спрашивает один-два раза и перестает, вне зависимости от того есть ли у него полная информация или нет.
Ну это-то решаемо. Беда другая: как проверить, что в запросе не содержится ошибок? Если даже нет однозначной компиляции запроса в условный sql –т.е. запрос, дающий корректный ответ на сегодняшней модели, может дать совершенно некорректный на завтрашней.
Я так и думал - тупо имитируют, отрабатывая задание.
ИИ могут задавать уточняющие вопросы если их попросить
И что, задают их когда действительно что-то требует уточнения, или просто произвольно для видимости?
Самые продвинутые - вполне. Естественно там может быть всякая фигня, ИИ же не ванга. В идеале надо все критерии (много-много под каждый случай) запихнуть и пусть переспрашивать пока запрос им не соответствует.
Естественно там может быть всякая фигня, ИИ же не ванга.
Ну то есть, выдают наугад. Как это не ванга? LLM ведь по сути именно что предсказывают слова.
SQL так и возник, в 70х это был "человеческий" язык для конечного пользователя, а не для разработчика.
Это меня всегда и радует. Сначала программисты придумали SQL чтобы пользователи к ним не приставали с запросами: нам нужен отчёт, сделайте …
Потом появились программисты которые тот ко этим и занимаются. Теперь появятся программисты которые будут писать запросы к ChatGPT чтобы он запрос к БД написал.
Совет автору- вопрос бесите боле-менее сложный отчёт, (простые не нужны тут проще sql написать или он уже написан).
И попробуйте его сформулировать от на русском языке. Результат скиньте сюда и мы посмотрим сможет ли наш встроенный EI понять что надо сделать.
Это меня всегда и радует. Сначала программисты придумали SQL чтобы пользователи к ним не приставали с запросами: нам нужен отчёт, сделайте …
А мне SQL всегда напоминал «Автостопом по Галактике», тот фрагмент, где документация по уничтожению Солнца лежала в соседней звёздной системе, а раз там не смотрел, значит, сам дурак.
Если бы программисты на самом деле хотели, чтобы пользователи сами могли сделать отчёт (не приставая, и, главное, не платя программистам), они бы придумали что-нибудь другое.
А что для этого можно ещё проще придумать? Чем SQL плох?
Чем SQL плох?
Тем, что объяснения 'чего в точности я имел в виду' (для чего SQL служит) превращается в десяток строк с десятком взаимных связей между их частями. А человек хочет одну короткую фразу, без уточнений и мозголомства. А о том, что уточнять таки надо(иначе сосчитается что-то не то) - не задумывается.
На естественном человеческом языке тоже точное описание "чего я имел в виду" может превратиться и в десять, и в двадцать строк.
Посмотрите для интереса выступления Ясюковой Л.А. Она в своих исследованиях пришла к выводу, что многие люди не могут понимать письменные инструкции. Уровень владения речью не у всех взрослых развит максимально, у многих самая крупная единица понимания текста это словосочетание. Недаром деепричастный оборот имеет свой отдельный мем "подъезжая к станции, с меня слетела шляпа" – для правильного выстраивания оборота надо воспринимать предложение целиком, видеть его структуру.
На естественном человеческом языке тоже точное описание "чего я имел в виду" может превратиться и в десять, и в двадцать строк.
Разумеется. Но SQL вынуждает это делать всегда. А тут народ как-то надеется, что неестественный интеллект как-то сам догадается, что имелся в виду самый распространенный случай.
Пока у вас данные простые, они будут представлены одной таблицей, а запрос будет представлять одну короткую фразу. Но в реальной жизни обычно информация (и, как следствие, данные) взаимосвязаны так, что без поллитры не разберёшься, поэтому и запросы сложные, и на естественном языке фиг сформулируешь. Попробуйте, например, на естественном языке сформулировать запрос, который вычисляет вашу будущую пенсию по первичным данным (включая, например, проверку вашего статуса ликвидатора чернобыльской аварии и ещё миллион уточняющих обстоятельств, о которых неспециалист вообще не знает).
Кто-то всё равно должен перевести бизнес-логику конкретной ситуации на язык схемы данных.
GUI, конечно.
Например, SharePoint. Но это была очень слабая попытка, с кучей технических ограничений (16 полей каждого типа на таблицу; не более одного блоба; для блобов нет нормального файлового представления, кроме… название из головы вылетело, то которое через http — это первое, что приходит на ум) и архитектурных ограничений (главное из которых — после подстановки данные нельзя использовать в формулах, что делает реляционность игрушечной).
GUI, конечно.
Так это только форма представления. И для сложных запросов и сложных БД он будет не менее сложным и неудобным, чем текстовый интерфейс (SQL). И более сложным в разработке и поддержке.
Например, SharePoint.
А как же MS Access? SharePoint ведь немного для другого.
Если вы понимаете, что SharePoint это другое, если вы им реально пользовались, то в чём вопрос? Access — действительно всего лишь «форма представления» SQL. В том смысле, что в нём нельзя спроектировать многопользовательскую и многотабличную базу и пользоваться ею, не вдаваясь ни в какие технические подробности. А в SharePoint можно. (Правда он всё равно бесполезен в силу технических и архитектурных ограничений, упомянутых выше).
Я SharePoint не пользовался, но по описанию понятно, что это уже уровень выше, чем просто СУБД и SQL в частности. А ограничения его, наверняка, связаны с упомянутыми мной проблемами. Это банально сложно в разработке и требует много ресурсов для работы. Вероятно, просто не рентабельно делать его мощнее.
В ЯП ведь аналогично, чем меньше вдаёшься в технические подробности, используя более высокоуровневые языки, тем более затратно это по ресурсам, и тем более сложная архитектура у таких языков.
ИМХО, невозможно эффективно делать сложные вещи, не вдаваясь в подробности. Сложность не решится сама собой.
А я пользовался. И не просто пользовался, а разбирал на запчасти и пересобирал (и знаю, например, что это якобы aspx-приложение на самом деле в значительной степени написано на unmanaged-плюсах). И прекрасно представляю, откуда берутся его ограничения.
Например, ограничение на 16 колонок каждого типа связано с тем, что все 16 колонок созданы заранее: Int1, Int2 .. Int16. (Сколько каждого типа, боюсь, я уже подзабыл, конкретно интов может и 32 — популярный тип, как-никак). Когда юзеру кажется, что он создаёт колонку, на самом деле под капотом его «колонка» маппится на существующую путём изменения метаданных таблицы. Мягко говоря, архитектурно это не лучшее решение. Можно (и нужно) динамически создавать настоящие таблицы.
Или вот: почему у них нет файлового представления блобов. А для чего у Майкрософта оно есть? )) У них же вообще с виртуальными ФС шляпа. Это уже потом они сделали OneDrive, когда Шарик сам уехал в облака.
Всё это совсем не фундаментальные ограничения, а либо спроектировано… скажем так, весьма своеобразно, либо отсутствие нужных корпоративных инструментов в момент разработки, либо маркетинг.
Что касается «это уже уровень выше, чем просто СУБД» — вы это про то, что его позиционировали как цэмээску? «Корпоративные порталы»? Ну так инженер не слушает, что там несут маркетолухи, а смотрит на суть. А суть в том, что это именно и буквально РСУБД. Но вместо текстового DSL (SQL) в качестве интерфейса там GUI. Для каждого элемента SQL предусмотрен counterpart в UI. Например, ключевым словам WHERE, GROUP BY, TOP из SELECT в нём соответствует создание и настройка view. Всё это не делает уровень Шаропоинта выше, чем у традиционных СУБД. Он просто другой. Сам подход другой. И очень интересный.
Если вы хотите точных терминов, замените коммерческий и малосмысленный термин “SharePoint” на “WSS” (инженерное название подсистемы, реализующей РСУБД).
Что касается «это уже уровень выше, чем просто СУБД» — вы это про то, что его позиционировали как цэмээску?
Нет. Это про то, что SharePoint - это не система управления реляционной базой данных. Она включает её, но ей не является. Поэтому не может быть альтернативой SQL.
Если вы хотите точных терминов, замените коммерческий и малосмысленный термин “SharePoint” на “WSS” (инженерное название подсистемы, реализующей РСУБД).
Не понимаю, что вы имеете в виду. Для меня WSS - это WebSocket Secure. Не имеющий к этому никакого отношения.
Windows SharePoint Services
Ну это не эквивалент SharePoint. Но так же не является СУБД.
В комментариях к этому материалу много говорилось про то, что SQL изобрели для простых пользователей. Это потом он стал языком, на котором программа общается с СУБД. И пользователи должны были из консольки создавать схему, вносить данные и запрашивать выборки. Пользоваться, короче. Ну так опишите, какую задачу пользователи могут решить при помощи SQL-сервера и не могут при помощи WSS. Бухгалтерия, таск-трекеры, CRM — я видел, как все эти вещи делали на ШП. С нормальными справочниками, а не пихая все данные в одну таблицу, с несколькими пользователями, с выборками и отчётами.
Только не забудьте, что я написал: что WSS это не просто РСУБД, это игрушечная РСУБД. Полноценной она стала бы, если бы убрать глупые ограничения. В первую очередь, если бы результат lookup можно было использовать в формулах. И раз уж там есть скоупы в виде sites, то чтобы справочники можно было размещать в родительских скоупах (одна таблица с контактами для использования везде). Плюс, облегчить создание представлений, которые являются визуальным аналогом SELECT. А то куда же это годится: хочешь выборку данных за прошлый год — создавай при помощи визарда новое представление. Плюс…
Поймите меня правильно: я не агитирую тут за ШП. Я его при помощи напильника и такой-то матери (вплоть до модификации подкапотных хранимок) заставлял через не могу выполнять достаточно простые вещи, и лучше многих знаю, что это, в общем-то, всего лишь дорогая игрушка. Но эта игрушка показывает, что РСУБД вполне можно делать вокруг UI, а не текстовых запросов в консоли. Вообще-то, это очевидно. Все остальные классы программ (операционные системы, например) с 1970-х годов давно дали юзерам UI вместо консоли. А СУБД просто перестали быть для пользователей, превратившись в модули для разработчиков.
Только не забудьте, что я написал: что WSS это не просто РСУБД, это игрушечная РСУБД. Полноценной она стала бы, если бы убрать глупые ограничения.
Но это не так. Это набор сервисов, включающих СУБД. Судя по вашим комментариям, ограничения там чисто в интерфейсе SharePoint.
Кстати, интересно, вы просто временами случайно забываете Р, или для вас нет разницы между РСУБД и СУБД? А то я не могу понять логику использования терминов.
Но эта игрушка показывает, что РСУБД вполне можно делать вокруг UI, а не текстовых запросов в консоли.
Это интерфейс делается вокруг программы, а не программа вокруг интерфейса. А так, конечно можно, только не всегда целесообразно, как я писал выше.
Букву Р я пишу, когда хочу подчеркнуть наличие справочников и какой-никакой нормализации. А когда я пишу, что ШП это СУБД, а не, допустим, CMS, буква R излишня.
Вы всё время говорите, что Шарик это не СУБД, но не уточняете, что именно. Мне кажется, это как с MFC, если помните такую штуку. Её писали как фреймворк для приложений-редакторов, но поскольку стандартной библиотеки C++ тогда не было, то соответствующие элементы были добавлены в MFC. А ещё туда добавили классов-обёрток над WinAPI. В результате, сегодня 95% программистов уверены, что MFC была обёрткой над WinAPI и заменой стандартной библиотеке. Мечтаю выпить в баре с авторами MFC и обсудить с ними «правило 95%» )))
Всё, что есть в WSS, помимо менеджмента данных — а что там есть? хоть пальцем покажите! — это такой же вспомогательный функционал для СУБД. Web parts? Архитектурно видно же что шариковые web parts отличаются от асп-дотнетных именно тем, что их затачивали как базу для контролов, управляющих таблицами. Хотя, конечно, они сохранили и весь функционал aspx. Что ещё? Это надо обсуждать предметно, на примерах.
Сейчас, в 2025-м году, вкладываться в изучение ШП я большого смысла не вижу. Но если вы такой же фанат технологий для работы с таблицами, как и я (см. мой никнейм), могу посоветовать поиграться с ним в виртуалке, создать там, например, тикет-трекер и поюзать его. И тогда будет понятно, о чём я тут талдычу. И для, так сказать, кругозора. Что бы вот такое не писать: «интерфейс делается вокруг программы, а не программа вокруг интерфейса» )) (1/2)
Букву Р я пишу, когда хочу подчеркнуть наличие справочников и какой-никакой нормализации. А когда я пишу, что ШП это СУБД, а не, допустим, CMS, буква R излишня.
Интересная логика. Но ведь реляционные БД отличаются совсем не этим. Степень нормализации никак не влияет на реляционность, не говоря уже о неких справочниках.
Вы всё время говорите, что Шарик это не СУБД, но не уточняете, что именно.
А зачем мне уточнять? Из описания на оф. сайте вроде очевидно, что это набор программ для совместной работы. CMS на стероидах, грубо говоря. А СУБД у Microsoft - это MS SQL Server.
Что бы вот такое не писать: «интерфейс делается вокруг программы, а не программа вокруг интерфейса»
А разве это не очевидно? Интерфейс - это средство взаимодействия пользователя (в данном случае) с программой. Интерфейс без программы не имеет смысла - как клавиатура с монитором без системника.
Есть обкорнатая версия ШП, с которой можно поиграться онлайн. Вот она: https://lists.live.com/
Я покажу пару скриншотов из БД воображаемого таск-трекера, который я запилил за пару минут для примера.
Вот справочник:
Вот зависимая таблица:
При её создании требуется сослаться на справочник:
Данные из справочника (см. номер телефона на первом скиншоте) подставляются сами.
Я не стал делать view, который соответствовал бы запросу номеров телефонов программистов, имеющих незакрытые тикеты, это уж, если вам интересно, попробуйте сделать сами.
Я коллекционирую такие приложения (неважно — онлайновые, оффлайновые, серверные, десктопные) и хорошо знаю, что когда речь заходит о чем-то более-менее универсальном, заканчивается всё: «Э-э-э… Ну, вот, вроде, ШП это умеет». И на этом всё. Поэтому и пишу про него как про единственного в своём роде представителя РСУБД, дающего простому пользователю вместо консольного интерфейса визуальный. И надеюсь, что вы не будете писать про MyClient и тому подобный софт, который id показывает как число, а не выпадающий список, и даёт вводить любые числа, пока при помощи сложных SQL-заклинаний вы не установите констрейнты. Надеюсь, теперь понятно. (2/2)
для этого существуют BI системы, на которые по факту тоже содют отдельного человека, отвечающего за подготовку данных и рисование дашбордов.
На кровавый ынтерпрайз мне, честно говоря, пофиг. Пусть лучше тратят деньги на BI и зарплату отдельного человека, чем на проституток для руководства.
А вот что мне искренне жаль, это что нельзя стандартными средствами из таблицы звонков в дайлере и таблицы контактов в «Контактах» сделать вьюшки с отсортированными колонками «КАк часто я звоню родственникам» и «Мои самые дорогие звонки». При этом, разумеется, не пилить их руками, а просто скачать из шаблонов. А ведь мы могли бы жить в мире, где для этого не надо писать приложение, работающее с sqlite-файлами Андроида, и искать спецификации в Android SDK.
Потом появились программисты которые тот ко этим и занимаются. Теперь появятся программисты которые будут писать запросы к ChatGPT чтобы он запрос к БД написал.
Так оно уже, есть ведь вакансии промпт-инженера
SQL ладно, его программист понять может. А вот аналогичным образом появившийся AppleScript – ужОс.
в 70х это был "человеческий" язык
Маленькое уточнение: не "был", а "задумывался как".
переход на естественный язык в работе с БД неизбежен
ЭТО ДОКАЗАЛИ ЕЩЁ В 1983 ГОДУ !
2025 – 1983 = 42, так и есть.
Это все, конечно, неизбежно, только сначала необходимо эволюционировать само хранение. Никто не ходит в БД с вопросами "посчитай выручку за месяц", где надо просто сделать суммирование с группировкой. Что это за модель такая, где возврат это просто отдельная колонка в БД? Это целый бизнес процесс с кучей побочных эффектов, и простого описания имён колонок не хватит, нужно описывать все варианты реализации бизнес-логики, которая наполняет эту модель. Буквально недавно как раз в логистике возникла задача добавления даты отгрузки в отчёт. Что может быть проще? А нет, это запись в таблице движения материалов с определенным видом движения и с определенных складов. И только для одной из нескольких схем реализации. Посмотрим на эти же прогнозы лет через 10, уже видели "self service bi".
Мы непременно придём к демократизации доступа, когда бизнес-пользователи смогут формулировать запросы на естественном языке, не погружаясь в синтаксис SQL.
Это уже есть, причём в продакшн. Посмотрите что предлагает Snowflake Cortex API:
Фичи: https://www.snowflake.com/en/product/features/cortex/
Документация: https://docs.snowflake.com/en/user-guide/snowflake-cortex/llm-functions
Во второй ссылке раскрыты вопросы перформанса и квот.
Наши Data/BI инженеры (так их принято называть) используют облачную Snowflake, которая предлагает богатый выбор встроенных LLM моделей (см вторую ссылку), при помощи которых можно извлекать данные используя промпты на человеческом языке. Им помогают специалисты с профильным образованием в области ИИ чтобы, так сказать, расширить и углу́бить, то есть максимально раскрыть потенциал.
Они пишут промпты, разбавляя их кодом на питоне (который они конечно же генерят, но сейчас не об этом), который вызывает специальный API внутри Snowflake для запуска ИИ движка, и передают ему в параметрах всякие штуки типа конкретной LLM модели, температуры (то есть степени креативности) и прочего. В результате LLM генерит SQL, опираясь на знание структуры хранилища, запускает его, извлекает данные, анализирует их в соответствии с промптом (он может быть очень длинный и хитрый) и затем питон запускает различные действия в других внешних системах, типа через REST API и т.п.
На этом основана куча автоматизации в нашей компании. Например, эта система по сути рулит отделом клиентской поддержки, назначает тикеты в жире в соответствии с умениями и доступностью сотрудников (т.е. учитывая их знания и опыт в различных прикладных сферах и технологиях, страны проживания и часовые пояса, отгулы и отпуска и т.п.), отвечает там же клиентам, ищет связанные тикеты и похожие кейсы, прикрепляет полезные ссылки на Confluence, пишет письма и прочее. Топ-менеджеры светятся от счастья! Есть и много других примеров, о которых я не могу рассказывать. Все это конечно же самописное, аналоговнетное.
Всех сотрудников компании настоятельно просят использовать ИИ где это только возможно, и предлагать новые области автоматизации.
Пока что опыт с LLM + SQL у меня такой:
даешь запрос + результат explain analyze - дает советы по оптимизации. Иногда дельные, но и в целом без ерунды.
просишь написать что-то сложное - тупит безбожно. Просьба написать миграцию полей JSON для MySQL меня прям вымотала. Приходится детально описывать свою хотелку на естественном языке. Очень быстро приходишь к мысли: зачем я занимаюсь этой галиматьей, если есть SQL.
Можно бесконечно сравнивать бенчмарки по олимпиадным задачам и писать визионерский булшит на хабре, но решения этого простого вопроса не видно. Даже если нейроинтрефейс прямо в башку запилить. Тогда придется не писать, но думать о запросе в мельчайших деталях. И снова: зачем мне это думать, если есть SQL?
Если LLM подкинуть правильный контекст (в разработке = существующий код), то это радикально режет нужду в разжёвывании. Контекст говорит сам за себя. И тогда LLM ускоряет на не сложных задачах. LLM без контекста — гадания на кофейной гуще, с ним — логичное быстрое продолжение (автодополнение) вашей мысли.
Ну класс, теперь мне как русскоговорящему и SQL-пишущему еще и русский SQL учить придется...
Неформальный естественный язык в формальной среде неизменно должен обрести формальные признаки, присущие этой среде, породив новый язык/диалект языка.
Вот что странно. Когда программистам понадобилось писать сложные программы, они кроме ассемблера изобрели С, fortran и python. А для обработки данных в таблицах ничего вкуснее SQL не изобрели.
Так вот, идея генерировать sql с помощью ИИ - это всё равно что генерировать байт-код прямо из описания задачи
Если кверять не исходные базы, а семантический слой с нормальными метаданными, можно закрыть приличную часть потребностей бизнеса. А поскольку в стандартном варианте у многих для общения с бд и так используется llm, которая называется 'аналитик', выгоду довольно легко рассчитать.
Интересное, по моему опыту, начинается, когда сам запрос уже должен содержать какие-то данные, например, чтобы отфильтровать результаты. А в компании используют надцать псевдонимов для одной сущности. Например один магазин называют кодами разных подразделений, по адресу, по фамилии менеджера и хз как ещё.
Другой пример: когда реальные сущности не могут быть однозначно классифицированы используя существующую структуру бд: посчитай, сколько в магазине продаётся жидкостей. И в базе нет поля is_liquid. Это могут быть разные категории, а то и отдельные товары в рамках какой-то категории.
Во всех статьях и презентациях решений nl-->sql такого рода запросы обходятся стороной. Если кто-то сталкивался, было бы интересно узнать, как решали.
наш подход к генерации SQL в ответ на вопросы пользователя на естественном языке.
А как будет решена проблема SQL инъекций , намеренной или случайной порчи данный , разграничения доступа к данным ?
Прежде чем выполнить запрос к БД, я изучаю план запроса, чтобы он не ушел ненароком в сканирование терабайтной таблицы или не выдал в результате миллиард строк. Подразумевается, что этим будет заниматься AI? Но как он тогда объяснит пользователю, что не так в его запросе? Вывалит код на SQL с планом запроса? И что с ним будет делать пользователь без знания SQL?
ИИ должен проверять план запроса. Если план запроса плох и ИИ ничего не может сделать, выдаются варианты оптимизации, в том числе по оптимизации таблиц+подключается отдел производительности.
Если план запроса плох
Что значит "плох"? Плохо или хорошо зависит от задачи и пожеланий пользователя. AI что ли пользователю на каждый запрос должен допрос с пристрастием устраивать, чтобы выяснить, что для него плохо, а что хорошо?
И о каком плане идет речь? О предполагаемом или примененном (EXPLAIN или EXPLIN ANALYZE)? Если первом - то нужно понимать, как он может измениться при реальном выполнении запроса. Если втором, так в некоторых случаях его можно и сутки дожидаться.
выдаются варианты оптимизации
И какие варианты оптимизации можно выдать пользователю не знакомому с SQL?
Обновить статистики? Даже простейший SET enable_seqscan=off; нужно применять с умом, который AI пока не доступен.
Я уже молчу, что тот же ChatGPT предлагает включить в условие JOIN ключ партиционирования только после явного указания, что без этого запрос будет неэффективен. На индексы, которые он предлагает создать - вообще без слёз не взглянешь. А уж заставить его одним запросом обновить или вставить более одной таблицы мне вообще не удалось.
Вы вообще оптимизацией SQL запросов занимались?
Что значит "плох"? Плохо или хорошо зависит от задачи и пожеланий пользователя. AI что ли пользователю на каждый запрос должен допрос с пристрастием устраивать, чтобы выяснить, что для него плохо, а что хорошо?
Да, ИИ должен устраивать допрос с пристрастием и предлагать варианты. Сейчас большой минус ИИ в том, что он додумывает за пользователя (если не использовать специальные промпты). Он может отметить, что было бы неплохо индексов вот туда добавить и тогда запрос работал бы шустрее. И проверить, не помешает ли это остальным запросам, работающим с этой таблицей.
Если первом - то нужно понимать, как он может измениться при реальном выполнении запроса. Если втором, так в некоторых случаях его можно и сутки дожидаться.
Значит ИИ будет мониторить, дожидаться реального выполнения, выдавать рекомендации.
Я уже молчу, что тот же ChatGPT предлагает включить в условие JOIN ключ партиционирования только после явного указания, что без этого запрос будет неэффективен. На индексы, которые он предлагает создать - вообще без слёз не взглянешь. А уж заставить его одним запросом обновить или вставить более одной таблицы мне вообще не удалось.
А 5 лет назад мы смеялись, что ИИ пальцы не умеет рисовать. Вопрос только в обучающих выборках и в датасете решенных кейсов, правильно размеченных.
Он может отметить, что было бы неплохо индексов вот туда добавить и тогда запрос работал бы шустрее.
И проверить, не помешает ли это остальным запросам, работающим с этой таблицей.
Как бот это проверит , не имея результатов нагрузочного тестирования и статистических данных анализа производительности при продуктивной нагрузке ?
Вопрос только в обучающих выборках
В этом то и состоит главная проблема - нет обучающих выборок для обучения . Все данные в интернете - грязные.
Как бот это проверит , не имея результатов нагрузочного тестирования и статистических данных анализа производительности при продуктивной нагрузке ?
А как люди это делают? Да, нужен пайплайн в который это будет включено.
В этом то и состоит главная проблема - нет обучающих выборок для обучения . Все данные в интернете - грязные.
Я думаю статистических данных и решённых кейсов у Оракла во внутренней базе знаний более чем достаточно, поэтому специализированный продукт должен выйти сильно лучше чем ChatGPT/Grok.
А как люди это делают?
Кто как. Как правило никто не делает, не анализирует и не проверяет. Просто создают индексы.
Потому, что как правило - нет инструментов для статистического анализа производительности СУБД да и вообще с PosgreSQL performance engineering пока не густо.
Да, нужен пайплайн в который это будет включено.
"Это" - что ? Что вы под этим подразумеваете ?
Я думаю статистических данных и решённых кейсов у Оракла
А при чем тут Оракл ?
Как бот это проверит , не имея результатов нагрузочного тестирования и статистических данных анализа производительности при продуктивной нагрузке ?
Кто как. Как правило никто не делает, не анализирует и не проверяет. Просто создают индексы.
Ну значит ничего особенно не изменится, просто так же создаст индексы. На самом деле думаю что у специализированного ИИ "знаний" по части работы с БД будет в среднем побольше, чем у среднего аналитика. Хотя бы потому, что ИИ сможет проанализировать и обобщить больше знаний о процессах в БД. Аналитику на блюдечке могут принести то, что ему пришлось бы спрашивать у дба и у управления производительности.
А при чем тут Оракл ?
В начале статьи упоминается что они создали ИИ инструмент для создания запросов. Ну пусть не Оракл, а другая бд у них тоже база знаний приличная должна скопиться.
"Это" - что ? Что вы под этим подразумеваете ?
Подразумевается, что в пайплайн будет включено нагрузочное тестирование и проанализировано в дальнейшем.
Ну значит ничего особенно не изменится, просто так же создаст индексы
Ну тут уж как повезет. Либо ничего не измениться, либо просадит производительности СУБД в целом .
управления производительности.
Уже в который раз встречаю это словосочетание "отдел производительности" , "управление производительности". что действительно такие бывают ? Кто и за что им интересно деньги платит? как они анализируют производительность СУБД не имея инструментов и методологии.
в пайплайн будет включено нагрузочное тестирование
Это не реально.
1) Это долго
2) требует анализа и расчетов и интерпретации результатов
Да, ИИ должен устраивать допрос с пристрастием и предлагать варианты.
Но тогда он и нужен будет только людям с Вашим менталитетом, желающим отвечать на кучу вопросов AI, вместо того, чтобы сразу получить нужный результат запроса.
дожидаться реального выполнения
А пользователь будет сутками ждать, например, результата умножения одной терабайтной таблицы на другую?
А 5 лет назад мы смеялись, что ИИ пальцы не умеет рисовать. Вопрос только в обучающих выборках и в датасете решенных кейсов, правильно размеченных.
То есть Вы утверждаете, что проблема с пальцами решаема только обучающими выборками, и не требует совершенно других на порядки более сложых обучаемых математических моделей с пространственным, а не плоским представлением объектов? Можете это доказать?
Почему Вы не ответили на прямо заданный вопрос? "Вы вообще оптимизацией SQL запросов занимались?"
Но тогда он и нужен будет только людям с Вашим менталитетом, желающим отвечать на кучу вопросов AI, вместо того, чтобы сразу получить нужный результат запроса.
Когда пользователь приходит к разработчику с невнятным ТЗ - тот задаёт уточняющие вопросы и это абсолютно нормально.
Про "Ваш менталитет" кекнул.
А пользователь будет сутками ждать, например, результата умножения одной терабайтной таблицы на другую?
НУ а как человек это решает? Возможно в начале ИИ протестирует умножение на небольших таблицах, прикинет время и предоставит решение пользователю - в зависимости от выбранных политик (в какой-то компании могут запретить запросы, съедающие много ресурсов). Возможно выдаст отчёт управлению производительности, чтобы разобрались уже вручную.
То есть Вы утверждаете, что проблема с пальцами решаема только обучающими выборками, и не требует совершенно других на порядки более сложых обучаемых математических моделей с пространственным, а не плоским представлением объектов? Можете это доказать?
Я утверждаю, что ИИ очень сильно "поумнели" за последние пару лет и что у Оракла есть достаточно обширная база знаний для обучения ИИ.
Почему Вы не ответили на прямо заданный вопрос? "Вы вообще оптимизацией SQL запросов занимались?"
А зачем мне отвечать на разновидность ad hominem? Он манипулятивный и направлен на разрушение авторитета и на то, чтобы ослабить мои аргументы. В первый раз я сделал вид, что его не услышал, чтобы не ставить вас не удобное положение. У вас похоже большой опыт в оптимизации, вы бы могли и без использования манипулятивных приёмов победить. Для чего вы это делаете?
Когда пользователь приходит к разработчику с невнятным ТЗ - тот задаёт уточняющие вопросы и это абсолютно нормально.
А при чём тут ТЗ? Аналитик при написании ТЗ делает, нередко, сотни SQL запросов. Ради интереса посмотрел на количество запросов аналитика по текущему обсуждаемому ТЗ. Получилось уже свыше шести сотен. К релизу тысяча явно будет. А моя помощь в написании этих запросов ему потребовалась пару раз от силы.
Про "Ваш менталитет" кекнул.
Посмотрел лог DBEaver. За сегодня с утра я сделал уже 142 SQL запроса к БД. Если бы на каждый запрос мне пришлось бы еще отвечать на вопросы AI, то я бы и два десятка запросов не успел сделать. Так что Ваше предложение я еще очень вежливо назвал менталитетом.
НУ а как человек это решает?
Про оптимизацию SQL запросов написаны целые книги, рефераты и диссертации. Причем ни на одних курсах Вас этому не научат. Нужны еще годы опыта. А Вы хотите, чтобы я в комментарии ответил на этот вопрос?
Я утверждаю, что ИИ очень сильно "поумнели" за последние пару лет.
Это совершенно не доказывает, что проблему с пальцами можно решить без перехода на пространственное представление объектов в математической модели - применения совершенно другой, на порядки более сложной математической модели.
у Оракла есть достаточно обширная база знаний для обучения ИИ
А при чем тут Oracle? Нередко запрос, эффективно выполняющийся на Oracle, окажется совершенно неэффективным или даже невыполнимым без полного переписывания на PostgreSQL или MS SQL. И без понимания технических особенностей СУБД такой запрос можно будет оптимизировать бесконечно с неизвестным результатом.
К тому же непонятно, о какой базе знаний идет речь, так как способы оптимизации SQL запросов очень сильно зависят от целей, инфраструктуры и задачи. Для примера, часто seqscan эффективней indexscan, но убедиться в этом можно только профилированием и нагрузочным тестированием.
А зачем мне отвечать на разновидность ad hominem?
Потому что в случае положительного ответа на этот вопрос я бы мог опровергнуть Ваши рассуждения Вашим же опытом. А в случае отрицательного ответа - не вижу смысла в дальнейшей дискуссии, так как объем информации, который потребуется изложить выходит за рамки не только комментария, но даже статьи.
А при чём тут ТЗ? Аналитик при написании ТЗ делает, нередко, сотни SQL запросов. Ради интереса посмотрел на количество запросов аналитика по текущему обсуждаемому ТЗ. Получилось уже свыше шести сотен. К релизу тысяча явно будет. А моя помощь в написании этих запросов ему потребовалась пару раз от силы.
Аналитик делает много запросов, а потом из этих знаний формируется финальный запрос, порой в несколько сотен строк. Вот на такой запрос и нужно ТЗ. А вот если оно не полное, то ИИ должна задавать уточняющие вопросы.
Посмотрел лог DBEaver. За сегодня с утра я сделал уже 142 SQL запроса к БД. Если бы на каждый запрос мне пришлось бы еще отвечать на вопросы AI, то я бы и два десятка запросов не успел сделать. Так что Ваше предложение я еще очень вежливо назвал менталитетом.
Это слабый аргумент. Если мне нужно вкрутить всего один шуруп, я могу воспользоваться отвёрткой, а не лезть в чулан за шуруповёртом. Если нужен простой селект и уже известна структура и где какие лежат данные, то быстрей написать самому.
Если человек первый раз видит данные, то он гораздо дольше будет вникать в структуру и связи. Если у ИИ будет хороший контекст из метаданных и структуры, то она должна сильно облегчить работу аналитиков и производительность может увеличиться в разы.
Я уже не говорю о том, что анализ и рефакторинг уже существующих скриптов, которые работают с доисторических времён могут значительно увеличить производительность.
А при чем тут Oracle? Нередко запрос, эффективно выполняющийся на Oracle, окажется совершенно неэффективным или даже невыполнимым без полного переписывания на PostgreSQL или MS SQL. И без понимания технических особенностей СУБД такой запрос можно будет оптимизировать бесконечно с неизвестным результатом.
При том, что в самом начале статьи упоминается "Oracle разработала APEX AI Assistant, который в интерактивном формате генерирует и выполняет SQL-запросы".
Для примера, часто seqscan эффективней indexscan, но убедиться в этом можно только профилированием и нагрузочным тестированием.
И что меняет и показывает этот пример, и для чего он здесь? Машина точно так же может профилировать и тестировать. Собственно, уже в куче мест она этим довольно успешно занимается.
Вот на такой запрос и нужно ТЗ. А вот если оно не полное, то ИИ должна задавать уточняющие вопросы.
Вы занялись откровенной подменой темы. ТЗ пишется не на запрос, а на разработку приложения, в котором этих запросов может быть сотни, а кроме этих запросов - еще куча логики на фронте и беке.
И до анализа такого ТЗ AI, при его текущем развитии, еще очень и очень далеко.
Если нужен простой селект
Вот только простые SELECT мне очень редко нужны )))
Если у ИИ будет хороший контекст из метаданных и структуры
Ключевое слово "если". Вот только почерпнуть этот контекст можно только либо изучая документацию проекта, либо анализируя код, как минимум, CONSTRAINT триггеров (предположим, что в коде нет ошибок). Что AI опять таки пока недоступно.
Я уже не говорю о том, что анализ и рефакторинг уже существующих скриптов, которые работают с доисторических времён могут значительно увеличить производительность.
С этим никто не спорит. Но AI чем тут может помочь? Человек, изучив бизнес требования и постановку может понять, что из миллионов возможных суперпозиций в данной задачи допустимы лишь десятки. Но как это поймет AI?
в интерактивном формате генерирует и выполняет SQL-запросы".
Но я же веду речь не о генерации, а об оптимизации. Не видите разницу?
Машина точно так же может профилировать и тестировать.
Вы серьёзно? Имеющиеся программные средства упрощают профилирование и тестирование, но уж никак не могут заменить в этом человека. И вряд ли смогут в обозримом будущем. Хотя бы потому что анализ профилирования и тестирования непосредственно связан с неполными или даже противоречивыми бизнес требованиями заказчика.
Если, очень упрощенно, считать оптимизацию запроса учетом сотни факторов, каждый из которых может принимать значение истина или ложь, то речь идет о выборе из 10Е30 вариантов. Именно поэтому, до сих пор ни у Oracle, ни у какой-либо иной РСУБД встроенный оптимизатор не в состоянии формировать действительно оптимальный план запроса. Вот когда AI дорастет до такого уровня, что сможет хотя бы для готового SQL запроса формировать всегда оптимальный план выполнения, вот только тогда можно будет всерьёз говорить уже о более сложной задаче - формировании самого SQL запроса AI.
На данный момент, я, для примера, наблюдаю, что еще ни одна нейронная сеть, которую мы пытались применить, не смогла даже в 80% случаев выиграть в кросс-валидации у SARFIMA при прогнозировании временных рядов. Впрочем, это такая ситуация далеко не только у меня. Например, тут LSTM с треском проигрывает даже ARIMA.
В этой сфере весьма показательно, насколько существующие сейчас технологии AI несовершенны и как часто даже наиболее продвинутые модели допускают ошибки. Я уже молчу о переученных моделях, определить которые весьма не просто.
Попробую аккуратней задать вопрос, исключительно, чтобы понять, стоит ли продолжать эту дискуссию. Какие проекты с разработкой или хотя бы обучением нейронных сетей у Вас есть в портфолио?
SQL не является моей основной специализацией поэтому я уже делаю почти так же. Сначала говорю нейронке структуру базы, а потом что надо найти. Получаю почти всегда правильный SQL и иногда немного его правлю. Имхо, так и будет работать, вряд ли в бэкенд приложение будут вставлять непредсказуемый запрос на русском, вместо отлаженного надёжного SQL.
Получаю почти всегда правильный SQL.
В этом и есть главная проблема: нет никакой гарантии правильности полученного результата. Даже если синтаксически запрос будет верный, кто поручится, что он выполняет именно то что вам надо? А если на кону DELETE или UPDATE, тоже нейроночке доверим?
Получается, что пользователь сего чуда всё равно должен быть докой в SQL, чтобы быть способным на лету верифицировать результат. Но тогда ему проще самому написать что требуется, чем городить промпты и потом до посинения дебажить результат.
Тут люди, в системе, сделанной людьми, по пять лет ищут косячное преобразование типов, которое убивает 500% производительности.
А если это всё будет генерить галлюцинирующая БЯМ, то там просто будет гроб, гроб, кладбище...
ИМХО кажется, что проблема не в написании SQL запроса (знании языка), а в том что БД не всегда корректно выполняет этот запрос. Но почему-то в направлении улучшения планировщика БД работы идут гораздо хуже, вместо этого люди страдают какой-то фигней и прикручивают LLM.
Хм, звучит немного странно. По большому счету, SQL и так почти естественный язык, где говорится "Отдай мне из таблиц таких то данные такие то".
Обычно, в развивающихся системах сотни и тысячи таблиц, различные костыльчики и т.д. и т.п.
В том и отличие программиста от бизнес заказчика, что он обо всех этих табличках знает и переводи в нормальный SQL с общих слов, когда заказчик сам до конца не знает, что ему толком надо и что надо учесть.
Мне кажется, что LLM смогут писать нормальный SQL только когда заказчики смогут его нормально описать другими словами, а они как раз и не могут.
С хорошими метаданными я такое ещё в 2018 делал на intent + NER, LLM ещё не было. Просто большой SQL-builder получился, и работал без проскальзываний, в синтаксисе уж точно. А join'ы делались кратчайшим путем в графе таблиц, без всяких пришлёпок.
Вопрос вполне естественный, ответ диаграммой.
LLM только очень большая будет неплохим SQL-билдером. Но в целом вся движуха мне по душе, очень давно жду.
Кто хочет попробовать RAG в этой задаче, посмотрите vanna.ai. Сам не пробовал, но выглядит рабочей штукой. Но и там все упирается в хорошую мету.
Все пишут а зачем писать промт на русском, когда проще на sql. Но для меня это как ответить на вопрос а для чего придумали sql когда есть бинарный код.
Это упрощает порог вхождения и позволит пользователям генерить простые запросы которые составляют большую долю, а для сложных задач останутся спецы.
В целом это неизбежность, это как промышленная революция 19-18 века, пытайтесь противостоять, можете отрицать можете найти кучу причин, почему она должна проволиться и что это пузырь, но она это будущее и оно неизбежно.
Вот простой пример извращённых потребностей бизнеса :
Отчёт Заявлено - Отгружено что может быть проще (сегодня заказы, завтра с полуночи отгрузки, в отгрузке есть номер заказа)
Выбираем заказы за вчера и отгрузки за сегодня вот вам отчёт.
Торговый отдел - огонь.
Склад - тут всё неправильно, мы этим отчёт пытаемся оценивать работу кладовщиков, а в отчёте показываться как недогрузы позиции которых вообще небыло на складе, уберите их.
Торговый отдел - что за фигня почему часть позиций исчезла из отчёта, они нам нужны для оценки работы торговых, они же "продали" эти товары клиенту, а в том что их нет на складе виноват логист.
Логист - да как вы меня з...ли, отчёт неверный надо сделать по другому.
Фирменная розница - мы заказываем и отгружаем в один день, а не на следующий, всё надо переделать.
З.Ы. после 5 итераций доработок появляется 5 разных отчётов Заявлено - Отгружено для разных отделов.
В целом, здесь проявляется основное когнитивное искажение любителей коннективистского подхода – подмена семантики синтаксисом.
Запросы к реляционным базам данных пишутся на языке SQL не потому, что глупые программисты не в состоянии были разобрать их на русском, а потому, что язык SQL соответствует семантическому домену описания операций над данными средствами реляционной алгебры. Можно формулировать реляционные операции хоть на суахили, но они останутся теми же самими SELECT, INSERT, UPDATE, DELETE, потому что таков семантический домен, то есть так устроена реляционная база данных. И ничего другого, кроме реляционных операций, в её семантике нет. Оттого, что вы напишете в запросе русским языком: "Рэп – кал", "Функция h : G → H является гомоморфизмом группы, если из a ∗ b = c следует h(a) ⋅ h(b) = h(c)" или "Факт хозяйственной жизни — сделка, событие, операция, которые оказывают или способны оказать влияние на финансовое положение экономического субъекта, финансовый результат его деятельности и (или) движение денежных средств", у исполнителя не появится никакой новой информации, которую можно интерпретировать в семантическом домене доступа к данным.
Поэтому надеяться, что умная машина решит вам какую-то задачу, которая даже не имеет постановки в категориях семантического домена – это просто шаманизм в худшем смысле этого слова. Вы сделайте сначала базу данных, которая будет хранить данные по принципу мозга человека, а тогда уж к ней сам собой и будет подходить интерфейс в виде языка человека. И никакая LLM при этом будет не нужна.
Одни уже изначально решили использовать Русский язык как основной (не будем называть продукт, его и так все знают), и это изначально привело к значительному снижению порога вхождения, и фактически в профессию идут люди очень слабо знающие материальную базу и в основном своем не желающие развиваться в параллельных областях. И как следствие качество кода из года в год падает, хуже код -> больше ресурсов, больше ресурсов -> больше затрат как на аппаратную часть так и на поддержку сервисов.
А теперь представьте, текст запроса в анализаторе запросов на русском языке и еще написанный во всем известном продукте.
SQL выражает точные пожелания, а LLM - примерные. И на выходе вы всегда будете получать примерно то что надо, а не то что вам надо. Нафига козе баян? Чтобы пришло 100500 левых людей с магическим мышлением и завалили базу левыми запросами, а потом завопили, что результат не тот?
Через год мы будем общаться с базами данных на матерном русском.
Уже через год мы будем общаться с базами данных по-русски