За исключением самых строго определенных приложений, я не уверен, что вы можете разработать схему, которая не сильно изменится. То, что вы можете сделать, это сделать схемы, которые не являются хрупкими, схемы, которые позволяют изменения происходят. По большей части это означает.
- Включите только те данные, которые вам нужны для удовлетворения сегодняшних требований
- Нормализовать.
- Написание автоматических тестов.
Первое правило сродни «делать самые простые вещи» или «вам это не понадобится» - правило, которое программисты используют, чтобы избежать раздувания кода. Меньшие схемы, такие как меньшие базы кода, требуют меньше усилий для изменения. Второе (нормализовать) аналогично принципу «Не повторяйся» (СУХОЙ), также известному как «один раз и только один раз», - другое правило, используемое для того, чтобы сделать код более дешевым для изменения. Третье правило (тесты) - это то, как программисты делают возможным рефакторинг, не беспокоясь о том, чтобы все сломать. Под тестами я имею в виду тестирование кода, который использует схему, но также и тестирование самой схемы: триггеры, правила, каскадное удаление и т. Д. могут быть проверены, и при тестировании их легче изменить в ответ на изменяющиеся требования.
В мире баз данных существуют оправдания для нарушения этих правил. Причина, по которой нарушается правило 1 (выполните простейшую вещь / YAGNI), заключается в том, что некоторые данные будет легче собирать с самого начала, а их будет сложно или даже невозможно собрать, если вы решите, что они вам понадобятся позже. Тем не менее, подумайте дважды, прежде чем поддаться этому оправданию. Вы можете почти всегда без особых проблем справляться с пробелами в данных, вызванными добавлением столбцов или таблиц позже, но если вы включите данные за сегодня, которые вам могут понадобиться только завтра, вы будете платить за них каждый раз, когда меняете схему. Каждый бит данных, который вы включаете и который вам в итоге не нужен, был ничем иным, как затратами без выгоды. Возможно, еще важнее то, что дополнительные данные могут оказать ужасное влияние на производительность, поскольку они уменьшают количество записей, которые могут поместиться в памяти. Несмотря на то, что базы данных прилагают большие усилия, чтобы обеспечить хорошую производительность при чтении с диска, их лучшая производительность достигается при наличии достаточного количества памяти (или достаточного количества данных), чтобы весь или большая часть рабочего набора помещалась в ОЗУ.
Поводом для нарушения правила 2 (нормализации) является производительность: приложения «хранилища данных» иногда требуют денормализации в тех случаях, когда объединения с несколькими таблицами делают базу данных медленной и капризной. Я хотел бы быть уверен, что это было необходимо перед денормализацией, поскольку он не бесплатный: данные, которые существуют более чем в одном месте, усложняют изменение схемы и уступают скорости запросов для дополнительной работы при вставке и обновлении.
Я не знаю оправдания за нарушение правила 3 (тестирование) или, по крайней мере, за ненадобностью, но это не значит, что его нет.
Мартин Фаулер пишет "Эволюционный дизайн базы данных" . У Скотта Эмбер и Прамода Садалажа есть книга по Рефакторинг баз данных . См. Также резюме / шпаргалку по рефакторингу книги .