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

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

G>> D>Пока звучит как бездумная денормализация.

G>> Ну я выше приводил уже список таблиц. Продублирую: "Таблицы User(Id, Name, Property), Network_Node(Id, Name, Property), User_User(User1Id, User2Id), Network_Node(Node1Id, Node2Id), UserOnNode(NodeId, UserId)"
G>> Что здесь бездумно денормализовано и как бы вы нормализовали? Какой у вас получился бы список таблиц?

D>Начнем с того что в твоем описании фигурируют какие-то роли
D>

Итак, админ запускает приложение. Выбирает список узлов, правой кнопкой — назначить роль. Роль назначается на узлы, а также если на узле есть зарегестрированные пользователи (их может быть несколько, предположим что один) и если эти пользователи имеют связи между собой — нужно установить связи между сетевыми узлами, только если эти связи не были запрещены админом до этого, если нет запретов со стороны других ролей и эти связи еще не существуют. Плюс у связи может быть статус, но это опустим — нужно назначать в только для определенных статусов связей.

D>Далее, property у нода и пользователя-это что за зверь? Для каждого свойства своя колонка? Они пересекаются между user, node? Как могут существать 2 таблицы Network_Node? Что такое User_User, UserOnNode(а почему тут вдруг отказались от underscore нейминга?)? А как запрещаются связи? И еще 100500 вопросов и потенциальных ответов на них из которых я сделал вывод что тут присутствует денормализация(вероятно не к месту) и как следствие попытки добиться консистентности данных через ХП.

Сначала я роли не вводил, ввел просто флаг property — считайте что это и есть роли. То есть свойство Property типа int и выставление туда значения — это есть назначение роли на узел. Таблицу User упростим до User(Id, Name).
Очевдно, что вторая таблица называется Network_Node. User_User — таблица связей пользователей, я не знаю а вы что подумали? Отказались от underscore нейминга потому что это нифига не важно сейчас. Мы ведь тестовую ситуацию разбираем.

Теперь еще раз что требуется сделать. Т.к. уже много раз переписывалось. В таблице User(Id, Name) 70000 записей. В таблице Network_Node(Id, Name, Property) 70000 записей. В Таблице UserOnNode(NodeId, UserId) — 70000 записей по одному пользователю на узле. В таблице User_User(User1Id, User2Id) — связи пользователей, все польователи связаны со всеми — это 70000*70000=4900000000 записей. На каждую из записей по 8 байт, т.е. приблизительно 36 гигабайт табличка, не учитывая индексов. Теперь в таблице Network_Node(Node1Id, Node2Id) — связи узлов. Допустим кто-то с кем-то уже был связан в случайном порядке 900000000 записей каких-то.
Нам нужно сделать: У узлов (35000 каких-то) Network_Node меняется свойство Property — бизнес логика такова, что нужно найти зарегестрированные на этих узлах пользовати и если они связаны — добавить связи по узлам.
На самом деле у связи тоже есть свойства, но давайте не будем сейчас усложнять. Вот задача просто такая как я выше описал сейчас.

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

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

G>> D>Пока звучит как бездумная денормализация.

G>> Ну я выше приводил уже список таблиц. Продублирую: "Таблицы User(Id, Name, Property), Network_Node(Id, Name, Property), User_User(User1Id, User2Id), Network_Node(Node1Id, Node2Id), UserOnNode(NodeId, UserId)"
G>> Что здесь бездумно денормализовано и как бы вы нормализовали? Какой у вас получился бы список таблиц?

D>Начнем с того что в твоем описании фигурируют какие-то роли
D>

Итак, админ запускает приложение. Выбирает список узлов, правой кнопкой — назначить роль. Роль назначается на узлы, а также если на узле есть зарегестрированные пользователи (их может быть несколько, предположим что один) и если эти пользователи имеют связи между собой — нужно установить связи между сетевыми узлами, только если эти связи не были запрещены админом до этого, если нет запретов со стороны других ролей и эти связи еще не существуют. Плюс у связи может быть статус, но это опустим — нужно назначать в только для определенных статусов связей.

D>Далее, property у нода и пользователя-это что за зверь? Для каждого свойства своя колонка? Они пересекаются между user, node? Как могут существать 2 таблицы Network_Node? Что такое User_User, UserOnNode(а почему тут вдруг отказались от underscore нейминга?)? А как запрещаются связи? И еще 100500 вопросов и потенциальных ответов на них из которых я сделал вывод что тут присутствует денормализация(вероятно не к месту) и как следствие попытки добиться консистентности данных через ХП.

Сначала я роли не вводил, ввел просто флаг property — считайте что это и есть роли. То есть свойство Property типа int и выставление туда значения — это есть назначение роли на узел. Таблицу User упростим до User(Id, Name).
Очевдно, что вторая таблица называется не Network_Node, а Node_Node. User_User — таблица связей пользователей, я не знаю а вы что подумали? Отказались от underscore нейминга потому что это нифига не важно сейчас. Мы ведь тестовую ситуацию разбираем.

Теперь еще раз что требуется сделать. Т.к. уже много раз переписывалось. В таблице User(Id, Name) 70000 записей. В таблице Network_Node(Id, Name, Property) 70000 записей. В Таблице UserOnNode(NodeId, UserId) — 70000 записей по одному пользователю на узле. В таблице User_User(User1Id, User2Id) — связи пользователей, все польователи связаны со всеми — это 70000*70000=4900000000 записей. На каждую из записей по 8 байт, т.е. приблизительно 36 гигабайт табличка, не учитывая индексов. Теперь в таблице Network_Node(Node1Id, Node2Id) — связи узлов. Допустим кто-то с кем-то уже был связан в случайном порядке 900000000 записей каких-то.
Нам нужно сделать: У узлов (35000 каких-то) Network_Node меняется свойство Property — бизнес логика такова, что нужно найти зарегестрированные на этих узлах пользовати и если они связаны — добавить связи по узлам.
На самом деле у связи тоже есть свойства, но давайте не будем сейчас усложнять. Вот задача просто такая как я выше описал сейчас.