С теоретической точки зрения вы абсолютно правы: в классических реляционных СУБД (PostgreSQL, MySQL) механизмы, которые мы называем "вертикальным секционированием", по факту реализуются через декомпозицию таблиц (нормализацию), что перекладывает часть ответственности за атомарность создания связей на прикладной уровень или триггерную логику.
Однако в стоит разделить два аспекта:
Терминологический: Почему это называют секционированием, а не просто "перестройкой структуры"? В контексте Highload-систем термин "секционирование" (partitioning) чаще относится к стратегии оптимизации IOPS и памяти. Если мы выносим редко используемые BLOB или тяжелые TEXT поля в отдельную таблицу, чтобы уменьшить размер основной "горячей" таблицы и ускорить Full Table Scan / Index Scan — мы решаем задачу физического размещения данных, а не логического моделирования. Именно поэтому закрепился термин "вертикальное секционирование" — как описание цели действия, а не механизма СУБД.
Проблема эквивалентности схем: Ваше замечание про утрату NOT NULL через связь 1:1 абсолютно обосновано - в классическом SQL действительно нет нативного механизма "Deferred Check" для перекрестных внешних ключей, который бы гарантировал транзакционную вставку в две таблицы как в одну "атомарную" сущность на уровне схемы.
Примечание: В PostgreSQL это частично решается через DEFERRABLE INITIALLY DEFERRED внешние ключи, но это всё равно требует двух операций вставки в рамках одной транзакции.
Вы правы в том, что "нативного" вертикального секционирования (как прозрачного для пользователя механизма, аналогичного горизонтальному декларативному секционированию в PG 11+) в мейнстримных РСУБД практически нет. То, что мы имеем — это "рукотворный" паттерн.
Но называть это "просто перестройкой" тоже не совсем полно, так как цель здесь не нормализация ради чистоты данных, а управление физическим слоем хранения. Мы осознанно меняем "гарантии целостности на уровне схемы" на "производительность и масштабируемость", что является типичным архитектурным компромиссом (trade-off).
Но это не попало в мои первые 3 действия. Можно объяснять пользователю, что возможность была, но какой смысл, если он уже ушёл. Эта статья нужна чтобы обратить внимание на важность получения обратной связи от пользователей, и на проверку багов, а не для того чтобы убедить, что в Кошельке невозможно найти способ связаться с поддержкой.
Действительно интересная статья, и вправду нужно использовать ИИ чтобы обрести суперсилу, а не бояться, что ИИ заменит. Пускай заменяет и ускоряет рутину! И более того – сейчас особо выбора нет, можно бояться, а можно учиться использовать ИИ чтобы быть эффективным. Если не учиться – обгонят. И именно учиться, т.к. не умея пользоваться ИИ, можно даже ухудшить рабочий процесс 🧐 Но как говорится – это не rocket science, главное действовать, изучать, применять.
В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
Стирать это хорошо. Это гораздо лучше чем не стирать. На этапе доски ошибки почти бесплатны. Любая пойманная ошибка экономит море денег.
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Фотографии доски после совещаний это вообще ценный артефакт. Он вероятно поможет кому-то через 10 лет понять как до такого дошли.
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
Когда БД спроектирована человек садится и пишет create table под все что придумали и согласовали.
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
А сколько БД крупных (допустим от человекогода на разработку бекенда) прод сервисов вы спроектировали? Я несколько.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Более того. в развитие темы — если он, как проверенный ценнейший специалист, для рисования моков запросит спины белых девственниц, то вопрос будет не "а зачем это тебе надо?", а "какую площадь обеспечить единовременно?"
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
Инструмент не важен, важно — решается задача или нет.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Чисто теоретический вопрос - вы представляете себе, что такое НФ? От 3 до 6? И как одна физическая сущность может развертываться в произвольное число таблиц и всего прочего, описывающего ее? А связи сущностей? Нарезать это в отдельные промты? Ну, удачи
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.
Верно! В любом случае лично я счёл статью достаточно интересной и полезной, потому и опубликовал её переведённую на русский язык версию.
С теоретической точки зрения вы абсолютно правы: в классических реляционных СУБД (PostgreSQL, MySQL) механизмы, которые мы называем "вертикальным секционированием", по факту реализуются через декомпозицию таблиц (нормализацию), что перекладывает часть ответственности за атомарность создания связей на прикладной уровень или триггерную логику.
Однако в стоит разделить два аспекта:
Терминологический: Почему это называют секционированием, а не просто "перестройкой структуры"? В контексте Highload-систем термин "секционирование" (partitioning) чаще относится к стратегии оптимизации IOPS и памяти. Если мы выносим редко используемые
BLOBили тяжелыеTEXTполя в отдельную таблицу, чтобы уменьшить размер основной "горячей" таблицы и ускорить Full Table Scan / Index Scan — мы решаем задачу физического размещения данных, а не логического моделирования. Именно поэтому закрепился термин "вертикальное секционирование" — как описание цели действия, а не механизма СУБД.Проблема эквивалентности схем: Ваше замечание про утрату
NOT NULLчерез связь 1:1 абсолютно обосновано - в классическом SQL действительно нет нативного механизма "Deferred Check" для перекрестных внешних ключей, который бы гарантировал транзакционную вставку в две таблицы как в одну "атомарную" сущность на уровне схемы.Примечание: В PostgreSQL это частично решается через
DEFERRABLE INITIALLY DEFERREDвнешние ключи, но это всё равно требует двух операций вставки в рамках одной транзакции.Вы правы в том, что "нативного" вертикального секционирования (как прозрачного для пользователя механизма, аналогичного горизонтальному декларативному секционированию в PG 11+) в мейнстримных РСУБД практически нет. То, что мы имеем — это "рукотворный" паттерн.
Но называть это "просто перестройкой" тоже не совсем полно, так как цель здесь не нормализация ради чистоты данных, а управление физическим слоем хранения. Мы осознанно меняем "гарантии целостности на уровне схемы" на "производительность и масштабируемость", что является типичным архитектурным компромиссом (trade-off).
😁 юмор же тоже должен присутствовать в статье, чтобы не скучно было читать такую стену текста
вам плюсик за внимательность к пасхалкам ✅
Небольшой кнопки в подвале каждого экрана было бы достаточно.
Но это не попало в мои первые 3 действия. Можно объяснять пользователю, что возможность была, но какой смысл, если он уже ушёл. Эта статья нужна чтобы обратить внимание на важность получения обратной связи от пользователей, и на проверку багов, а не для того чтобы убедить, что в Кошельке невозможно найти способ связаться с поддержкой.
Рад привествовать, уважаемый
Прошёлся по тексту ещё раз, благодарю за замечание
Они такие :-)
Я смотрю тут под каждой статьёй не дадут расслабиться господа орфографисты-пунктуологи! Бдят изо всех сил!
Я стараюсь писать грамотно, правда! :D
Действительно интересная статья, и вправду нужно использовать ИИ чтобы обрести суперсилу, а не бояться, что ИИ заменит. Пускай заменяет и ускоряет рутину! И более того – сейчас особо выбора нет, можно бояться, а можно учиться использовать ИИ чтобы быть эффективным. Если не учиться – обгонят. И именно учиться, т.к. не умея пользоваться ИИ, можно даже ухудшить рабочий процесс 🧐 Но как говорится – это не rocket science, главное действовать, изучать, применять.
Да, всё в точности так!
Хабр – стадия "ненависть" ко всем кто пишет что нейросети могут как то помочь 😁
Вы напишите свой вопрос так чтобы его нормальные люди поняли
Какой курсор? Какая структура? Какой косяк? Куда упорол?))
вы сами поняли что написали?
Благодарю за комментарий! Рад, что статья понравилась!
А то тут налетели ненавистники ИИ и айда тухлыми помидорами кидаться) Я уж в один момент подумал не зря ли я написал статью))
Я не хочу чтобы меня блокировали за рекламу. В правилах написано — упоминать название можно, ссылки давать нельзя. Так что это я не из вредности...
В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Кто такой Клод?) Я Андрей Рик 🤠
Полностью согласен с вышеописанным
В статье указано название инструмента, попробуйте его найти самостоятельно в поисковиках.
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.