Это возможно, но крайне маловероятно.
Context
Во-первых, во времена, когда появилась реляционная модель, люди, работавшие в сфере ИТ, были более образованными и уважали стандарты. Компьютерные ресурсы были дорогими, и люди всегда искали лучший способ использовать эти ресурсы. Такие люди, как Кодд и Дейт, были гигантами в индустрии, где люди занимались высокими технологиями.
Кодд не придумал нормализацию, мы нормализовали наши нереляционные базы данных задолго до появления реляционных. Нормализация - это теория и практика, опубликованные как Принцип полной нормализации. Мы нормализовали наши программы, мы посчитали случайное дублирование субротина (метода) серьезной ошибкой. В настоящее время он известен как «Никогда не дублируй что-либо» или «Не повторяй себя», но последние версии не признают обоснованную академическую теорию, лежащую в основе, и поэтому его сила не реализована.
То, что сделал Кодд (среди многих вещей), определило формальные нормальные формы специально для реляционных баз данных. И с тех пор они развивались и совершенствовались. Но они также были похищены не академиками с целью продажи своего снаряжения.
Моделирование базы данных, которое было изобретено Коддом и Ченом и завершено Брауном, имело прочное основание. За последние 25 лет он достиг Стандартизации и был доработан и усовершенствован многими другими, у которых было прочное заземление.
Мир перед ОО
Давайте возьмем мир программирования до ОО. У нас было много стандартов и соглашений для моделирования наших программ, а также для реализации на уровне языка и платформы. Ваш вопрос просто не будет применяться в те дни. Вся отрасль глубоко понимала, что разработка баз данных и разработка программ - это две разные науки, и для них использовались разные методологии моделирования, а также применяемые стандарты. Люди не обсуждали , если они применяли стандарты, они обсуждали степень, в которой они соблюдали стандарты; они не обсуждали , если они моделировали свои данные и программы, они обсуждали степень, в которой они моделировали свои данные и программы. Именно так мы отправляем людей на Луну, особенно в 1969 году.
Рассвет ОО
ОО пришел и представил себя так, как будто до него не существовало никакого другого языка программирования или методологии проектирования. Вместо того чтобы использовать существующие методологии и расширять или изменять их, он отрицал их существование. Таким образом, неудивительно, что потребовалось 20 лет, чтобы сформулировать новые методологии с нуля и постепенно продвигать их до уровня SOLID и Agile, который не является зрелым; причина вашего вопроса. Это говорит о том, что за это время вспыхнуло и умерло более двадцати таких методологий.
Даже UML, который мог бы быть абсолютным победителем, применимым к любому языку программирования, страдал от той же болезни. Он пытался быть всем для всех, отрицая существование зрелых методологий.
Конец индустрии
С появлением РС отношение «каждый может делать все» (подразумевается: вам не нужно формальное образование или квалификация), что качество и гордость профессии утрачены. Люди теперь изобретают вещи с нуля, как будто никто на планете никогда не делал этого раньше. ИТ-индустрия сегодня очень низкая технология. Вы знаете, но большинство людей, читающих эти страницы, не знают, что существует одна методология реляционного моделирования и один стандарт. Они не моделируют, а реализуют. Затем заново внедрите. И заново внедрить. Рефакторинг, как вы говорите.
OO Сторонники
Проблема заключалась в том, что люди, которые придумали эти методы ОО, не были гигантами среди профессионалов; они были просто самыми громкими из неакадемических партий. Известен благодаря публикации книг, а не благодаря признанию со стороны сверстников. Неквалифицированный и не осведомленный . В их наборе было One Hammer , и каждая проблема выглядела как гвоздь. Поскольку они не были формально образованы, они не знали, что на самом деле дизайн базы данных и разработка программы - это две разные науки; этот дизайн базы данных был достаточно зрелым, имел четко установленные методологии и стандарты, и они просто применили свой новый блестящий молоток к каждой проблеме, включая базы данных.
Поэтому, поскольку они игнорировали как методологии программирования, так и методологии баз данных, изобретая колесо с нуля, эти новые методологии развивались очень медленно. И с помощью такой же толпы, без хорошей академической основы.
Программы сегодня имеют сотни методов, которые не используются. Теперь у нас есть программы, чтобы обнаружить это. Принимая во внимание, что со зрелыми методологиями мы предотвращаем это. Тонкий клиент не был целью, которую нужно было достичь, у нас была наука, которая его создала. Теперь у нас есть программы для обнаружения «грязных» данных и их «очистки». В то время как на верхнем уровне рынка баз данных мы просто не допускаем «грязных» данных в базу данных.
Я принимаю, что вы рассматриваете дизайн базы данных как серию рефакторинга, я понимаю, что вы имеете в виду. Для меня это наука (методология, стандарты), которая исключает необходимость повторного анализа. Даже принятие ре-факторинга является громким сигналом того, что более старые методологии программирования неизвестны; что нынешние методологии ОО являются незрелыми. Опасность того, что раздражает работать с ОО-персоналом, заключается в том, что сама методология воспитывает уверенность в менталитете One Hammer, а когда код нарушается, у них не остается ни одной ноги; когда система ломается, вся система ломается, это не одна маленькая деталь, которую можно починить или заменить.
Возьми Скотта Эмблера и Ловкого. Эмблер провел 20 лет публично и громко, споря с гигантами индустрии баз данных, против Нормализации. Теперь у него есть Agile, который, хотя и незрелый, имеет обещание. Но секрет за этим это нормализация. Он поменял треки. И из-за своих прошлых войн он не может выйти и заявить об этом честно и отдать должное другим, поэтому это остается секретом, и вам остается вычислить Agile без объявления его основ.
Прогноз
Вот почему я говорю, учитывая очевидный небольшой прогресс в мире ОО за последние 20 лет; 20 или около того ОО методологии, которые потерпели неудачу; При поверхностном подходе весьма маловероятно, что существующие методологии ОО достигнут зрелости и будут принимать (единственную) методологию проектирования баз данных. Это займет, по крайней мере, еще 10 лет, более вероятно, 20, и это будет заменено некоторой заменой ОО.
Чтобы это было возможно, должны произойти две вещи:
Сторонникам ОО необходимо формальное высшее образование. Хорошая основа в науке программирования. Конечно, каждый может сделать что угодно, но чтобы делать великие дела, нам нужно хорошее заземление. Это приведет к пониманию того, что рефакторинг не является необходимым, что он может быть устранен наукой.
Они должны прекратить свое отрицание других методологий и стандартов программирования. Это откроет дверь либо к созданию ОО на вершине этого, либо к принятию основ этого и слиянию его с ОО. Это приведет к твердой и полной ОО методологии.
Real World OO
Очевидно, я говорю из опыта. В наших крупных проектах мы используем зрелые методологии анализа и проектирования, одну для базы данных, а другую для функции. Когда мы дойдем до стадии вырезания кода, мы позволим команде OO использовать все, что им нравится, только для своих объектов, что обычно означает UML. Никаких проблем с архитектурой, структурой, производительностью, раздувным ПО, One Hammer или сотнями неиспользуемых объектов, потому что все это было решено за пределами ОО. И позже, во время UAT, не было проблем с поиском источника ошибок или быстрым внесением необходимых изменений, потому что вся структура имеет документированную структуру; блоки можно изменить.