ListProperty ключей по сравнению с Many-Many в Механизме Приложения
C:\Desktop>curl --head https://www.google.com/ --proxy 1.1.1.1:8080
3 ответа
Это зависит от нескольких факторов:
- Вам нужно хранить информацию о самом отношении, кроме его порядка? Например, если между заказами и продуктами много: много, потребуется хранить количество каждого продукта.
- Нужно ли вам связать более тысячи или около того элементов на стороне отношения с «меньшей» мощностью (например, > 1000 задач или> 1000 списков для элемента)?
- Обычно вы хотите получить все связанные элементы сразу или хотите быть более избирательным?
Если вам нужна дополнительная информация или у вас много элементы в вашей ассоциации, или вам нужно получить только некоторые из них, объект отношения, вероятно, будет лучшим выбором. В других ситуациях список может быть как проще, так и быстрее. В случае списка дел
За исключением реляционного контекста, когда кто-то настаивает на нормализации (что, конечно, целесообразно в реляционном случае!), Отдельный «класс отношения» TodoListItem кажется мне излишним, и несколько "неестественно" с точки зрения способа рассуждений о проблеме по сравнению с тем, как ее кодируют. Однако с точки зрения оптимизации это, безусловно, упростило бы поиск всех списков, в которых есть элемент.
Учитывая, что TodoListItem может принадлежать нескольким TodoListItem, я был бы обеспокоен тем, что было бы правильным иметь одно свойство порядка, которое работало бы для каждого списка, к которому принадлежит данный элемент. Я бы подумал, что для каждого списка, к которому он принадлежит, понадобится ордер.