Дизайн класса против Db Design (ER-диаграмма)

Question

На этапе проектирования системы, должен ли дизайн класса диктовать дизайн БД или дизайн БД диктует дизайн класса. Я понимаю, что есть несколько ситуаций, когда одна или другая уже существует, и приходится создавать другую вокруг существующей. Но скажите, если бы вы могли начать с нуля, какой подход лучше? Я больше склоняюсь в первую очередь к Class Design, а затем к DB, но мне хотелось бы внести свой вклад в идею. Какие проблемы масштабирования нужно рассмотреть? Проблемы реализации?

Answer 1

Всякий раз, когда это зависит от меня, я почти всегда начинаю с проектирования базы данных.

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

Answer 2

Очень сильно зависит от приложения, я бы сказал. Если ваше приложение ориентировано на данные, вы должны отдать предпочтение базе данных над дизайном приложения; если ваше приложение в основном связано с бизнес-логикой или вычислениями, вы, вероятно, хотите отдать предпочтение дизайну приложения.

Еще одним соображением является долговечность и охват приложения - как говорит Джей, нередки случаи, когда несколько приложений используют одну и ту же базу данных. Хотя я бы на самом деле предположил, что это является причиной предоставления сервиса или интерфейса на основе сообщений для базы данных - я не думаю, что вы захотите позволить нескольким приложениям иметь прямой доступ к данным. В таком случае, я думаю, вы бы сосредоточили свои усилия на дизайне на уровне обслуживания.

Вы также можете подумать о сопоставлении дизайна с бизнес-областью - в идеале вы хотите, чтобы ваше программное обеспечение отражало бизнес-концепции (см. «Проектирование на основе доменов» Эванса). Это обычно - но не всегда - легче при работе с объектной технологией, а не с моделями отношения сущностей (классический вопрос - как сопоставить наследование с моделью базы данных).

Наконец, важно учитывать навыки и склонность команды - наличие банды гуру баз данных для разработки объектной модели обычно приводит к крутой кривой обучения (и наоборот).

Answer 3

Ваша база данных должна быть хорошо продумана, но ни приложение, ни дизайн базы данных не должны сильно влиять на другую.Ваши приложения должны быть независимыми от базы данных.Для хранения данных вашего приложения вы должны полагаться на слой, который обеспечивает необходимые переводы из ваших доменных объектов в таблицы базы данных.

Answer 4

Если дизайн класса диктует дизайн БД или дизайн БД диктует дизайн класса.

Я не уверен, что либо диктовать дизайн другой. Диктат подразумевает жесткую связь, что обычно является плохой вещью.

При разработке базы данных предполагается, что другие программы будут обращаться к базе данных.Важной частью проектирования базы данных является выбор правильных имен таблиц, имен столбцов и ограничений целостности.Все эти вещи являются частью открытого интерфейса базы данных.(Все эти вещи также связаны с нормализацией, математическим процессом, которого нет при разработке приложений. Это наблюдение, а не критика.)

Изменить действительно плохо разработанный публичный интерфейс действительно очень дорого.