Обновление отношений «многие ко многим» с LinqToSQL

Question

Если бы у меня была, например, таблица сопоставления «многие ко многим» под названием «RolesToUsers» между таблицей «Пользователи» и «Роли», вот как я это делаю:

// DataContext is db, usr is a User entity
// newUserRolesMappings is a collection with the desired new mappings, probably 
//   derived by looking at selections in a checkbox list of Roles on a User Edit page
db.RolesToUsers.DeleteAllOnSubmit(usr.RolesToUsers);
usr.RolesToUsers.Clear();
usr.RolesToUsers.AddRange(newUserRolesMappings);

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

В Интернете на эту тему удивительно тихо, и запрос «LinqToSQL« многие ко многим »» в основном просто приводит статьи о том, что преобразователь данных LinqToSQL не «хорошо» его поддерживает.

Как все остальные обновляют многие ко многим с помощью LinqToSQL?

Answer 1

Отношение - это набор фактов. Users, Roles и UsersToRoles - все это отношения, и не имеет никакого логического смысла относиться к одному как к более «первоклассному», чем к другому. То, что вы делаете, имеет смысл, поэтому кажется, что оно так хорошо работает.

Мир ORM демонстрирует реляционную модель еще хуже, чем SQL. В частности, оно институционализирует ошибку, заключающуюся в том, что реляционные базы данных хранят коллекции объектов. Они не; они хранят наборы фактов. Многие из этих фактов - о сущностях, поэтому заблуждение так заманчиво. Но множество фактов касается многих других понятий, таких как членство, события, статусы, мнения, транзакции, изменения, сравнения, истории и т. Д.

Также рассмотрим:

1. В какой-то момент вы можете указать, когда пользователь принял определенную роль, а затем, возможно, эта роль ожидает утверждения или временно отозвана. Я обнаружил, что почти все «отношения», которые я хочу выразить в модели данных, в конечном итоге несут полезную нагрузку сверх двух внешних ключей, которые составляют отношение «многие ко многим». Если ваше OR-отображение было настроено так, чтобы скрывать «многие ко многим» (как они склонны делать), вы найдете переход к сущности довольно болезненным с точки зрения разрывов кода.
2. Часто отношения сложнее, чем двоичные. «Профессор P использует учебник T в классе C.» Это могут быть неприводимые троичные отношения, которые не так просто спрятать за каким-то атрибутом коллекции объекта Профессора.
   • Я только что заметил, что именно эта проблема возникла как ТАК вопрос несколько минут назад. Из вопроса следует, что JPA 2.0 должен был явно добавить поддержку троичных отношений (обрабатывает ли он четвертичные и т. Д. Отношения?).

Answer 2

Это может быть не ответ на ваш вопрос, но и объяснение, почему «Интернет на эту тему удивительно тих»: я думаю, большинство людей (включая меня) просто обновляют / удаляют / добавляют отдельные элементыотношений n-to-n, и поэтому никогда не задавал себе вопрос, который у вас есть.

Например, когда у вас есть две таблицы «пользователи» и «роли», а сценарии использования просто для добавления / удаления роли для пользователя.

Просто любопытно: в каком приложении делатьвам нужно обновить все сопоставление, как ваш пример?