Общие отношения в Django

Question

Хотелось бы услышать ваше мнение. На текущем этапе (1.1) вы бы использовали общие отношения в джанго или придерживались более традиционного моделирования - учитывая, что еще невозможно легко пересечь и фильтровать такие отношения (по сравнению с отношениями ForeignKey, ManyToMany, OneToOne)?

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

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

Один из способов сделать это - определить модель действия, которая может соответствовать любому сценарию и подключить их к другим моделям с использованием общих отношений, другим способом - определить отдельные модели PageView, EmailUpdateLog, EmailSubscription и получить к ним доступ «обычным способом».

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

Вы нашли сценарий, когда общие отношения дают вам огромное преимущество, помимо просто быть интересной концепцией?

Возможно, вы нашли другой способ подражать родовым отношениям?

Спасибо.

Answer 1

Все зависит от ваших требований/задач ..

Для некоторых задач общих отношений являются штрафом (и я использую их) Для другого более эффективного использования «традиционное моделирование»

Answer 2

Я бы вопроса Вашего отправного предположения:

учитывая, что это пока невозможно пройти и фильтр против таких отношений легко

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

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