Comments 113
Отличная статья ! Очень правильная ! Нужно быстрее и шире внедрять в практику проектирования СУБД и особенно для высоконагруженных систем всякие нейросети и прочие ИИ.
Это позволит DBA старой школы очень долго быть востребованными и диктовать ценник за услуги !
Запрос стоимостью 3 триллиона и вопрос руководителя разработки "почему у нас всё не работает " - я видел. И этот запрос написал человек , ну с помощью ORM конечно. А уж ORM + ИИ будет круче Чип и Дейла - точно.
Теперь , после таких статей уверен - мы и не такое встретим. По крайней мере в программе конференций ИИ уже анонсирован.
И это хорошо ! Впереди очень много интересных открытий . Уж , что может напрогнозировать нейросеть про оптимизацию производительности СУБД - кейсов достаточно . А уж если нейросеть пустить в архитектуру - ух даже дух захватывает .
Благодарю за комментарий! Почувствовал в нём нотку сарказма, здесь стоит упомянуть, что всё приносит пользу при правильном использовании, и вред при неправильном. И молотком можно ударить по пальцем, но это не значит, что молоток плохой – то же самое и с использованием нейросетей. Если их использовать бездумно, без понимания технического аспекта, не проверяя результат, и не пытаясь понять как он устроен – на выходе будет УГ. А если же точечно просить ИИ выполнить что-то, декомпозируя задачи, и детально описывая желаемый результат и его особенности, то достаточно быстро можно получить очень достойный результат. Что касается ORM – за счёт своей универсальности и удобства чтения, они действительно порой генерируют неэффективный громоздкий код, который долго выполняется. И тут между прочим, кроме шуток, может хорошо помочь ИИ, который напишет под задачу чистый SQL запрос.
На счет примера с молотком. Ну вот, допустим, есть механический молоток с несколькими степенями свободы и с ИИ начинкой. Его задача увидеть гвоздь и забить его. Гвоздь должен держать человек. Ну не доверился бы я такому молотку. Вдруг он посчитает мой ноготь, покрытый серебрянкой, шляпкой гвоздя?
Сейчас автомобили с ИИ начинкой ездят на автопилоте по реальным автомобильным дорогам, там масштаб ответственности повыше будет, чем "не попасть по пальцу забивая гвоздь"
Мда, и даже тут минус. Что, может я выдумал что автомобили на ИИ-автопилоте сейчас способны гонять, и это не так? Или это спортивный интерес какой-то всё заминусить? 😁
Я думаю что вы слишком преувеличиваете возможности ИИ автопилотов на данный момент. Да, они ездят, но только в хороших, я бы сказал рафинированных условиях. Тот же автопилот Тесла пару месяцев назад не смог проехать автономно между двумя городами, по трассе. Не заметил какую то железяку на дороге. Так что пока довольствуемся малым - удержание в полосе да адаптивный круиз контроль, без всяких ии, чисто на алгоритмах
Но факт в том, что это происходит, и люди доверяют свои жизни, садясь в этот автомобиль. То есть технология уже дошла до этого. Я же это не придумываю, говорю факты. Другой вопрос, что технология не идеальна, посмотрим что будет через года 3, лет 5, то что происходит уже сейчас – словно фантастика, а дальше ещё улучшат технологию.
Ну и кстати. В автопилотах никакого ии нет, строго алгоритмы. По крайней мере не дорлгах общего пользования
Да ладно? https://habr.com/ru/news/486600/
А дальше будет еще прекрасней. Картина уже не кажется такой утопической в свете обесценивания многих творческих профессий:
ИИ будет писать музыку, картины, стихи, прозу, творить прочие виды искусства, в перерывах поигрывая в гамы, а кожаные будут работать на кремниевых и прочих нужных для развития ИИ заводах 24/7/365 и скорее всего за еду. А ведь планировали все наоборот в прошлом веке. Кардинально противоположное! Но цели диктует бизнес, а бизнес больше не хочет нанимать человеков.
Я конечно, утрирую и гиперболизирую, но тенденции нехорошие наблюдаются. Надеюсь в скором времени ситуация исправится, пусть и не вернется на нормальные прошлые позиции.
А вас не смущает, что после картин появилась фотография, что после фотографии появилось кино чёрно-белое, затем цветное. Затем видео вообще стало как отдельным классом к примеру на том же Ютубе. На лошадях перестали ездить так массово. И да это требование бизнеса, потому как он закрывает какие-то потребности кожаных.
Вот именно, вы абсолютно правы! Это прогресс, и оглянувшись назад, мы можем с уверенностью сказать, что не зря после картин появилась фотография, что после фотографии появилось кино чёрно-белое, затем цветное, и так далее. Это гораздо круче, чем если бы мы оградились от прогресса, и только вручную рисовали картины. И стоит отметить – вручную картины и сейчас рисуют.
ИИ может усилить человека. Это как второй мозг, или дополнительные виртуальные руки. ИИ лишь помогает материализоваться идее – будь то код, картина, что либо ещё. Ускоряется время от идеи до её воплощения, при правильном взаимодействии с ИИ. И мы (человечество) можем достигнуть намного больших благ для себя же, при помощи ИИ и его развития.
Был какой-то стартап в сфере перевозок где за штурвалом ... Ну и закрылся ... Полтора года назад в новостях наткнулся. В то время встретил статью о такси и о грузоперевозках, фурах. По-моему это было о фурах, но может и о бразильской компании которая занималась такси... Честно специально не записывал и не помню львиную долю подробностей... Понимаешь почему такой скептицизм к этому. Это математично-статестическая модель использования слов. Логики там попросту нет. Ноль. Реально - с первого раза может только "hello world" накодить. Сама по себе в чистом виде, без дополнительных инструментов. Но так или иначе усреднённый ответ будешь иметь. И с этим ничего не можно сделать, они фундаментально так устроены. Видел мультик Cat-Dog? Вот тебе усреднённый ответ. Человек который с системами работает много, начинает и мыслить также как и системы и нет для него больше раздражающего чем маленькие недочёты, вот эти вот бл***кие недочёты. Неправильные переменные, иерархия вложения объектов. С иерархией в ЛЛМ большие проблемы ибо там логика нужна... А система может и не работать из-за одной неправильной переменной. Человек который шарит в нюансах таких ошибок не допускает ибо шишки ибо опыт. Чаще негативный и эмоционально яркий и хорошо записанный в подкорку. Профильная деформация это называется когда жизнь свою подчиняет или пробует подчинить безжалостно логике, иерархии. Суть ты понял я думаю. Не хочу тут трактат описывать. Мы то что мы едим, мы то что мы делаем. Мы строим себя из себя самих же.
С иерархией в LLM дела уже обстоят вполне себе, уважаемый. Тот же Cursor и ориентируется в существующей структуре, и сам способен создать структуру папок и файлов. Я как то проводил ревью файловой структуры не особо большого проекта, там backend с несколькими crud операциями и другой не сильно замороченной логикой, который был реализован полностью на ИИ. И я полностью одобрил структуру папок и файлов. То есть во первых она (структура) там была, а во вторых мне было не к чему придраться, чтобы сказать что что-то с ней не так.
Человек который шарит в нюансах таких ошибок не допускает
Поэтому у штурвала ИИ должен быть именно такой человек, который способен проверить результат. Сделать ревью, и при необходимости исправить.
В командах программирования и без ИИ точно так же и происходит. Если не делать обязательное ревью самыми опытными кодерами в команде, а то и внешними экспертами, то потом можно ошалеть от того, что накодили те кто выдаёт себя даже не за джунов, а за "миддлов" а то и за "сеньоров". А при грамотном ревью и всё работает, и команда развивается.
Уточню, потому что, кажется, мы говорим о разных уровнях.
Я **не спорю**, что современные инструменты на базе LLM (Cursor, Copilot, IDE-агенты) *умеют*:
* ориентироваться в существующей файловой структуре,
* создавать каталоги/файлы,
* воспроизводить **принятую** архитектуру проекта.
Мой комментарий был **не про это**.
Я говорил про **LLM в чистом виде**, как модель:
* без жёсткой схемы,
* без валидаторов,
* без типов,
* без AST,
* без runtime-проверок,
* без внешних инструментов, которые ограничивают пространство ошибок.
И конкретно — про **иерархию объектов и логическую связанность данных**, например:
* вложенные JSON-структуры,
* строгие контракты API,
* зависимости между полями,
* семантику, где одна ошибка в имени / уровне вложенности ломает всю систему.
LLM **не оперирует логикой и иерархией как системой ограничений**.
Она оперирует **вероятностями токенов**, даже если результат *выглядит* структурированным.
То, что ты описываешь (Cursor, ревью, рабочая структура) — это:
* LLM + контекст,
* LLM + tooling,
* LLM + человек как внешний валидатор и источник логики.
С этим я полностью согласен:
**у штурвала должен быть человек**, иначе система разваливается на мелочах.
Мой скепсис был не к «ИИ в команде»,
а к иллюзии, что **модель сама по себе** понимает иерархию так же, как человек с опытом, который уже набил шишки на неработающих системах.
Коротко:
* структура ≠ логика,
* воспроизведение паттерна ≠ понимание ограничений,
* без внешней валидации LLM фундаментально остаётся у
средняющей моделью.
Вот это я и имел в виду.
Как говорится, собака лает, караван идёт, Андрей. Все правильно пишешь
Вы уверены, что системы автоматического пилотирования работают на LLM?
Кто вам сказал, что я считаю что автопилоты работают на LLM? Я использовал формулировку "ИИ", и да, он там используется. Машинное зрение, и кто знает что ещё под капотом. https://habr.com/ru/news/486600/
Кто вам сказал, что я считаю что автопилоты работают на LLM?
Статья и комментарии к ней, которые про LLM (генеративный ИИ). Если Вы хотели сказать, что под формулировкой "ИИ" есть и другие технологии, которые справляются со своей работой получше, то это уже уход от основной темы обсуждение, так как обсуждается конкретная технология, а не лейбл "ИИ" в целом.
и да, он там используется
Он это кто, LLM? Там, где "масштаб ответственности повыше", или там, где условная Алиса выбирает музыку?
LLM - технология генерации контента, поэтому Вам неоднократно написали о том, что результат генеративных моделей надо валидировать, что в свою очередь требует неопределенного количества времени, которое игнорируется в контексте "экономии времени".
И кроме того, стоит отметить, что аварии автомобилей с автопилотом на борту (неважно какого генезиса) — тоже объективная реальность:
Авария Xiaomi SU7 в Китае (март 2025)
Tesla — смертельная авария 2019 года во Флориде (суд 2025)
2 ДТП с виной БА в России
LLM - технология генерации контента, поэтому Вам неоднократно написали о том, что результат генеративных моделей надо валидировать, что в свою очередь требует неопределенного количества времени, которое игнорируется в контексте "экономии времени".
Так я и сам пишу, что требует валидации. Вот часть текста одного из моих комментариев под этой же статьёй:
Я на личном практическом опыте многократно убедился, что экономия существенная, и эффект ускорения значительный. Да, именно при правильном использовании, с последующей верификацией. И я не говорю о том, чтобы делать всё-всё при помощи ИИ. Нужно понимать, какие задачи будет быстрее запромптить и отверифицировать, чем продумать и написать самому. Если ставить перед собой цель написать весь код проекта исключительно с помощью ИИ, то на более менее среднем-крупном проекте это доставит больше проблем, чем пользы. Однако реализацию отдельных моментов, которые можно эффективно ускорить с помощью ИИ, не жертвуя качеством и излишними время-затратами, рациональнее реализовывать с помощью ИИ. И да, это облегчит и ускорит процесс.
Вы неправильно поняли метафору. Сравнение идёт не между потенциально опасным инструментом без ии, и инструментом с ии. Сравнение идёт между одним и тем же инструментом, в одном случае оператор умеет им пользоваться и получает нужный ему результат, во втором случае не умеет и наносит себе травмы.
Благодарю за комментарий! Почувствовал в нём нотку сарказма, здесь стоит упомянуть, что всё приносит пользу при правильном использовании, и вред при неправильном.
Спасибо за спасибо. Да предчувствия не обманули - это был сарказм, ну совсем чуть-чуть конечно. Поставил бы я минус , если бы была техническая возможность - конечно нет.
Личный опыт использования нейросетей для DBA - каждому инструменту своя область применения.
Использование нейросетей, личный положительный опыт:
1) Семантический анализ результатов.
2) Формирование сводного отчета по результатам экспериментов.
3) Генерация гипотез и тем для исследований.
4) Генерация тестовых скриптов.
Можно ли эти задачи выполнить вручную ? Конечно можно. Зачем использовать нейросеть ? Для экономии главного ресурса - время.
Использование нейросетей, личный негативный опыт:
1) Прогноз влияния изменения конфигурационного параметра на производительность СУБД - соотношение ложных к верным = 14 к 1. Монетку бросать было бы эффективнее.
2) Рекомендации по оптимизации производительности - просто генерация текста. Практической пользы практически ноль. ВСЕ рекомендации нужно проверять экспериментально.
По последнему пункту, по итогам посещения 3-х вебинаров на тему использования ИИ для оптимизации производительности явно вижу явную тенденцию - тему будут окучивать и устраивать чёс - все , кто сможет дотянутся. Проблема в том, что рекомендации нейросетей по оптимизации основаны на очень ограниченном наборе начальных данных. Ну например на одном вебинаре , ведущий кроме как создание индексов просто не знал что есть еще множество способов влиять на производительность СУБД. И это решение они будут продавать и это будут покупать.
Что в общем то лишь подтверждает тезис начального комментария - "Это позволит DBA старой школы очень долго быть востребованными и диктовать ценник за услуги ! "
Стандартный цикл разработки ПО в принципе не изменится после широкого внедрения ИИ в процесс разработки , сейчас(по опыту реализации импортозамещения в крупной компании):
1) Эйфория и всеобщий энтузиазм разработчиков , архитекторов и менеджеров.
2) Процесс разработки (скрам, аджайл и прочеее по тренду)
3) Нагрузочное тестирование для закрытия этапа
4) Запуск в продуктивной нагрузке с живыми пользователями
Результат - ой , у нас все тормозит, ну как же так, на тестовом стенде все же работало и летало.
И только здесь идет обращение к DBA - "помогите , мы уперлись в СУБД."
А дальше все по классике как было и 10 лет назад и 20 и 30 - процесс оптимизации в реляционных СУБД в общем то ничего особо нового не предлагает.
Как изменит ситуацию внедрение ИИ на этапе разработки ? Да наверное никак, может быть даже больше будет запросов стоимостью 3 триллиона и вопросов разработчиков - а почему у нас под нагрузкой все медленно .
Согласен, как я и писал где то под этой же статьёй в ответе на другой коммент – нужно использовать ИИ с умом и пониманием где он будет полезен, а где его использование будет неэффективно, и даже вредно. Нельзя слепо верить ИИ, и давая ему задачу, обязательно нужно иметь возможность убедиться в правильности результата.
На самом деле, все споры , обсуждения вокруг темы можно завершить сразу в самом начале - нейросеть/LLM не являются искусственным интеллектом. Тем более абсолютно все чат-боты даже шага не сделали к направлению интеллекта.
Это всё просто математические алгоритмы , предназначенные для своих узкоспециализированых задач .
И всё. Тема для споров исчезает. Хотя и траффик в сети и сопутствующий хайп тоже пропадает. В общем получается скучно.
P.S. Вспомню опять случай из даааалекой молодости(год примерно 1987). В бытность даже еще не студентом, а школьников 10-го класса, как то имел разговор с доктором философии. Ну и стандартный вопрос
-а вот чем хочешь заняться, что интересно , куда поступать надумал ?
-да вот тема искусственного интеллекта очень интересна(эта тема не в этом году родилась, работы идут ооооооочень давно, если кто не знал)
-ну тогда для начала вы должны понять, что такое интеллект, сознание . Надо Юнга почитать, Фейербаха, для начала.
Читал, наверное и поэтому то же в тему искусственного интеллекта так и не зашел , выбрал области попроще.
Вот я очень сильно сомневаюсь, что те кто везде использует термин Искусственный интеллект знают кто такие Юнг, Фейербах.
IMHO термин "искусственный интеллект" был специально применен для повышения интереса и окучивания инвесторов в общем то вполне академической и не самой новой темы. Но всемирный хайп сделал свое дело - бабло потекло не рекой а просто океаном.
Чем кончится - поживем увидим.
А вот LLM считает, что он является искусственным интеллектом 😁
И гугол тоже пишет, что "обзор от ИИ"
Как по мне не нужно сравнивать искусственный интеллект с человеческим. Это естественно не одно и то же, и не будет одним и тем же. У человеческого интеллекта есть свои плюсы и минусы (но не у всех людей есть интеллект 😁), у искусственного интеллекта есть свои другие плюсы и минусы.
И сила именно в объединении человеческого и искусственного интеллекта, или если вам так больше нравится, человеческого интеллекта и мощь результатов машинного обучения
По авторам это док реально пожалел и не бахнул на все деньги, так там будет, если не стесняться:
Декарт
Локк
Мерло-Понти
Витгенштейн
Сёрл
Нагель
Гуссерль
После 87 года добавились (навскидку)
Чалмерс (1996)
Деннет (1991)
Бостром (2014)
Disclaimer. С большим уважением отношусь к профессионалам (не только в IT, а вообще), но мир - не черно-белый.
Давно понятно, что ai-ассистент - не заменитель рук и головы, а удлинитель. Полностью делать сложную задачу в чат-боте - такая же странность, как полностью всё писать руками, когда можно переиспользовать готовый код или задать боту подробную профессиональную инструкцию сгенерить что-то простое или типовое-объемное. В любом случае придется проверять, а не втупую add, commit, push.
Абсолютно верно, и ИМХО больше всего ценятся и будут цениться как раз специалисты, обладающие глубокой технической экспертизой, и навыками эффективного использования современных вспомогательных инструментов вроде искусственного интеллекта. Такие люди всегда будут очень востребованны, и как выразился pg_expecto, будут диктовать ценник за услуги
Это не так работает. Конкретной компании нужны специалисты под конкретные задачи исполняемые конкретными инструментами существующими уже. Вот так вот и определяется ценность специалистов. Если инструмент какой-либо устаревшей perl, но на него завязано очень много, значит такой специалист будет цениться. То есть ценность специалиста "в моменте", здесь и сейчас.
В наши времена человек может быть экспертом в другом языке программирования, и не знать Perl. И если он владеет нейросетями – не знание именно Perl не помешает ему успешно выполнить задачу на Perl. А если не владеет – то он в принципе сможет справиться, но на это уйдёт колоссальное количество времени, несопоставимое с тем, если он будет использовать ИИ. А старые технологии вымирают, и заменяются новыми. Сколько раз я уже застал ситуации, где бизнес огромные деньги тратит чтобы переписать ПОЛНОСТЬЮ РАБОЧУЮ систему на новый стек, хотя казалось бы зачем тратиться, когда всё уже создано и работает.
Ого! Давно мечтал о таком инструменте, где можно простыми словами накидать базу, ии конечно творит чудеса
Я сам не перестаю удивляться, я был в восторге ещё когда просто в режиме чата можно было общаться как с человеком, а сейчас ИИ уже и в файлах с кодом ориентируется, может создавать новые, вносить изменения сразу в несколько файлов, базы данных проектирует, и прогресс в ИИ-инструментах очень быстро идёт! Только и успевай узнавать, что ещё нового вышло, и как этим улучшить свои процессы!
Накидывайте. Если проект взлетит и у него появятся деньги мы потом за очень много денег переделаем все нормально.
Потом DBA и архитекторы с LLM вместо мозга забудут про нормальные формы, нормализацию и денормализацию (и когда что применимо) и настанет новый дивный мир, pg_expecto совершенно прав!
Если использовать LLM чтобы он делал работу ВМЕСТО вас, то да, результат будет не обнадёживающий. Здесь же речь идёт о том, чтобы использовать его В ПОМОЩЬ себе, проверяя и дорабатывая его результаты. Приведены примеры как это можно сделать. Некомпетентные архитекторы БД были и до LLM, и всегда будут. А компетентным ИИ может помочь в работе, например массово внося изменения в таблицы. Неужто этот факт настолько плох, что нужно яростно минусить и статью с примерами, и все мои комменты?)))
Массовые изменения вносить или не надо или это делается за полчасика через регэкспы или в тяжелом случае через sed. Вайб проектировщики когда-нибудь тоже так научатся.
Вот именно, что как вы говорите "за полчасика". А тут за минуту. Повторюсь, это так плохо?)
Над такими изменениями стоит минимум денек подумать. Обсудить надо с кем-то. И только потом делать. Полчаса на понажимать кнопки уже не играют вообще никакой роли. Это скорее отдых от реальной работы которая к этому моменту уже сделана.
Да, это так плохо.
Вы про что вообще говорите? Речь про проектирование БД в статье идёт, а не про внесение изменений в реальную базу данных при помощи ИИ, в курсе?
Проектирование БД любой более-менее сложной системы делается на доске маркером. И занимает хорошо если только недели.
Формально описать таблички это погрешность какая-то.
Типовые системы не надо проектировать. Открываем справочник по красным мячиками и списываем оттуда верное решение.
Можно не на доске и не маркером, но это в общем-то детали, не отменяющего общего подхода "использовать разум, а не LLM, там где нужно разум"— на готовую согласованную принятую всеми ERD я даже рискну (возможно) LLM-ку натравить, чтобы она CREATE/INSERTы родила со всеми описанными констрейнами и прочим (но все равно перечитаю после нее)
@BoomerCore полностью соглашусь, что не нужно использовать ИИ "вместо" разума. Однако можно попросить накидать его варианты, например предположить какие нужны сущности и связи. И далее посмотреть что он предложил, и на основе этого мыслить самому. Вдруг ИИ предложит то, что было упущено на первый взгляд, и это будет полезно. ИИ оперирует значительно большей базой знаний, чем любой человек, просто за счёт объёмов. Какой бы человек не был гик и в хорошем смысле слова задрот в теории, ИИ всё равно знает больше тонкостей и приёмов в ней. Но всегда важно понимать, что нельзя на 100% доверять результату генерации, и нужно иметь возможность её проверить и убедиться что это именно то что нужно, или понять что и как нужно доработать. И повторюсь, в большинстве случаев проще докрутить что-то существующее, чем с чистого листа делать. Как и цели использования ИИ – можно например не просить спроектировать "за вас" базу данных, но сгенерировать код тех же INSERT, SELECT и тд по спроектированной схеме, результат с высокой вероятностью будет тот что нужен, а время будет потрачено существенно меньшее.
Воспринимайте ИИ не более как самописную доску с маркером, которая готовит вам черновик, который вы словами можете корректировать. И будет вам счастье. Каким бы ни был ИИ на данный момент или в будущем, ответственность всегда лежит на том, у кого есть доступ к клавиатуре.
@BugM Вы мыслите слишком консервативно для нынешнего времени. БД на доске маркером, а дальше что, когда через год нужно погрузить нового члена команды в то как бд устроена? Фотографию доски ему показывать? Или эту доску в рамочку повесить и не трогать? На каждый проект по доске? А когда внести изменения в схему нужно, маркером стирать и дописывать? Почерком который возможно половина людей не разберёт? Отлично, современно 👍
Когда БД спроектирована человек садится и пишет create table под все что придумали и согласовали.
Стирать это хорошо. Это гораздо лучше чем не стирать. На этапе доски ошибки почти бесплатны. Любая пойманная ошибка экономит море денег.
Фотографии доски после совещаний это вообще ценный артефакт. Он вероятно поможет кому-то через 10 лет понять как до такого дошли. Хорошо бы к нему еще и краткие резюме совещаний оставлять. Тут нейронка ок, превратить 30 минут разговора в пару абзацев она способна.
А сколько БД крупных (допустим от человекогода на разработку бекенда) прод сервисов вы спроектировали? Я несколько.
Стирать это хорошо. Это гораздо лучше чем не стирать. На этапе доски ошибки почти бесплатны. Любая пойманная ошибка экономит море денег.
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Фотографии доски после совещаний это вообще ценный артефакт. Он вероятно поможет кому-то через 10 лет понять как до такого дошли.
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
Когда БД спроектирована человек садится и пишет create table под все что придумали и согласовали.
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
А сколько БД крупных (допустим от человекогода на разработку бекенда) прод сервисов вы спроектировали? Я несколько.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Вы не поверите. Доска удобнее и эффективнее любого онлайн инструмента. Она даже окупает командировки людей. Но от безысходности можно и онлайн порисовать. Всякое бывает.
Визуальной схемы на этапе проектирования не существует. Есть сущности, есть их связи, есть какие-то важные или не очень свойства, есть инварианты. И это все меняется на каждом совещании. Иногда просто выворачивается наизнанку. А вот схемы БД нет. И это хорошо. В реальной БД есть море тонкостей которые на этапе проектирования просто не нужны и вносят много шума. А его и так достаточно. Три-четыре сеньора генерят прямо очень много разумных идей и предложений и имеют пять-шесть вариантов решения для любой проблемы. Разумных вариантов. Все неважное на этом этапе должно быть откинуто. Сеньор потом это просто сделает а второй сеньор его проревьюит.
Ну да, писал и не раз. А в чем проблема? БД на 50-70 таблиц в версии один это прямо очень сложная система. И скорость проектирования это наименее важная характеристика. Потратить пару дней сеньора на написание create table и пусть он еще подумает пока руки пишут и выловит одну логическую ошибку это идеальное решение. Эта же ошибка но не выловленная на этапе проектирования потом будет стоить хорошо если только месяцы работы команды.
А и сейчас нет альтернатив. Интерактивность уровня взять другой маркер и порисовать наискосок так чтобы все обратили внимание недоступна ни одному онлайн инструменту. Я перепробовал наверно все популярное. И все не очень. Видимо это проблема психологии, а не инструментов. Ну и ладно, будем и дальше в гости друг к другу кататься чтобы порисовать.
Командировка сжигает минимум два дня. Даже Москва-Питер. 4.5 часа Сапсана умножить на два в один день не влазит. Человеку надо поспать нормально после дороги и идти утром в офис. Меряем сроки и затраты людей исходя из этого. Один день вообще не имеет значения. Неделя это минимальный срок о котором думаем. Время на напечатать 70 create table - ничто.
У меня был очень тяжелый проект который примерно квартал онлайн вообще не двигался. За второй квартал когда мы раз в две недели стали собираться вместе в одном офисе все сделали. Прямо вообще все. Осталось только сделать тикеты и отдать на разработку.
Интерактивность уровня взять другой маркер и порисовать наискосок так чтобы все обратили внимание недоступна ни одному онлайн инструменту.
"А если найду?" (с)
Я лично знаю 2, где уникальные маркеры выдаются автоматически каждому участнику, и 2 — с выбором цвета маркера вручную, и отдельно еще Excalidraw, где в режиме совместной работы видно, кто что добавлял (цвет инструмента один, но разделение по авторству есть).
Перечислять?
Проектирование любой системы хранения данных это итеративный процесс, в процессе которого совершенно объективно появляются изменения и дополнения. если для вас это новость — мои соболезнования (не знаю кому, вам или вашему работодателю). Коллега BugM в главном совершенно прав.
@BoomerCore вот именно, что "проектирование любой системы хранения данных это итеративный процесс, в процессе которого совершенно объективно появляются изменения и дополнения."
@BugM же утверждает что БД должна проектироваться никак иначе как маркером на доске, в 2025 году...
Я не говорю что сложную БД нужно спроектировать за один промпт, и не проверяя кидать в релиз. Но как минимум можно и нужно использовать современный онлайн инструмент с общим доступом, к которому можно всегда вернуться в любое время и с любого устройства, легко вносить необходимые изменения (хоть вручную, хоть запросом описывая ИИ какие конкретно нужны изменения, например для массового редактирования таблиц). И нет ничего плохого в том, чтобы во время проектирования советоваться с ИИ, именно советоваться а не использовать его вместо своих мозгов, принимая за истину всё что он отвечает.
В вашем диалоге пока именно BugM выглядит и звучит как профессионал с основательным традиционным подходом, который (проверено опытом десятилетий) работает, поэтому он, как опытный профессионал, имеет неотчуждаемое право на мелкие личные слабости, и если хочет "маркером на доске" — будет маркером на доске. А артефакты результатов его труда (если потребуется, хотя я уверен, что сохраняемые результаты<этой итерации> он сам положит куда нужно когда нужно) подберет и ассистент из "адептов модного". Более того. в развитие темы — если он, как проверенный ценнейший специалист, для рисования моков запросит спины белых девственниц, то вопрос будет не "а зачем это тебе надо?", а "какую площадь обеспечить единовременно?"
Инструмент не важен, важно — решается задача или нет. Если все стороны процесса в одном физически месте в одно время, то лищние уровни для работы им могут быть банально не нужны. А сохранение/распространение информации — отдельный вопрос, хоть и связанный, так как проектировщик/DBA работает не в вакууме.Чисто теоретический вопрос - вы представляете себе, что такое НФ? От 3 до 6? И как одна физическая сущность может развертываться в произвольное число таблиц и всего прочего, описывающего ее? А связи сущностей? Нарезать это в отдельные промты? Ну, удачи
Более того. в развитие темы — если он, как проверенный ценнейший специалист, для рисования моков запросит спины белых девственниц, то вопрос будет не "а зачем это тебе надо?", а "какую площадь обеспечить единовременно?"
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
Инструмент не важен, важно — решается задача или нет.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Чисто теоретический вопрос - вы представляете себе, что такое НФ? От 3 до 6? И как одна физическая сущность может развертываться в произвольное число таблиц и всего прочего, описывающего ее? А связи сущностей? Нарезать это в отдельные промты? Ну, удачи
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.
Да, я не поленился наконец посмотреть что там курсор нагенерил. Что же, все "ожидаемо плохо", но в точном соотвествии с промтом. LLM не думает, а только старается выполнить заданный промт. Так вот, дедушка Оккам результат не одобряет.
Контрольный вопрос: что в схеме вызвало у меня такую реакцию? Хинт: нет, это не следование школе "искуственных ключей", потому что "искусственники vs естественники" это давний безнадежный религиозный спор.
Покажите, что вы хотя бы "так себе мидл". И да, я не настоящий DBA, потому что давно ушел из мира большого секса, еще до рождения Постгреса, коллега BugM на вскрытии может (если захочет) увидеть и больше.
Иногда все же надо, потому что "приходится"
Я бы инструменты "на расслабоне" и "в тяжелом случае" поменял местами, потому что реально серьзные регекпы "на все деньги" более тяжелая артиллерия, чем sed. Но это "личное оценочное суждение", не опровергающее базовый тезис, с которым соглашусь. Сделать руками — оно еще и автомагически лучше запомнится, хотя бы на уровне глобальном "что" и "почему"
Те же самые регулярные выражения проще и быстрее сгенерировать нейросеткой по запросу, чем зубрить/гуглить/вспоминать необходимую последовательность символов. И как BugM собирался редактировать визуальную схему базы данных при помощи sed/регулярок для меня остаётся загадкой, ведь речь идёт про проектирование "чертежа" базы данных
Человека не знающего синтаксис регулярок наизусть и я бы не подпускал к клавиатуре при проектировании БД. Он еще не дорос. Пусть регулярки учит. Синтаксис упрощенный естественно,тонкости можно и погуглить.
Схема БД это текстовый файл. Лежит в гите конечно. Визуальную схему каждый генерит своей любимой тулзой. Конфиги для любой любимой тулзы тоже лежат в гите. Новичок просто берет готовый.
Я не знаю регулярок наизусть. Я знаю как они работают. Когда надо хожу в документацию. И последние 20 лет работаю с базами данных, побочно. Конечно они не супер сложные, но свои задачи выполняют. Вопрос в сложности задачи. Если тебе надо поменять розетку в квартире, то тебе не надо проходить курсы по высоковольтных линиях. Просто поражает вот это вот школьная манера-зазубривать.
Требования "знать наизусть все изыски" в утверждении не было, так что уровень (и метод решения, кстати)
Я знаю как они работают. Когда надо хожу в документацию.
вполне рабочий и удовлетворительный. Неудовлетворительным был бы в случае "схожести до неразличимости" с чем-то таким
сразу идти к LLM с промтом "Замени каждый 5 символ в строках многострочного текста, если это цифра, на 5, но только если цифра не 9нечетная (чуть больше адка в студию), и перед цифрой не стоит ab". Пример выдумал на лету из головы, он не суперсложный по ощущениям, но "есть нюансы"
Я понял вашу позицию. Вся проблема осуждальщиков работы с ИИ именно состоит в том, что они экстраполируют применение этого инструмента на все случаи жизни. А ведь автор акцентирует внимание, так же как и я: этот инструмент надо использовать точечно, подходя к этому адекватно и логически. То есть давать оценку изначально есть ли смысл применять этот инструмент, после которого или во время использования которого придётся потратить достаточное количество времени на коррекцию результата. Приведу простой пример: надо завернуть два шурупа. Есть отвёртка под боком и электрический шуруповёрт включаемый в розетку, лежащий где-то наверху. Естественно, что быстрее взять отвёртку и закрутить два шурупа, чем доставать шуруповёрт, расправлять провод, вставлять биту, потом всё это сворачивать. Но если задача стоит, закрутить 100 шурупов, безусловно шуруповёрт и работа с ним, подготовка обратно укладывание даёт ощутимый результат. В этом-то и задача специалиста не бездумно использовать инструмент, а манипулировать ими.
В оригинале автор стаьи ни разу не намекнул, что он (если использовать ваши) аналогии "генерит 100500 описаний БД в час, а с ИИ стал еще в 6 раз больше"
Шуруповерт — ни разу не удачная аналогия современным LLМ: у него нет свободы выбора и вариативности решений на одной и той же формулировке. Точнее — вообще выбора нет, в отличие от...
И я и BugM пишем не о том, что "надо делать руками то, что можно и имеет смысл делать неруками", а о том, что целесообразность каждой операции замены кожаного мешка на силиконовый кирпич надо оценивать. В вашей же аналогии: закручивать надо один винт из стали X, решение об этом принято в результате совещаний и согласований за время X. Что по итогу принципиально изменится, если вместо закручивания руками за время X/10 будет использован (небесплатный, дополнительно к работнику) шуруповерт с интеллектом, который закрутит тот же винт за X/50, но перед этой операцией надо проверить, что интеллект выбрал винт именно из "стали X", а не Y, потому что "усе выбирают Y", и так до тех пор, пока он не возьмет правильный. Аналогия так себе, но как драфт пойдет
Так что мы не возражаем против использования LLM a priori, а только лишь против использования "везде, куда вроде как можно засунуть", без оценки нужности, эффективности и всего такого (ТЭО, в общем)
Так что мы не возражаем против использования LLM a priori, а только лишь против использования "везде, куда вроде как можно засунуть", без оценки нужности, эффективности и всего такого (ТЭО, в общем)
Забавно что и я и @fulvert тоже говорим именно о том, что
ИИ надо использовать точечно, подходя к этому адекватно и логически. То есть давать оценку изначально есть ли смысл применять этот инструмент, после которого или во время использования которого придётся потратить достаточное количество времени на коррекцию результата.
Но при этом у нас тут развязался чуть ли не спор на эту тему, хотя как будто бы в этом мы мыслим одинаково 😁
Лежит в гите конечно
или не в Git, потому что им мир SCM не ограничивается, но да — лежит, версионируется, и вся история жизни, а не только текущее состояние, при необходимости поднимается и используется
Человека не знающего синтаксис регулярок наизусть и я бы не подпускал к клавиатуре при проектировании БД.
Это вопрос диалектический, иногда можно, мне кажется. Под жестким супервизором. Хотя как интеллектуальный фильтр вполне применимо.
Те же самые регулярные выражения проще и быстрее сгенерировать нейросеткой по запросу, чем зубрить/гуглить/вспоминать необходимую последовательность символов.
Только простейшие случаи, которые (у меня) и так будут идти примерно со скоростью набора на клавиатуре. Как только идут сложные более-менее реальные ситуации начинается боль, это даже если не вспоминать про в общем-то обилие разных подсинтаксисов в базовых (и заметно разных) PCRE и POSIX
редактировать визуальную схему базы данных
Никак, что любому очевидно — визуализация это только представление, а описание (оно же формализация) у вменяемых проектировщиков в тексте, не обязательно text/plain, но регекспам на этот момент класть с высокой колокольни.
Вижу, BugM меня апиридил, но все же оставлю, чтобы не сложилось впечатления, что это его персональная девиация, а "норм посоны так не делают"
Здесь на Хабре столько ненавистников ИИ, видимо я ошибся с темой. Надо было написать что-то вроде "о ужас, ии всё испортил, и с ним стало только хуже, везде и у всех!", видимо тогда статья бы залетела. Эта статья в топике "ИИ в разработке", в ней по сути ничего кроме примеров, как ИИ может помочь при проектировании БД, откуда столько ненависти и минусов?)) Я показал как можно использовать ИИ в помощь, нравится используйте, не нравится не используйте...) Не хотите использовать "этот ваш ИИ", никто вас не заставляет. Или реакция минусом приносит какое-то неописуемое удовольствие?))) Вот так, участвуешь в "сезоне ИИ разработки" от Хабра, делишься практическими примерами использования ИИ, и в ответ получаешь кучу негатива) Ну ок, чё..) Может новогоднего настроения нет у людей, или авралами завалило перед НГ. Или ИИ бесит самим фактом своего существования, может кого-то сокращают, наивно думая что ИИ способен заменить программиста (не способен, может только усилить при грамотном использовании). Остаётся только гадать...
Обратите внимание: количество добавлений Вашей статьи в закладки не влияет на карму и рейтинг, но красноречиво подчеркивает расхождение между оценкой статьи и пользой её для читателей.
Закладки это не "польза", там даже корреляции скорее нет, чем есть
27 закладок на сколько там прочтений (ладно, просмотров доступно публично)? Посчитаем процент? 27/8687 даже полпроцента не сделал
"Миллион леммингов не может ошибаться"?! А тут — даже не миллион
@BoomerCore да вы правы, эта статья никому не может принести пользу 😇 в отличие от ваших комментариев 😁
Тоже об этом думал. Вообще я заметил общую для большинства людей особенность – если человек чем-то доволен, он может не заморачиваться на плюсы, хорошие отзывы и так далее. Но вот если испытывает малейшее несогласие или недовольство – сразу готов и минусы писать, и жалобы подавать, и всё что угодно. Я и за собой это заметил – и начал с этим работать. Например когда я ездил на такси, и поездка проходила отлично, я просто выходил и всё. Но стоило водителю как то меня огорчить, хотя бы чуть чуть, я сразу снижал оценку, и писал плохой отзыв. Далее я пересмотрел эту позицию, и сфокусировался на том, что я хотя бы чутка остался доволен, я обязательно поставлю высокую оценку, а если вообще отлично всё прошло, то и оценку высокую, и отзыв хороший, и может даже чаевые дам. А если наоборот водитель меня огорчил, то я ещё подумаю – а настолько ли это ужасно, чтобы ему снижать оценку? Надо ли вообще снижать, и насколько сильно, может до 4 или 3, а не до 1 или 2? Может проблема вообще была во мне, моём настроении, или моих необоснованных требованиях к водителю? И так далее. И вот знаете, когда я на все сферы жизни такое мышление начал применять, лично моя жизнь сильно изменилась в лучшую сторону.
Благодарю за комментарий!
Здесь на Хабре столько ненавистников ИИ, видимо я ошибся с темой. Надо было написать что-то вроде "о ужас, ии всё испортил, и с ним стало только хуже, везде и у всех!", видимо тогда статья бы залетела.
Может новогоднего настроения нет у людей, или авралами завалило перед НГ. Или ИИ бесит самим фактом своего существования, может кого-то сокращают, наивно думая что ИИ способен заменить программиста (не способен, может только усилить при грамотном использовании). Остаётся только гадать...
Если гадать, то может слегка минуснули за то, что в статье ничего нового, одни банальности в перемешку с остро-эмоциональными пассажами. Ну реально "Ведь ИИ в ИТ не для того чтобы заменить нас, а для того, чтобы дать нам супер-силу!" - мы же не на комсомольском собрании.
А чем ИИ не супер-сила? Он обучен на огромных базах знаний людей, и буквально за минуту может выполнить просьбу например по коду, и выполнить весьма хорошо, если точно описать её, с учётом всех пожеланий. Вы пробовали?
Ничего нового в статье, вы каждый день видите как ИИ рисует схемы базы данных?) Я вот ни разу не видел статью об этом например.
Проблема LLM в том, что вы не можете верифицировать качество этих знаний до того, как используете их интерпретацию силами той модели, которую применяете.
Тезис "миллион леммингов не может ошибаться" — глубоко ошибочен и методологически порочен.
Это становится проблемой, если просить LLM сделать то, о чём сам не знаешь. Если просить сделать то, что понимаешь как должно быть устроено, и формулируешь промпт именно с указанием этих тонкостей, то можно и получить необходимый результат, и оценить, насколько он корректен. И это будет быстрее, чем писать вручную. Не нужно просить LLM сделать крупные задачи по абстрактному описанию. Сначала крупная задача декомпозируется на набор мелких задач, далее нужно максимально точно сформулировать какой нужен результат по каждой задаче, получить и при необходимости скорректировать результат, и после этого уже приступать к просьбе выполнить следующую декомпозированную мелкую задачу. Тогда это становится супер-силой. А если написать промпт а-ля "напиши мне программу чтобы товары продавать", то и на выходе будет чёрти что. Всё опять же упирается в умение правильно использовать инструменты..
Вам уже тут неоднократно объясняли, что если делать задачу правильно (ваш пример), то экономия "на спичках" даст настолько незначительный эффект ускорения в %времени (если даст, потому что результат еще надо проверить-верифицировать), что введение еще одного (слабого) звена (да еще и внешнего, неконтролируемого с вашей стороны) в цепочку получения решения не выглядит с рациональной точки зрения обоснованным и "в моменте" и "в перспективе"
Какой дополнительный value получает бизнес от предложенного решения?
Какой смысл объяснять то, с чем не сталкивались, или сталкивались слишком поверхностно, чтобы иметь право рассуждать о чём речь? Я на личном практическом опыте многократно убедился, что экономия существенная, и эффект ускорения значительный. Да, именно при правильном использовании, с последующей верификацией. И я не говорю о том, чтобы делать всё-всё при помощи ИИ. Нужно понимать, какие задачи будет быстрее запромптить и отверифицировать, чем продумать и написать самому. Если ставить перед собой цель написать весь код проекта исключительно с помощью ИИ, то на более менее среднем-крупном проекте это доставит больше проблем, чем пользы. Однако реализацию отдельных моментов, которые можно эффективно ускорить с помощью ИИ, не жертвуя качеством и излишними время-затратами, рациональнее реализовывать с помощью ИИ. И да, это облегчит и ускорит процесс. Опять же, лично я рассуждаю не на основе моих теоретических предположений на этот счёт, а на основе многократного практического опыта, а вы? Лично вы пробовали подобным образом работать с ИИ? Или вы "и так всё знаете" чтобы даже не пробовать?))
Какой смысл объяснять то, с чем не сталкивались, или сталкивались слишком поверхностно, чтобы иметь право рассуждать о чём речь?
Вы так уверены, что именно я "не сталкивался" или "слишком поверхностно"? И на чем же основана ваша уверенность? Ну расскажите, всем заинтересованным сторонам будет интересна история духовидца и телепата. А право рассуждать у меня есть всегда и обо всем, независимо от вашего об этом мнения. Качество рассуждений и выводов может сильно меняться в зависимости от глубины погружения в... и понимания контекста, но не возможность иметь право или нет
Пока вы старательно скатываетесь на уровень "малолетний невоспитанный хам", продолжите дальше — у меня внизапна закончится педагогический запал. Мне от этого хуже не станет, станет ли лучше в моменте и в перспективе вам — вопрос к вам.
Я на личном практическом опыте многократно убедился, что экономия существенная
Если вы работаете по методологии ХХП, то да, такое возможно, при этом я лично рекомендую всем не забывать про правило "Shit in - shit out".
А когда собственно реализация это только последняя часть процесса решения задачи, то и я, и собрат по несчастью "объяснять очевидные вещи упертому адепту хайпа" BugM излагают точку зрения чуть более приближенную к реальности, в которой "все не так однозначно", и у меня на это есть некий букет примеров разного уровня сложности
ну может у них продукт - змейка на js, или магазин на дижанге, штош Вы так строго (*сарказм*)
p.s. есть некоторые проблемы с комментированием, как вы понимаете, по этому отвечаю не совсем стандартно.
никто не нападает на сложность технических реализаций, я как бы говорю, что в обучающих выборках всегда есть змейка и магазин на дижанге. Отсюда фокус с написанием 146% кода чатботом, - работает.
А если вы попросите извлечь хэш из запароленого пдф, то скорей всего чатбот напишет всё что угодно, кроме того что нужно
сопсно весь сарказм буквально в этом, а вы заставили меня объяснять анекдот. шейм он ю
Вы, к счастью, не представляете, что спроектировать нормальный (это слово тут главное) e-shop — не совсем банальная задача, даже если не надо думать о хранении сущностей товарных, где отдельный круг ада для проектировщиков магазинов должен быть (если они, товары т.е., тянутся из 1С или еще какой учетной системы), все равно есть масса гитик, о которых надо думать (в идеальном мире, где разработчик имеет не только "закрыть задачу в спринте"), иначе пришедший потом, когда уже мало что можно исправить, SEO-спец вспоминает этих ХХПшников тихим матерным словом.
А "змейка" БД и требует, так что "незачет, придете на пересдачу"
Вы как бы говорите мне о том, что развернуть облачный pg клустер что бы хранить результаты локальной змейки очень современно, и приводит к тому, о чем пишет уважаемый pg_expecto?
Нет, чтобы советовать такое я еще достаточно здоров.
Я писал только о целесообразности, эффективности и применимости <подсставить что угодно по выбору> (ну и немного о том, что примеры и аналогии должны быть более прозрачными и иметь связь хотя бы некую с телом обсуждения: это у упоминаю змейки, которая к задачам DBA чуть более, чем никак)
Вы так уверены, что именно я "не сталкивался" или "слишком поверхностно"? И на чем же основана ваша уверенность? Ну расскажите
@BoomerCore я тут скорее не про вас, а про тех, насчёт которых вы утверждаете:
Вам уже тут неоднократно объясняли, что если делать задачу правильно (ваш пример), то экономия "на спичках" даст настолько незначительный эффект ускорения
А по поводу подобных комментариев, именно такое впечатление и сложилось. Когда человек не пробовал, не знает какие сейчас возможности у нейросетей, и результаты какого качества они могут давать, но предполагает, что заведомо не могут ничего полезного сгенерировать, и пишет комментарии отталкиваясь от своих теоретических размышлений. А уверенность моя в этом основана, повторюсь, на личном практическом опыте.
Я уже несколько раз здесь писал, что именно декомпозируя "собственным интеллектом" задачи на мелкие, и делегируя их ИИ, и то не все, а те в которых экономия времени будет существенной, при том что процесс включает не только написание промпта, но и проверку результата, то общая экономия будет тоже существенной. И опять же, это личный практический опыт, а не предположения. И нет, не по ХХП.
Shit in - shit out согласен, об этом я и в статье пишу:
Чем подробнее и точнее будет текстовый промпт, тем лучше будет результат
Всё очень просто: или ты как надсмотрщик отдаёшь приказы роботу при уборке квартиры, или ты убираешься сам. А выигрыш для бизнеса как обычно: время. Может быть силы надсмотрщика, что тоже деньги. И вам правильно говорят: надо применять инструменты там где они нужны, а не везде скопом.
Rikkster, давайте по шагам полный пример "в студию", а там конкретно и поговорим!
Пример чего конкретно вы желаете, могу полюбопытствовать?)
Конкретный пример проектирования реляционной схемы БД с помощью AI от начального формулирования требований (постановки задачи) и с дальнейшей детализацией всех шагов до получения конечного результата. Можно взять пример с небольшой БД в которой ~3-5 таблиц и с отношениями "один ко многим" и "многие ко многим". Потом мы его с Вами и обсудим.
Два скриншота из статьи как раз пример такого "сферического коня в вакууме", автор считает (вероятно), что на этом проектирование закончено.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
И как найти этот ИИ для БазаДанных
Где ссылка на ИИ, оно бесплатно?
Статью я бы переименовал в: "Как ИИ помогает проектировать базы данных начинающему разработчику".
Опытный разработчик вряд ли захочет запускать на свою бд-"вотчину" современный ИИ, за которым потом придётся разгребать авгиевы конюшни потока сознания...
В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
Отличная статья. Полностью согласен с тем, что ИИ помогает значительно ускорить процесс разработки. Возможность быстро получить развёрнутый ответ на редкий или необычный вопрос, вместо того, чтобы часами шерстить форумы - делает его бесценным инструментом даже в руках опытного разработчика.
Благодарю за комментарий! Рад, что статья понравилась!
А то тут налетели ненавистники ИИ и айда тухлыми помидорами кидаться) Я уж в один момент подумал не зря ли я написал статью))
Здесь нет "ненавистников ИИ" (который и не ИИ, а всего-то LLM), а только лишь суровые рационалисты — работа такая. На мой вопрос "где вам Курсор косяк упорол в структуре, который нормальный миддл не пропустит?", вы, любезный, так и не ответили. А деградацию производительности потом будут по вашей БД править другие, не LLM-фицированные
где вам Курсор косяк упорол в структуре, который нормальный миддл не пропустит?
вы сами поняли что написали?
Здесь нет "ненавистников ИИ" (который и не ИИ, а всего-то LLM), а только лишь суровые рационалисты — работа такая.
Прикола ради , вот ответ нейросети на вопрос "подбери реальные примеры для СУБД PostgreSQL для общей темы "используя известный тезис о 5 стадиях принятия неизбежного , на какой стадии сейчас находится массовое IT сообщество в принятии использования нейросетей в обычной практике для IT специалиста ?""
-------------------------------------------------------------------------------------
Анализируя текущие тенденции в IT-сообществе, особенно среди специалистов по базам данных, можно сделать вывод, что в целом оно находится на стадии «Торга». Сообщество активно экспериментирует с нейросетями как с инструментом, нащупывая его границы и практическую пользу, но еще не пришло к массовому и безоговорочному «Принятию».
Если применить модель Кюблер-Росс к IT-сообществу в контексте нейросетей и PostgreSQL, то разные группы специалистов демонстрируют признаки всех стадий одновременно.
Вот как это выглядит на практике с примерами из области PostgreSQL:
1. Отрицание
Суть: Восприятие нейросетей как незрелой технологии, неспособной решать сложные задачи в такой консервативной и критически важной сфере, как СУБД.
Пример для PostgreSQL: Убеждение, что классический оптимизатор запросов, основанный на статистике и проверенных эвристиках, всегда превосходит «черный ящик» нейросети в надёжности и предсказуемости. Ядро PostgreSQL не включает и не планирует в ближайшем будущем включать нейросетевые оптимизаторы, что для части сообщества является подтверждением правильности их позиции.
2. Злость
Суть: Раздражение от ошибок и неоправданных ожиданий, страх перед бездумной заменой проверенных практик.
Пример для PostgreSQL: Критика нейросетевых моделей за систематические ошибки в прогнозировании производительности под нагрузкой. Например, эксперименты показывают, что нейросеть может игнорировать такие факторы, как динамическое кэширование данных в памяти (shared_buffers) или конкуренцию за блокировки индексов при высокой параллельной нагрузке, выдавая неверные рекомендации. Это вызывает скепсис и защитную реакцию у опытных администраторов.
3. Торг (доминирующая стадия в данный момент)
Суть: Активные поиски ниши, где нейросети могут быть полезны прямо сейчас, без претензий на революцию.
Примеры для PostgreSQL:
Исследовательские проекты: Разработка нейронных оптимизаторов запросов (MSCN, DQ, NEO), которые учатся предсказывать кардинальность или строить оптимальные планы выполнения, демонстрируя потенциал на этапе исследований.
Внешние инструменты анализа: Обсуждение и создание прототипов внешних AI-инструментов (например, на Python), которые анализируют метрики (
pg_stat_statements), дают рекомендации по настройке индексов илиwork_mem, но не встраиваются в ядро СУБД.Автоматизация рутины: Использование языковых моделей (ChatGPT, GigaChat) для генерации шаблонных SQL-запросов, написания простых скриптов на PL/pgSQL или объяснения сложных планов выполнения.
4. Депрессия
Суть: Осознание масштаба изменений и временное ощущение, что фундаментальные навыки могут обесцениться.
Пример для PostgreSQL: Размышления о том, не сделают ли нейросети в будущем менее востребованными глубокое знание внутренней механики планировщика запросов или тонкой ручной настройки. Вопрос о целесообразности доклада по нейросетям на профильную конференцию (PgConf) может отражать сомнения в актуальности таких «экспериментальных» тем для практикующих специалистов.
5. Принятие
Суть: Нейросети интегрируются в рабочий процесс как один из многих профессиональных инструментов.
Примеры для PostgreSQL:
Готовые коммерческие решения: Использование адаптивных оптимизаторов на базе машинного обучения, которые уже являются частью коммерческих дистрибутивов (например, AQO в Postgres Pro).
Инструмент бизнес-аналитики: Интеграция нейросетевых моделей в платформы для работы с данными (например, GigaChat API от Сбера) для автоматической генерации отчетов, трансляции данных или анализа бизнес-процессов, где в качестве источника данных может выступать PostgreSQL.
💎 Заключение
IT-сообщество, и в частности специалисты вокруг PostgreSQL, находятся в активной фазе «Торга». В этой фазе нейросети воспринимаются не как замена, а как потенциальный вспомогательный инструмент для конкретных задач: оптимизации сложных запросов, анализа метрик или автоматизации рутины. Переход к стадии «Принятия» требует времени, практических доказательств надёжности и чёткого определения границ, где нейросети дополняют, а не вытесняют экспертизу человека.
Если вас интересуют конкретные технические детали работы адаптивного оптимизатора AQO или примеры промптов для языковых моделей при работе с SQL, я могу предоставить более подробную информацию.
Хабр – стадия "ненависть" ко всем кто пишет что нейросети могут как то помочь 😁
IMHO нейросеть в общем то ни при чем. Хабр всегда таким был. Даже когда ИИ еще был в мечтах энтузиастов.
Тема кармы молота перемолота мильон раз.
Хабр в общем то ничем не отличается от реального мира, такой же слепок - "агрессивное меньшинство". Примеров в реальном мире чуть больше чем до..., в общем много.
Ситуация ведь если вдуматься абсурдная с точки зрения здравого смысла - берем какую нибудь статью с кучей минусов - смотрим количество читателей. Затем статистику минусов . Отношение минусаторов к читателям меньше не то, что статистической погрешности а вообще как правило менее 1%. Основная масса читателей, прочитали и пошли дальше, кто-то может комментарий оставил.
Но минусатор он не такой - он и минус поставит и комментарий возмущенный напишет и еще будет искать автора по другим веткам других статей и там возмущаться. Если минусаторов набирается достаточное количество, то автору сливают карму - ату его он не такой как мы, он думает по другому, он верит в другое - сразу ограничивается возможность писать новые статьи - 1 статья в месяц, потом ограничивается возможность комментировать другие статьи.
В результате - все как в реальном мире - агрессивная очень малая часть читателей Хабра лишает возможность общаться с автором остальную значительно большую часть аудитории.
Повторюсь - Хабр совем не особенная какая то площадка - в реальном мире подобная ситуация сплошь и рядом.
В итоге - автор публикуется на других площадках , просмотры получают другие ресурсы (1000 просмотров в день для Хабра наверняка такие мелочи что модно и забить, хотя зачем поменяли показ статистики с прочтений на показы ? Предположу - цифры слишком уже не оптимистические получились по итогам года). Ну а Хабр, что Хабр - хорошая площадка для SEO , вполне себя оправдывает - цифра кармы и количество минусов под статьями поисковиками и нейросетями не учитываются вообще никак.
Так, что в общем то ничего особенного, жизнь продолжается, караван идет.
Вот приметно как то так.
Да, всё в точности так!
Исключительно в виде лингвистической шутки: у молота нет кармы. Я раза три перечитывал
Тема кармы молота перемолота мильон раз
Но потом мне доперло, "что хотел написать автор": иногда дефис это не просто дефис, а целая коллекция смыслов
При согласии с общим посылом позволю себе только не согласиться с существительным "меньшинство" (про минусаторов): пока технически мы не можем оценить соотношение когорт отношений "отрицательное" / "нейтральное" / "положительное", пока одно из этих действий не является обязательным (привет Древней Греции и ее "идиотам") и учитывая даже неравновесность голосования: "вверх" некоторые могут делать +2, вниз — только -1. Но да, что карма используется как именно инструмент тоталитарного давления и затыкания рта тем, кто "не как все" . Вот тут на примере меня все просто прелестно видно: "смеешь думать своей головой — молчи, холоп!" Про грубость - пока мои комментарии не так обильны, их можно просмотреть и понять, насколько снежинкой надо быть, что с них начать таять. И да, кармасрач тут начинать не надо: их было много, они все бесполезны, потому что имеем охлократию в классическом виде, и кто же сам отдаст власть по доброй воле?!
17 дек в 12:36 -1 Придерживаюсь другой позиции. Личная неприязнь
17 дек в 01:29 -1 Грубое общение. Придерживаюсь другой позиции
17 дек в 01:29 -1 Неконструктивное общение
15 дек в 03:15 -1 Придерживаюсь другой позиции
11 дек в 14:34 -1 Неконструктивное общение
11 дек в 13:44 -1 Грубое общение. Неконструктивное общение
11 дек в 13:38 -1 Грубое общение. Неконструктивное общение
ИИ есть и использовать его в качестве расширения возможностей—нормально. Мы же не отказываемся от автомобилей в пользу лошадей. Негативно, если человек многое делигирует ИИ, научно уже доказано, что такие люди глупеют, потому что перестают думать и вспоминать когда-то усвоенное.
Как ИИ помогает проектировать базы данных