Вроде на прошлой неделе как раз была статья про переход на YDB ? Или это касалось не такси? Если всё-таки такси, то очередность статей не очень понятная - сначала написали, что отказались от Postgre в пользу YDB, а теперь описываете, как всё устроено на Postgre.
UPDATE: а, ой, это Хабр мне подсунул старую статью! А я решил, что она сегодняшняя, каюсь!
Им сама НВидия и даёт в долг )) Нвидия при этом в шоколаде , им теперь все будут много лет должны, даже если ускорители станут не нужны в будущем. Гениальные менеджеры
MCP это внешний способ извлечения данных (просто какая-то сторонняя логика, никак не связанная с моделью), а тут речь как бы о внутреннем (по отношению к модели) способе.
Я не писал ни про "ежедневно" ни про "под нагрузкой", я лишь имел в виду, что если какая-то система живет и эволюционирует (меняется структура базы и т.д.), то как правило эти изменения структуры надо накатывать на рабочие базы (в момент "апгрейда версий системы", а уж ежедневно или не ежедневно - это смотря как часто происходят такие апгрейды). Просто для меня из статьи было не понятно, зачем вообще менять структуру базы, если это не "продакшен база" с энным количеством рабочих данных. Так бы и писали тогда "механизм предназначен для синхронизации изменений схемы базы между несколькими разработчиками в процессе разработки системы до ввода её в практическую эксплуатацию". Я не то чтобы жалуюсь, просто описанное сильно отличается от моих use case'ов работы с продакшен базами.
Еще такой момент, в статье описывается миграция структуры базы, но так, как будто это пустая база, без данных. Что как правило нереально. В реальности при миграции структуры самое сложное - это что делать со старыми данными - куда их переливать, как конвертировать (если меняется тип/формат колонки) и т.д., а в описанной схеме про данные вообще ни слова.
Если скрипт изменений генерит LLM, значит он может быть косячный (содержать не все изменения, просто быть некорректным, упоминать какие-то несуществующие таблицы/столбцы и т.д.) Правильно понимаю, что проверка итогового скрипта производится уже вручную человеком? Если да, то в чем суть этой проверки, попытка выполнить весь скрипт целиком в транзакции, а если ошибки - то откат и ручное разгребание уже по шагам?
Понял :)
Подпись под фото лучше обрезать или переписать, чтобы она не вводила в заблуждение
Step 3.5 и Mimo V2 ещё. И qwen 3.6
Поскольку 90+ процентов обычных людей не знакомы с этим языком, достаточно было бы обзорной статьи с простыми примерами.
C/2026 A1 (MAPS) 4 апреля упадёт на солнце, а t короны по прежнему стабильна
https://github.com/teorth/erdosproblems/wiki/AI-contributions-to-Erdős-problems
https://habr.com/ru/articles/994934/
Вроде на прошлой неделе как раз была статья про переход на YDB ? Или это касалось не такси? Если всё-таки такси, то очередность статей не очень понятная - сначала написали, что отказались от Postgre в пользу YDB, а теперь описываете, как всё устроено на Postgre.
UPDATE: а, ой, это Хабр мне подсунул старую статью! А я решил, что она сегодняшняя, каюсь!
Мощь )
Так вроде в статье ничего не было про добавление кода в ванильный постгрес, статья-то не про Postgres, а про Pangolin
Им сама НВидия и даёт в долг )) Нвидия при этом в шоколаде , им теперь все будут много лет должны, даже если ускорители станут не нужны в будущем. Гениальные менеджеры
Хабр тот, но он не торт )
MCP это внешний способ извлечения данных (просто какая-то сторонняя логика, никак не связанная с моделью), а тут речь как бы о внутреннем (по отношению к модели) способе.
ИИ на основе N-грамм рисовал :-D
Ты бы хоть погуглил перед тем как писать. Виза и мастер кард российских банков эмитентов сейчас работают через процессинг НСПК.
Я не писал ни про "ежедневно" ни про "под нагрузкой", я лишь имел в виду, что если какая-то система живет и эволюционирует (меняется структура базы и т.д.), то как правило эти изменения структуры надо накатывать на рабочие базы (в момент "апгрейда версий системы", а уж ежедневно или не ежедневно - это смотря как часто происходят такие апгрейды). Просто для меня из статьи было не понятно, зачем вообще менять структуру базы, если это не "продакшен база" с энным количеством рабочих данных. Так бы и писали тогда "механизм предназначен для синхронизации изменений схемы базы между несколькими разработчиками в процессе разработки системы до ввода её в практическую эксплуатацию". Я не то чтобы жалуюсь, просто описанное сильно отличается от моих use case'ов работы с продакшен базами.
Еще такой момент, в статье описывается миграция структуры базы, но так, как будто это пустая база, без данных. Что как правило нереально. В реальности при миграции структуры самое сложное - это что делать со старыми данными - куда их переливать, как конвертировать (если меняется тип/формат колонки) и т.д., а в описанной схеме про данные вообще ни слова.
Если скрипт изменений генерит LLM, значит он может быть косячный (содержать не все изменения, просто быть некорректным, упоминать какие-то несуществующие таблицы/столбцы и т.д.) Правильно понимаю, что проверка итогового скрипта производится уже вручную человеком? Если да, то в чем суть этой проверки, попытка выполнить весь скрипт целиком в транзакции, а если ошибки - то откат и ручное разгребание уже по шагам?
Спасибо за пояснение. Из статьи это было совершенно неочевидно :)
Стало чуть понятнее, но всё равно не до конца.
objects/dbo/Procedures/GetReport.sql
Вот этот файл откуда взялся? В систему контроля версий изначально выложен скрипт всех объектов базы?