ORM - Схема базы данных управляет составом объекта или наоборот?
У нас было довольно мало обсуждения среди нашей группы разработки относительно того, должен ли состав объектов управлять проектированием баз данных, или если диск проектирования баз данных состав объектов.
Для тех, кто имел дело с этим, какова была Ваша философия? Конечно, не каждый объект отображается 1:1 на таблицу базы данных. Но, для тех, которые делают, как Вы обработали это? IOW, который на первом месте, таблица базы данных и затем соответствующий объект или объект и затем таблица базы данных для сохранения его?
Спасибо.
3 ответа
Ваша база данных, вероятно, переживет любое приложение, которое вы создаете сегодня. Вся производительность и масштабируемость будут зависеть от схемы вашей базы данных. Надежная модель базы данных - это фундамент, на котором строится любое приложение, и я бы сказал, что именно в это место вам следует вложить больше всего усилий при проектировании и тестировании, поскольку это даст самые большие преимущества.
При этом, конечно, ваше приложение предпочтет манипулировать сущностями предметной области, а манипулирование неестественными сущностями, основанными на теории отношений, а не бизнес-сущностями, только усложнит ситуацию. Я считаю, что роль ORM заключается в том, чтобы как можно лучше соответствовать этим двум. Но всякий раз, когда возникают неизбежные конфликты, преимущество должно предоставляться движущим фактором вашей производительности и масштабируемости: схемой базы данных.
«сущность, а затем таблица базы данных для ее сохранения»
Сущность - это то, чем манипулирует ваша программа. В этом суть того, что обрабатывается.
Представление этой сущности в базе данных (например, представления плоских файлов или представления графического интерфейса пользователя) - это просто удобные представления этой сущности.
Возможно, вам придется немного подумать о представлении БД, когда дело доходит до некоторых вещей, в которых реляционные базы данных особенно плохи. Например, отношения «многие ко многим» требуют введения дополнительной таблицы, потому что база данных имеет ограничения, которых нет в вашей объектной модели. У вас могут быть некоторые соображения по дизайну сущностей, чтобы справиться с этим, но они немногочисленны и хорошо понятны.
База данных менее важна.
Определения сущностей являются центральными и важными.
Я бы сказал, что вы строите свою логическую модель данных и строите базу данных и соответствующие ей объекты.
Фактически, я бы поставил под сомнение предположение, что таблица базы данных и соответствующие объекты не могут соответствовать. Я редко, если когда-либо, видел случай, когда они действительно не могли бы (если вы создаете приложение с нуля). Кроме того, я бы сказал, что каждый раз, когда объектная модель и схема базы данных расходятся, возникает множество проблем.
Я вернулся к мысли, что все будет проще, если вы заставите их всегда совпадать, как бы еретично это ни было.