YAGNI относится к проектированию баз данных?

Это отличный вопрос. Я лично обнаружил, что изменение схемы базы данных и преобразование всех данных в новое представление гораздо сложнее, чем рефакторинг кода. Фактически, настолько, что всякий раз, когда я запускаю проект, который будет использовать новую базу данных, мне всегда нужно время, прежде чем я сажусь и пишу какой-либо код, чтобы получить мою спецификацию как можно более тщательной. Это часто подразумевает предвосхищение функций и включение их поддержки в базу данных, даже если я не планирую немедленно их реализовывать.

Возможно, вы сможете быть немного более проворным с рефакторингом базы данных, если используете фреймворк или другой подобный уровень, который предоставляет механизм для изменения базы данных, но если вы

Существует целый ряд гибких размышлений о разработке и реализации баз данных. Возможно, вам будет интересно ознакомиться с лучшими практиками на www.agiledata.org , чтобы узнать некоторые мысли Скотта Амблера по этому вопросу. Для себя я обычно позволяю дизайну базы данных расти по мере разработки приложения. Я редко создаю таблицы раньше времени. Исключениями могут быть такие вещи, как аудит и разрешения, вещи, которые затрагивают весь дизайн. Я подумаю о том, как реализовать эти вещи, даже если на самом деле я не создаю таблицы для них заранее.

Мое мнение таково, что YAGNI относится ко всему, кодированию, проектированию баз данных, работе по дому (моя жена не согласна со мной яростно об этом) и т. д.

Каждое приложение на основе СУБД, над которым я когда-либо работал, регулярно обновляло сценарий, так что это должно планироваться в процессах. Администраторам не понравится часть вашего предложения «частый выпуск», поскольку для них это больше работы (или для вас, если это база данных, отличная от DBA).

Но для этого они и нужны.

Существует концептуальная основа для проектирования базы данных.

В классическом проектировании базы данных есть три модели: концептуальная, логическая и физическая.

Концептуальная модель возникает из анализа требований и развивается поскольку основной предмет развивается или как понимание предмета развивается. Концептуальная модель связывает элементарные данные с точки зрения формы и семантики, но не занимается такими вопросами, как составление таблиц.

Логическая модель использует реляционную модель данных. Это может быть выведено из концептуальной модели, но это также касается состава отношений. Нормализация и другие вопросы композиции вступают в игру здесь. Логическая модель предполагает проектирование таблицы, а также запросы и обновления, которые будет выполнять приложение.

Физическая модель реализует отношения в виде таблиц, а также добавляет все другие функции, такие как индексы, табличные пространства и т. Д., Необходимые для фактического построения базы данных. , Он основан на логической модели, но объем данных, загрузка, производительность и дисковое пространство все играют роль.

Это звучит долго и утомительно, но на самом деле это быстро, если вы знаете, как это сделать. Все это можно сделать за несколько недель, в то время как остальная часть команды все еще обсуждает функциональные спецификации. Для действительно небольшого проекта (6 таблиц, 50 столбцов) это можно сделать за несколько дней, всего лишь карандашом и бумагой. Для более крупных проектов Существуют инструменты, которые делают дизайн более автоматическим, менее подверженным ошибкам и легко структурируемым.

Но что произойдет, когда вы обнаружите, что концептуальная модель была неточной или неполной, а две другие модели и саму базу данных необходимо изменить? Вот тут Data Независимость приходит на помощь. Независимость данных делает для проектирования баз данных то же самое, что инкапсуляция для проектирования объектов. А именно, он предотвращает распространение незначительной корректировки в одном месте по всем объектам приложения. Объекты зависят только от данных, которые они используют.

Если новая схема должна быть добавлена ​​в схему, шансы того, что любое приложение будет сломано, исчезающе малы. Даже если необходимо изменить существующую таблицу, запросы, использующие только старые столбцы, не увидят никакой разницы. Даже когда объекты зависят от изменений, вы все еще можете дать измененной таблице новое имя, а затем создать представление со старым именем, которое будет выглядеть так, будто старая таблица все еще там.

И физическая независимость данных почти полна в хорошей СУБД. Вы можете реорганизовать данные, добавлять и удалять индексы и т. Д., И вам не нужно менять какое-либо приложение.

Короче говоря, управление изменениями может быть сделано блестяще с использованием действительно хороших продуктов СУБД. К сожалению, многие администраторы баз данных и программисты не знают, как адекватно использовать эти функции СУБД, хотя они существуют уже много лет.

и вам не нужно менять какие-либо приложения.

Короче говоря, управление изменениями может быть сделано блестяще с использованием действительно хороших продуктов СУБД. К сожалению, многие администраторы баз данных и программисты не знают, как адекватно использовать эти функции СУБД, хотя они существуют уже много лет.

и вам не нужно менять какие-либо приложения.

Короче говоря, управление изменениями может быть сделано блестяще с использованием действительно хороших продуктов СУБД. К сожалению, многие администраторы баз данных и программисты не знают, как адекватно использовать эти функции СУБД, хотя они существуют уже много лет.

Принцип все еще применяется. Вам не придется беспокоиться о добавлении полей в таблицы и т. Д., Пока у вас не будет много данных. Довольно много данных. Поэтому слишком рано беспокоиться о деталях планов индексирования и запросов, не видя фактических данных, часто тратится впустую время и даже может привести к проблемам с архитектурой позже.

К сожалению, при проектировании базы данных после производственного релиза довольно страшно, если не следовать хорошему процессу тестирования / выпуска. Таким образом, даже больше, чем код, вы хотите, чтобы это было правильно с первого раза с базой данных.

С базами данных вы действительно хотите планировать вывод данных, а также их ввод и хранение, так что если вы «запланировали» «Функции включают в себя отчеты, которые сильно повлияют на дизайн базы данных, так что, возможно, планируйте это.

Не настраивайте таблицы, которые вам пока не нужны. Одна из причин, стоящих за YAGNI, заключается в том, что вы не будете заранее предсказывать правильные вещи, которые вам понадобятся. Вы можете легко добавлять новые таблицы, изменять существующие таблицы и т. Д., Когда вам нужно их изменить.

Хорошая структура должна иметь некоторые инструменты для выполнения миграций , которые позволят вам обновить и понизить вашу базу данных. легко и автоматически. Если у вас это есть, и вы достаточно осторожно относитесь к своему дизайну, вы должны иметь возможность реорганизовать свой путь туда, где вам нужно, вместо того, чтобы пытаться придумать все, что вам когда-либо понадобится, заранее.

Дизайн базы данных похож на любой другой вид дизайна. Ваше понимание постепенно увеличивается, и с улучшением понимания появляется развивающаяся схема.

Хотелось бы, чтобы было проще объяснить, как на самом деле существует концептуальная основа для проектирования схемы реляционной базы данных. Единственный инструмент, который действительно моделирует это, - Object Role Modeling, которая появилась давно. Самым знакомым инструментом был Visiomodeler. Чтобы почувствовать вкус этого, вот пара ссылок на Скотта Амблера и Скотта Беккера Но можно сделать вывод, что утверждения типа объектного моделирования ведут непосредственно к конкретной реляционной логической модели; следовательно, схема должна будет меняться по мере изменения вашей концептуальной модели.

На практике ваши rdbms могут справиться с небольшим сгибанием, если вы действительно знакомы с выражениями преобразования; и оно того стоит, чтобы в этом разбираться.

Примечание: я думаю, что методы избегания SQL, такие как LINQ и объектно-реляционные модели, просто будут препятствием для развития проекта. Я могу ошибаться Есть основания надеяться, что Microsoft Entity Framework будет охватывать моделирование объектов; но я видел только косвенные ссылки на эту возможность.

следовательно, схема должна будет меняться по мере изменения вашей концептуальной модели.

На практике ваши rdbms могут справиться с небольшим сгибанием, если вы действительно знакомы с выражениями преобразования; и оно того стоит, чтобы в этом разбираться.

Примечание: я думаю, что методы избегания SQL, такие как LINQ и объектно-реляционные модели, просто будут препятствием для развития проекта. Я могу ошибаться Есть основания надеяться, что Microsoft Entity Framework будет охватывать моделирование объектов; но я видел только косвенные ссылки на эту возможность.

следовательно, схема должна будет меняться по мере изменения вашей концептуальной модели.

На практике ваши rdbms могут справиться с небольшим сгибанием, если вы действительно знакомы с выражениями преобразования; и оно того стоит, чтобы в этом разбираться.

Примечание: я думаю, что методы избегания SQL, такие как LINQ и объектно-реляционные модели, просто будут препятствием для развития проекта. Я могу ошибаться Есть основания надеяться, что Microsoft Entity Framework будет охватывать моделирование объектов; но я видел только косвенные ссылки на эту возможность.

Я думаю, что методы избегания SQL, такие как LINQ и объектно-реляционные модели, будут просто препятствием для развития проекта. Я могу ошибаться Есть основания надеяться, что Microsoft Entity Framework будет охватывать моделирование объектов; но я видел только косвенные ссылки на эту возможность.

Я думаю, что методы избегания SQL, такие как LINQ и объектно-реляционные модели, будут просто препятствием для развития проекта. Я могу ошибаться Есть основания надеяться, что Microsoft Entity Framework будет охватывать моделирование объектов; но я видел только косвенные ссылки на эту возможность.