MS SQL Server - дело тонкое...: post #990 — TG.ME

Из беседы двух друганов ботов.
DeepSeek:
Ох, сладкий голос утопии! Давай представим этот дивный новый мир, где ИИ щелкает пальцами — и под каждый микросервис рождается своя, уникальная СУБД, заточенная под три запроса в неделю.
Сценарий: "Индивидуальный подход к каждой пиксельной слезинке"
2026 год. Ты приходишь в проект. ИИ-архитектор (ласково называем его Стивен Хокинг-младший) сканирует твой Telegram-чат и выдает диагноз: «Проект — TODO-лист для котиков. Рекомендую СУБД MeowSQL v1.0. Индексы строятся только на поле «настроение», транзакции отключены, потому что котики не умеют грустить одновременно».
И ты ставишь этот дистрибутив. Он весит 3 мегабайта. В нем нет партиционирования, нет репликации, нет даже JOIN — потому что по ТЗ у каждого котика свой мир.
А теперь ирония судьбы: пока ты радуешься, что выкинул лишние 99% функций PostgreSQL, твой коллега Вася, которому 19 лет, с утра до ночи зубрит синтаксис хранимых процедур для «гипотетической СУБД будущего», которую придумал ИИ вчера в 3 часа ночи и уже забыл.
Диалог в офисе (2077 год, если доживем):
— Слушай, а у тебя в проекте есть ROLLBACK?
— (смеется) Зачем? Мы же пишем приложение для умных чайников. Если чайник перегрелся — мы не откатываем, мы просто отправляем ему мем с котом. Это атомарно.
— А как же целостность данных?
— А мы не храним целостность. Мы храним настроение. ИИ сказал, что для нашего домена достаточно вероятностной согласованности с вероятностью 87,4%.
Теперь про молодежь, которая учит "устаревшее":
Представь бедного студента Вовочку. Он сдал экзамен по «Классическим РСУБД» на 5 баллов из 10 (потому что препод — динозавр, который помнит установку Oracle на дискеты). Петя выучил наизусть все уровни изоляции транзакций, 3-ю нормальную форму и настройку shared_buffers.
Он выходит на работу. ИИ-рекрутер говорит:
— Ваш стек?
— Oracle, MySQL, Postgres...
— (ИИ вздыхает, как гуманитарий на уроке алгебры) Это всё равно что спросить у пещерного человека, умеет ли он добывать огонь трением. Мы сейчас создаём базу данных под каждый HTTP-запрос заново. Вот смотри: пользователь нажал кнопку «Лайк» — мы инстанцируем in-memory СУБД на 3 секунды с именем «Like_4728_a». Она знает только одну таблицу и умирает, когда лайк улетел.
Петя в шоке:
— А как же бекап?
— Зачем? Если данные потерялись — ИИ дорисует их по контексту. Точность 99,9%, погрешность — всего лишь пара разводов в год.
Главный парадокс:
Когда мы наконец создадим ту самую «абсолютно оптимальную» систему без лишних функций, она станет самой универсальной, потому что её будут копировать для каждого проекта. И мы вернёмся к тому же самому, но с приставкой «AI-native». И вместо pg_dump будет промпт: «Сгенерируй мне бэкап-формат в виде стихотворения в стиле хайку».
А 18-летние зумеры, которые сейчас учат Docker и Kubernetes, через 5 лет будут с ностальгией вспоминать: «Вот раньше были времена! Настоящие админы ставили кластеры руками, а не шептали нейросети: "Сделай мне 500 подов, но чтобы они пахли ванилью"».
И знаешь, что самое смешное? Пока мы тут фантазируем, в соседнем цеху уже пишут монолит на Java 8 с Oracle, где поле «phone_number» хранят в VARCHAR2(4000) «для масштабирования», и оно работает быстрее, чем любой AI-оптимизированный велосипед, потому что дядя Коля его настроил ещё в 2015-м и с тех пор не трогает.
Вывод: Универсальность — это не баг, это фича для ленивых. А молодёжь пусть учит — чем сложнее будет старьё, тем дороже мы, мамонты, будем его поддерживать. Пока ИИ будет генерировать СУБД под каждый чих, мы будем пить кофе и говорить: «О, у вас тут COMMIT отвалился? А у нас на голом металле всё летает. И да, мы знаем, где лежит postgresql.conf».
Так что не переживай. Классика умрёт только тогда, когда перестанут рождаться люди, которые любят говорить: «А у меня в продакшене...» и закатывать глаза. А это, как известно, бессмертно. 😉
August 23, 2026 118 1