Как обычно осуществляется прямой доступ 1-многих отношений?

Question

Я понимаю, что отношение 1-много легче всего представить дочерним элементом, имеющим ссылку внешнего ключа, указывающую на родителя.

Parent
  - id

Child
  - id
  - parentId // fk

В этом случае доступ к родителю от ребенка тривиален.Просто сделайте O (1) доступ к родительской таблице.

Но как управлять эффективным доступом всех дочерних элементов родителя?

Например, как метод, подобный Parent.children(), обычно реализуется в orm, чтобы он был эффективным?

Некоторые вещи, которые я рассмотрел / попробовал:

Если бы у родителя также был список childIds: [], это сработало бы, но тогда вам пришлось бы вставить childId в родителейchildIds после создания.Две операции по созданию модели кажутся неправильными, даже если мы получаем O (1) доступ к списку дочерних идентификаторов.

Вы можете просто перебрать всех детей children.filter(({ parentId }) => parentId === 2), чтобы получить детей здесь, например, Родителя 2, каждый галстук, к которому вы хотите получить доступ ко всем детям Родителя 2.Но это O (n) операций, и становится неэффективным.

Есть ли какой-нибудь стандартный способ избежать обеих этих ловушек?Т.е. каковы / являются стандартные подходы к реализации метода orm, который возвращает потомков родительской модели в отношении 1-многие?

Answer 1

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

ORM позволяет вам объявлять отношения и методы для получения результатов запросов связанных сущностей, но запрос, выполняемый ORM, специфичен для магазина, и именно здесь он будет сделан "более эффективным".В хранилище SQL разработчик обычно не задумывается об этом, ORM просто запустит, например, select * from children where parentId = 2, и хранилище сделает это эффективным.

Похоже, у вас есть хранилище объектов javascript.Если производительность не является реальной проблемой, children.filter({ parentId }) === parent.id является подходом, используемым redux-orm, и, скорее всего, будет адекватным, учитывая скорость современных браузеров.

Для хранилищ SQL, вероятно, существуют гораздо более низкоуровневые подходы к оптимизации таких запросов.Например, если все дочерние элементы были отсортированы по parentId, можно использовать более эффективные алгоритмы, чем O (n).Некоторые такие подходы могут также применяться к хранилищам объектов javascript.

Другими словами, использование parentId в дочерней модели приводит к проблеме фильтрации при переходе от 1 к множеству.

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

Короче говоря, цикл O (n) для реализации метода 1-много займет большое n, чтобы стать узким местом производительности, и если это так, есть другие подходы фильтрации, которые меньше, чем O (n),Вы можете изучить алгоритмы фильтрации CS, чтобы понять это дальше.Также, если вы реализуете свой магазин, многие опции действительны, это зависит только от вашего конкретного случая.SQL обычно абстрагирует используемые алгоритмы, но если вы реализуете свое собственное хранилище, вам нужно подумать об этом более тщательно, основываясь на ваших случаях.