Эта преждевременная оптимизация означает, что вы не должны оптимизировать вообще. Я видел более ужасно плохие базы данных, потому что никто не хотел рассматривать производительность (критическую для любой системы баз данных) при проектировании, поскольку это было преждевременной оптимизацией, чем любая другая проблема проектирования базы данных. Мусор, есть известные убийцы производительности, прекратите использовать их в качестве первого выбора.
Другой миф, слишком сложно реорганизовать базу данных. Нет, но вы должны подумать, как сделать рефакторинг на этапе проектирования, чтобы сделать это эффективно. И кстати, чем дольше вы будете ждать, чтобы решить эту досадную проблему с проектной производительностью, тем труднее будет ее решить.
Еще один плохой миф, дизайн базы данных должен отражать принципы ООП. Нет, базы данных предназначены для работы с наборами, а не с принципами ООП. Некоторые ООП вызывают ужасные проблемы с производительностью, а другие просто глупы в терминах базы данных.
Наконец, вы должны обеспечить целостность данных в приложении. Базы данных прослужат дольше прошлого приложения и потеряют правила при замене приложения, несколько приложений получат к ним доступ, и часто возникает необходимость запуска прямых запросов для исправления вещей, которые не проходят через приложение. Я никогда не видел базы данных, которая отказывается обеспечивать целостность данных в базе данных, которая имеет хорошие данные.