Лучшие практики для разработки классов для представления таблиц базы данных

Question

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

Предположим, у нас есть база данных с двумя таблицами: Users и Orders (один пользователь можетмного заказов), и на любом языке ООП у вас есть два класса для представления этих таблиц User и Order.В базе данных очевидно, что «заказ» будет иметь идентификатор «пользователя», потому что это отношение «один ко многим» (потому что у одного пользователя может быть много заказов), а у пользователя не будет никакого идентификатора заказа.Но в коде, что является лучшей практикой из следующих трех?

a) Должен ли пользователь иметь массив Orders?б) Должен ли заказ иметь идентификатор пользователя?в) Должен ли заказ содержать ссылку на объект пользователя?

Или есть более эффективные способы решения этой проблемы?Я всегда делал это по-разному, все они имеют свои плюсы и минусы, но я никогда не спрашивал мнение эксперта.

Заранее спасибо!

Answer 1

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

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

Я не верю, что есть лучшая практика, так как она действительно зависит от того, чего вы пытаетесь достичь. С Пользователями и Заказами я мог видеть, что вы начинаете с Заказа и нуждаетесь в доступе к Пользователю и наоборот; поэтому в вашей ситуации кажется, что вы должны наносить на карту объекты в обоих направлениях.

Одно слово предупреждения, только будьте осторожны, чтобы не создать круговую ссылку. Если вы удалите оба объекта без ссылки, это может привести к утечке памяти.

Answer 2

Вы спрашиваете о том, что известно как «объектно-реляционное отображение» (ORM). Я думаю, что лучший способ узнать то, что вы хотите изучить, это взглянуть на некоторые хорошо зарекомендовавшие себя библиотеки ORM [такие как ActiveRecord (Ruby) или Hibernate (Java)] и посмотреть, как они это делают.

Имея это в виду:

a) Если приложение требует этого, должен быть доступ к массиву (или аналогичному перечислению) объектов, представляющих заказы пользователей через объект пользователя. Однако обычно это лучше всего включать в себя ленивую загрузку (то есть заказы обычно не будут извлекаться из базы данных, когда пользователь извлекает из базы данных .... заказы будут впоследствии запрашиваться, когда приложению необходим доступ к ним). После того, как объекты загружены лениво, они могут быть кэшированы ORM, чтобы исключить необходимость в дальнейших запросах на это определение.

b) Если только по соображениям производительности вы не тянете только определенные столбцы, вы обычно тянете все столбцы при получении заказа. Таким образом, он будет включать в себя идентификатор пользователя.

в) Ответ также относится и к этому.