ORM - Схема базы данных управляет составом сущности или наоборот?

Question

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

Для тех, кто имел дело с этим, какова была ваша философия? Конечно, не каждый объект отображает 1: 1 в таблицу базы данных. Но для тех, кто это делает, как вы справились с этим? IOW, который идет первым, таблица базы данных, а затем соответствующая сущность или сущность, а затем таблица базы данных, чтобы сохранить ее?

Спасибо.

Answer 1

"сущность, а затем таблица базы данных для ее сохранения"

Entity - это то, чем манипулирует ваша программа. В этом суть того, что обрабатывается.

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

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

База данных менее важна.

Определения сущностей являются центральными и существенными.

Answer 2

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

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

Answer 3

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

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

Я вернулся к мысли, что все проще, если вы сделаете так, чтобы они всегда совпадали, какими бы еретическими они ни были.