Я немного смущен тем, как процесс разработки приложения на базе базы данных. Я использую Java-язык и реляционную базу данных. Каков правильный способ перебора процесса разработки объектно-ориентированного приложения на базе базы данных, такого как «управление управлением запасами». Разработка схемы базы данных, после чего выполняется OOD или наоборот.Объектно-ориентированный дизайн и процесс проектирования базы данных
Поскольку я предполагаю, что вы собираетесь использовать традиционную СУБД, из моего собственного опыта лучше всего сначала разработать схему базы данных: подумайте обо всех таблицах, которые вам нужны для хранения вашей информации, подумайте об отношениях между их (внешние ключи).
Следующий шаг должен заключаться в написании самого приложения. Я предполагаю, что вы собираетесь использовать Java, и можете воспользоваться дизайном ООП.
В таком случае я настоятельно рекомендую использовать технологию ORM, такую как Hibernate, для выполнения взрыва между вашим дизайном приложений ООП и дизайном РСУБД. Хотя это не обязательно, поскольку вы можете использовать простой подход JDBC.
По моему опыту, разработка этого способа намного меньше времени, чем вначале спроектировать ваше приложение высокого уровня OOP, а затем попытаться установить схему БД на него, потому что обычно возиться с БД более дорогостоящим, чем с высоким уровнем ООП-абстракция.
Существует несколько различных подходов, и каждый из них имеет свои достоинства и недостатки.
Если вы придерживаетесь подхода ORM и используете такой инструмент, как Hibernate, вы можете скрыть большую часть реализации базы данных. Вы продолжите работу с OOD, и схема базы данных выпадет из этого. ORM, такие как Hibernate, даже генерируют схему для вас (это очень полезно при тестировании, поскольку вы можете создавать базу данных в памяти на лету для своих тестов).
Преимущества этого подхода состоят в том, что вы можете сосредоточиться на OOD и работать с «тонкими срезами», где схема базы данных генерируется по мере вашего продвижения. Это хорошо вписывается в гибкий подход.
Недостатком подхода ORM является то, что он не может привести к оптимизации схемы базы данных. Например, производительность вашей схемы базы данных может быть не такой хорошей, как если бы вы больше сосредоточились на дизайне схемы.
Если вы решили сосредоточиться на дизайне базы данных, вы можете потратить время на его оптимизацию для повышения производительности и других нефункциональных требований (таких как масштабируемость и аудит). Недостатком такого подхода является то, что он может ограничивать то, как вы делаете OOD в своем коде, и может быть труднее работать в итеративном режиме, предпочитаемом гибким.