Здравствуйте, Gattaka, Вы писали:

G>>Если все пользователи связаны со всеми, то установка property на любом узле приведет к добавлению Node_Node всех узлов в поле Node2Id. Что для дальнейшего использования не имеет смысла, так как просто можно запрашивать n.Property вместо джоина к Node_Node.

G>>А если ты приведешь реальные средние значения количества связей User_Node и User_User, то перемножив два числа получим количество считываемых\добавляемых строк. Например для User_Node примерное соотношение 10, а для User_User — 150, то надо будет получить максимум 1500 записей для каждого ID. Размер записи — 8 байт (два ID по 4 байта). То есть 12кб. Если это операция обновления, которая не выполняется 10 раз в секунду, то можно не беспокоиться о скорости.
G>Считайте, что все со всеми минус 1000000 каких-то случайных связей между пользователями. Вот такие объемы. Те расчеты, что вы привели — оч. мало.
Тогда нужно логику разворачивать — сохранять каких связей НЕТ. Тогда просто два селекта и except. И добавить\удалить надо будет несколько строк.

G>>А вообще я бы лучше сделал материализованную view вида

G>>

G>>create view UserNodeJunction with schemabinding as 
G>>select 
G>>    un1.NodeId as Node1Id, 
G>>    un1.UserId as User1Id, 
G>>    un2.NodeId as Node2Id, 
G>>    un2.UserId as User2Id 
G>>from UserOnNode un1 
G>>join User_User uu on uu.User1Id = un1.UserId -- Берем связи пользователя
G>>join UserOnNode un2 on un2.UserId = uu.User2Id 

G>>create clustered index PK_UserNodeJunction on UserNodeJunction (Node1Id, User1Id, Node2Id, User2Id)
G>>create index IX_NodeLink on UserNodeJunction (Node1Id, Node2Id)
G>>

G>Ерунда , будет тормозить добавление и удаление связей.

Я не вижу в этом проблемы, ты же и так предлагаешь писать по 70 000 строк на клик мышкой, я предлагаю то же самое.

Добавление связей как часто происходит?

G>>Тогда твой запрос вообще можно было бы во view превратить:
G>>

G>>create view NodeWithProperty as 
G>>select distinct n.Id, j.Node2Id
G>>from Network_Node n
G>>join UserNodeJunction j on n.Id = j.Node1Id
G>>where n.Property = true 
G>>

G>Так джойн и так быстро делается, только при вставке связей вы получите дополнительные расходы.

Ты что-то не договариваешь. У тебя в 4 900 000 000 в таблице User_User и 70 000 в UserOnNode. То есть внутренний джоин дает 2e19 записей, которые потом надо отсортировать, чтобы сделать distinct. На это не хватит памяти никакого сервера. Так что не может этот джоин быстро работать ни при каких раскладах.
Поэтому indexed view выгоднее, хранятся уже отсортированные значения в индексе и distinct будет быстрее.

G>Плюс размер базы разратется в 2 раза. Если сейчас это 36 ГБ табличка — будет 72 ГБ.
И? Важно не то, сколько ты хранишь, а сколько читаешь. Ведь 98% операция чтения.


G>>И если это view индексировать (вытащив distinct на уровень выше), то вовсе пропадет необходимость что-то куда-то вставлять.

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

G>Было бы супер не вставлять, но печаль... Во-первых тут не одно свойство может приводить к такому, во вторых даже если в результате бага связи попали — исчизать не должны. И масса еще другого...
Как за с материализованными view было бы проще, там меньше чего может сломаться.