В этом месяце я столкнулся с той же проблемой в двух разных частях работы:
Version 1: User 1 & User 2 are friends
Version 2: Axis 1 & Axis 2 when graphed should have the quadrants colored...
Проблема в том, что я не Я не вижу элегантного способа хранения и запроса этой информации с помощью СУБД.
Есть два очевидных подхода:
Подход 1:
store the information twice (i.e. two db rows rows per relationship):
u1, u2, true
u2, u1, true
u..n, u..i, true
u..i, u..n, true
have rules to always look for the inverse on updates:
on read, no management needed
on create, create inverse
on delete, delete inverse
on update, update inverse
Advantage: management logic is always the same.
Disadvantage: possibility of race conditions, extra storage (which is admittedly cheap, but feels wrong)
Подход 2:
store the information once (i.e. one db row per relationship)
u1, u2, true
u..n, u..i, true
have rules to check for corollaries:
on read, if u1, u2 fails, check for u2, u1
on create u1, u2: check for u2, u1, if it doesn't exist, create u1, u2
on delete, no management needed
on update, optionally redo same check as create
Advantage: Only store once
Disadvantage: Management requires different set of cleanup depending on the operation
Мне интересно, есть ли третий подход, который идет по линиям «ключ с использованием f (x, y), где f (x, y) уникален для каждой комбинации x, y и где f (x, y) === f (y, x) "
Моя интуиция подсказывает мне, что должна быть какая-то комбинация побитовых операций, которые могут выполнять эти требования. Что-то вроде двухколоночного:
key1 = x && y key2 = x + y
Я надеюсь, что люди, которые проводили больше времени на математическом факультете и меньше на социологическом факультете, увидели доказательство возможности или невозможности этого и могут быстро предоставить "[Ты придурок ,] это легко доказано (не) возможно, см. эту ссылку "(вызов имени необязательно)
Любой другой элегантный подход также будет очень приветствоваться.
Спасибо