MCP это внешний способ извлечения данных (просто какая-то сторонняя логика, никак не связанная с моделью), а тут речь как бы о внутреннем (по отношению к модели) способе.
Я не писал ни про "ежедневно" ни про "под нагрузкой", я лишь имел в виду, что если какая-то система живет и эволюционирует (меняется структура базы и т.д.), то как правило эти изменения структуры надо накатывать на рабочие базы (в момент "апгрейда версий системы", а уж ежедневно или не ежедневно - это смотря как часто происходят такие апгрейды). Просто для меня из статьи было не понятно, зачем вообще менять структуру базы, если это не "продакшен база" с энным количеством рабочих данных. Так бы и писали тогда "механизм предназначен для синхронизации изменений схемы базы между несколькими разработчиками в процессе разработки системы до ввода её в практическую эксплуатацию". Я не то чтобы жалуюсь, просто описанное сильно отличается от моих use case'ов работы с продакшен базами.
Еще такой момент, в статье описывается миграция структуры базы, но так, как будто это пустая база, без данных. Что как правило нереально. В реальности при миграции структуры самое сложное - это что делать со старыми данными - куда их переливать, как конвертировать (если меняется тип/формат колонки) и т.д., а в описанной схеме про данные вообще ни слова.
Если скрипт изменений генерит LLM, значит он может быть косячный (содержать не все изменения, просто быть некорректным, упоминать какие-то несуществующие таблицы/столбцы и т.д.) Правильно понимаю, что проверка итогового скрипта производится уже вручную человеком? Если да, то в чем суть этой проверки, попытка выполнить весь скрипт целиком в транзакции, а если ошибки - то откат и ручное разгребание уже по шагам?
Если скрипт изменения строит сама эта система, я не до конца понял, что находится в первичном коммите от человека, как описано изменение базы, чтобы на его основе система начала строить скрипт разницы с другими схемами?
А может автор сам тупой. Извините, не сдержался. Да, на карте осадков есть режим показа давления и прочей ерунды, но беглый взгляд на картинку не выявил ничего сверхъестественного (для не жителя Питера по крайней мере).
Это другая крайность. Всё-таки миллиард (или сколько их там) персональных компьютеров в мире выполняет (пока ещё) "классические" программы, не связанные с ИИ, которым, слава богу, хватает типичного/обычного набора железа.
Описание про возможность выполнить фрагмент кода - какое-то бредовое, т.к. чтобы в сложной системе что-то выполнять, система сначала должна построить с памяти сложный набор структур данных (композицию классов и т.п.) и вся эта сложная структура уже потом позволяет выполнять определенные "расчеты" над некоторыми данными. А если вызвать только "середину кода" без сотен тысяч строк подготовки, о чем может идти речь, о каком понимании, как эта середина должна сработать. Автор либо совсем новичок (не имел дела со сложными системами), либо просто фантазер в розовых очках.
MCP это внешний способ извлечения данных (просто какая-то сторонняя логика, никак не связанная с моделью), а тут речь как бы о внутреннем (по отношению к модели) способе.
ИИ на основе N-грамм рисовал :-D
Ты бы хоть погуглил перед тем как писать. Виза и мастер кард российских банков эмитентов сейчас работают через процессинг НСПК.
Я не писал ни про "ежедневно" ни про "под нагрузкой", я лишь имел в виду, что если какая-то система живет и эволюционирует (меняется структура базы и т.д.), то как правило эти изменения структуры надо накатывать на рабочие базы (в момент "апгрейда версий системы", а уж ежедневно или не ежедневно - это смотря как часто происходят такие апгрейды). Просто для меня из статьи было не понятно, зачем вообще менять структуру базы, если это не "продакшен база" с энным количеством рабочих данных. Так бы и писали тогда "механизм предназначен для синхронизации изменений схемы базы между несколькими разработчиками в процессе разработки системы до ввода её в практическую эксплуатацию". Я не то чтобы жалуюсь, просто описанное сильно отличается от моих use case'ов работы с продакшен базами.
Еще такой момент, в статье описывается миграция структуры базы, но так, как будто это пустая база, без данных. Что как правило нереально. В реальности при миграции структуры самое сложное - это что делать со старыми данными - куда их переливать, как конвертировать (если меняется тип/формат колонки) и т.д., а в описанной схеме про данные вообще ни слова.
Если скрипт изменений генерит LLM, значит он может быть косячный (содержать не все изменения, просто быть некорректным, упоминать какие-то несуществующие таблицы/столбцы и т.д.) Правильно понимаю, что проверка итогового скрипта производится уже вручную человеком? Если да, то в чем суть этой проверки, попытка выполнить весь скрипт целиком в транзакции, а если ошибки - то откат и ручное разгребание уже по шагам?
Спасибо за пояснение. Из статьи это было совершенно неочевидно :)
Стало чуть понятнее, но всё равно не до конца.
objects/dbo/Procedures/GetReport.sql
Вот этот файл откуда взялся? В систему контроля версий изначально выложен скрипт всех объектов базы?
Если скрипт изменения строит сама эта система, я не до конца понял, что находится в первичном коммите от человека, как описано изменение базы, чтобы на его основе система начала строить скрипт разницы с другими схемами?
Не знаю насколько deep, но в OpenWebUI есть готовый реализованный RAG по базам документации.
https://github.com/open-webui/open-webui
А может автор сам тупой. Извините, не сдержался. Да, на карте осадков есть режим показа давления и прочей ерунды, но беглый взгляд на картинку не выявил ничего сверхъестественного (для не жителя Питера по крайней мере).
Есть ли информация, какие open source продукты яндекса наиболее популярны вне Яндекса? (в продакшен средах других компаний)
Спасибо за ответ!
А сам claude code что из себя представляет ? Это локальная программа или что?
Это другая крайность. Всё-таки миллиард (или сколько их там) персональных компьютеров в мире выполняет (пока ещё) "классические" программы, не связанные с ИИ, которым, слава богу, хватает типичного/обычного набора железа.
Странный вопрос. Если вы уже являетесь MS SQL DBA, то конечно вам будет проще освоить Postgres, т.к. и то, и другое - СУБД )
Ещё бы пунктуацию подтянуть, а то нет запятых там, где они должны быть, и есть там, где их быть не должно.
Описание про возможность выполнить фрагмент кода - какое-то бредовое, т.к. чтобы в сложной системе что-то выполнять, система сначала должна построить с памяти сложный набор структур данных (композицию классов и т.п.) и вся эта сложная структура уже потом позволяет выполнять определенные "расчеты" над некоторыми данными. А если вызвать только "середину кода" без сотен тысяч строк подготовки, о чем может идти речь, о каком понимании, как эта середина должна сработать. Автор либо совсем новичок (не имел дела со сложными системами), либо просто фантазер в розовых очках.
Наконец-то хоть один нормальный комментатор.
Жаль, что Пэк Джин-он не читает Хабр ))