Относится ли YAGNI к проектированию баз данных?
В коде, как правило, довольно легко добавлять новые классы для обеспечения дополнительной функциональности и тому подобное. У меня достаточно хорошее понимание рефакторинга кода и того, что с ним связано, поэтому YAGNI, как правило, имеет для меня смысл.
С чем я не знаком, так это с работой и обновлением реляционной базы данных после ее развертывания. Я занимаюсь разработкой небольшого проекта для домашних животных, над которым планирую попрактиковаться в выпуске на ранней стадии , выпуске часто, и мне интересно, стоит ли мне рассматривать данные, которые не будут использоваться в первоначальном выпуске, но включены в список запланированных функций? Легко ли добавлять таблицы и схемы, как добавлять новые классы? Или я должен попытаться настроить таблицы для вещей, которые я мог бы использовать, но не планирую в ближайшем будущем?
8 ответов
Если у вас есть хорошее тестирование, которое попадает в базу данных, я бы расширил YAGNI до вашего дизайна базы данных.
В общем случае легко добавлять столбцы и таблицы, а также значительно проще удалять или изменять их. Учитывайте это при разработке таблиц (т. Е. Если у клиента может быть несколько пользователей, не добавляйте идентификатор пользователя в таблицу клиентов. Сделайте это правильно с первого раза).
Это отличный вопрос. Я лично обнаружил, что изменение схемы базы данных и преобразование всех данных в новое представление гораздо сложнее, чем рефакторинг кода. Фактически, настолько, что всякий раз, когда я запускаю проект, который будет использовать новую базу данных, мне всегда нужно время, прежде чем я сажусь и пишу какой-либо код, чтобы получить мою спецификацию как можно более тщательно. Это часто предполагает ожидание функций и включение их поддержки в базу данных, даже если я не планирую немедленно их реализовывать.
Вы могли бы быть немного более проворным с рефакторингом базы данных, если вы используете платформу или другой подобный уровень, который предоставляет механизм для изменения базы данных, но если вы пишете прямой SQL, то я бы рекомендовал инвестировать скромное количество время разработки и реализации схемы, которая с меньшей вероятностью потребует изменений в будущем.
Существует целый ряд гибких размышлений о разработке и реализации баз данных. Возможно, вам будет интересно ознакомиться с лучшими практиками на сайте http://www.agiledata.org/, чтобы узнать некоторые мысли Скотта Амблера по этому вопросу. Для себя я обычно позволяю дизайну базы данных расти по мере разработки приложения. Я редко создаю таблицы раньше времени. Исключениями могут быть такие вещи, как аудит и разрешения, вещи, которые затрагивают весь дизайн. Я подумаю о том, как реализовать эти вещи, даже если на самом деле я не создаю для них таблицы заранее. Сквозные аспекты действительно влияют на дизайн таблиц, даже если эти функции не всегда являются первыми.
Мое мнение таково, что YAGNI относится ко всему: к кодированию, проектированию баз данных, работе по дому (моя жена категорически не согласна со мной по этому поводу) и так далее.
Каждое приложение на основе СУБД, над которым я когда-либо работал, регулярно обновляло сценарий, так что это должно планироваться в процессах. Администраторам баз данных не понравится часть вашего предложения "часто публикуйте", так как для них это больше работы (или для вас, если это не база данных DBA).
Но для этого они и существуют.
Существует концептуальная основа для проектирования баз данных.
В классическом проектировании баз данных существует три модели: концептуальная, логическая и физическая.
Концептуальная модель возникает из анализа требований и развивается по мере развития основного предмета или понимания предмета. Концептуальная модель связывает элементарные данные с точки зрения формы и семантики, но не занимается такими вопросами, как составление таблиц.
Логическая модель использует реляционную модель данных. Он может быть выведен из концептуальной модели, но он также имеет дело с композицией отношений. Нормализация и другие вопросы композиции вступают в игру здесь. Логическая модель рассчитывает дизайн таблицы, а также запросы и обновления, которые будет выполнять приложение.
Физическая модель реализует отношения в виде таблиц, а также добавляет все другие функции, такие как индексы, табличные пространства и т. Д., Необходимые для фактического построения базы данных. Он основан на логической модели, но в игру вступают объем данных, нагрузка, производительность и дисковое пространство.
Это звучит долго и утомительно, но на самом деле это быстро, если вы знаете, как это сделать. Все это можно сделать за несколько недель, в то время как остальная часть команды все еще обсуждает функциональные спецификации. Для действительно небольшого проекта (6 таблиц, 50 столбцов) это можно сделать за несколько дней, всего лишь карандашом и бумагой. Для более крупных проектов существуют инструменты, которые делают дизайн более автоматическим, менее подверженным ошибкам и легко программируемым.
Но что происходит, когда вы обнаруживаете, что концептуальная модель была неточной или неполной, а две другие модели и саму базу данных необходимо изменить? Вот где Data Независимость приходит на помощь. Независимость данных делает для проектирования баз данных то же, что инкапсуляция для проектирования объектов. А именно, он предотвращает распространение незначительной корректировки в одном месте по всем объектам приложения. Объекты зависят только от данных, которые они используют.
Если в схему необходимо добавить новую таблицу, вероятность того, что какое-либо приложение будет сломано, исчезающе мала. Даже если необходимо изменить существующую таблицу, запросы, использующие только старые столбцы, не увидят никакой разницы. Даже когда объекты зависят от изменения, вы все равно можете присвоить измененной таблице новое имя, а затем создать представление со старым именем, которое будет выглядеть так, будто старая таблица все еще там.
И физическая независимость данных почти полна в хорошей СУБД. Вы можете реорганизовать данные, добавлять и удалять индексы и т. Д., И вам не нужно менять какие-либо приложения.
Короче говоря, управление изменениями может быть сделано блестяще с использованием действительно хороших продуктов СУБД. К сожалению, многие администраторы баз данных и программисты не знают, как адекватно использовать эти функции СУБД, хотя они существуют уже много лет.
Принцип все еще применяется. Вам не придется беспокоиться о добавлении полей в таблицы и т. Д., Пока у вас не будет много данных. Довольно много данных. Поэтому слишком рано и слишком рано беспокоиться о деталях индексации и планов запросов, не видя фактических данных, часто тратится время и даже позже возникают архитектурные проблемы.
К сожалению, разбираться с дизайном базы данных после производственного выпуска может быть довольно страшно, если не следовать хорошему процессу тестирования / выпуска. Таким образом, даже больше, чем код, вы хотите сделать это правильно с помощью базы данных.
С базами данных вы действительно хотите планировать получение данных, а также их размещение и хранение, поэтому, если ваши "запланированные" функции включают отчеты, это сильно повлияет на структуру базы данных, так что, возможно, планируйте это.
Настроить схему не так просто, как добавить класс, но это выполнимо.
В целом, YAGNI все еще применяется.
Дизайн базы данных похож на любой другой вид дизайна. Ваше понимание растет постепенно, и с лучшим пониманием приходит развивающаяся схема.
Хотелось бы, чтобы было проще объяснить, как на самом деле существует концептуальная основа для проектирования схемы реляционной базы данных. Единственный инструмент, который действительно моделирует это, это Object Role Modeling, которая появилась давно. Самым знакомым инструментом был Visiomodeler. Чтобы получить представление об этом, вот пара ссылок на Скотта Амблера и Скотта Беккера. Но можно сделать вывод, что утверждения типа объектного моделирования ведут непосредственно к конкретной реляционной логической модели; следовательно, схема должна будет меняться по мере изменения вашей концептуальной модели.
На практике ваши rdbms могут справиться с гибкостью, если вы действительно знакомы с выражениями преобразования; и это стоит того, чтобы стать хорошим в этом.
Примечание: я думаю, что методы избегания SQL, такие как LINQ и объектно-реляционные модели, будут просто препятствием для развития проекта. Я могу ошибаться Есть основания надеяться, что Microsoft Entity Framework будет охватывать моделирование объектов; но я видел только косвенные ссылки на возможность.
Не настраивайте столы, которые вам пока не нужны. Одна из причин YAGNI заключается в том, что вы не собираетесь заранее предсказывать правильные вещи, которые вам понадобятся. Вы можете легко добавлять новые таблицы, изменять существующие таблицы и т. Д., Когда вам нужно их изменить.
Хорошая структура должна иметь некоторые инструменты для выполнения миграций, которые позволяют вам легко и автоматически обновлять и понижать вашу базу данных. Если у вас это есть, и вы достаточно осторожно относитесь к своему дизайну, вы должны иметь возможность реорганизовать свой путь туда, где вам нужно, вместо того, чтобы пытаться придумать все, что вам когда-либо понадобится.