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

Question

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

Я не очень знаком с тем, как работать и обновлять реляционную базу данных после ее развертывания. Я разрабатываю небольшой проект для домашних животных, над которым я планирую потренироваться Release Early, Release Часто , и мне интересно, стоит ли мне рассматривать данные, которые не будут использоваться в первоначальном выпуске, находится в списке запланированных функций? Легко ли добавлять таблицы и схемы, как добавлять новые классы? Или я должен попытаться настроить таблицы для вещей, которые я мог бы использовать, но не планирую в ближайшем будущем?

Answer 1

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

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

Answer 2

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

Answer 3

Если у вас хорошее тестирование для базы данных, я бы расширил YAGNI до вашего дизайна базы данных.

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

Answer 4

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

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

Но вот для чего они здесь.

Answer 5

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

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

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

Настроить схему не так просто, как добавить класс, но это выполнимо.

Таким образом, в целом, YAGNI все еще применяется.