Nhibernate дизайн и композитные ключи

Question

Хорошо. Я нахожусь в ситуации, когда у меня есть следующие таблицы

Пользователь (UserId ....) UserFavourite (UserId, OtherUserId, AddDate)

Если вы «добавили в избранное» другуюПользователь добавляет строку в userFavourite.Теперь у меня есть ссылочная целостность между столбцами UserId и OtherUserId и таблицей User с двумя ограничениями внешнего ключа.

Мой вопрос: каков наилучший способ доступа к нему через NHibernate?Базовый метод Get <> принимает идентификатор, который является столбцом идентификатора.В этом случае уникальной идентифицирующей характеристикой таблицы является составной ключ UserId и OtherUserId, поэтому я думаю, что мне нужен составной ключ.Я везде читал, что они плохие, и если БД спроектирована правильно, я не должен их использовать.

Поэтому я подумал о том, как еще я мог бы спроектировать БД, и я полагаю, что мог бы иметь

UserFavourite (UniqueID, UserId, OtherUserId, AddDate)

И сделайте UniqueId PK и ID для метода Get и наложите уникальное ограничение на столбцы UserId / OtherUserId.Однако это не решает мою проблему, так как, когда я хочу удалить строку через код или получить ее, мне все равно нужно передать UniqueID, к которому у меня не будет доступа.Я хочу иметь возможность сказать

«Удалить этого пользователя (идентификатор пользователя 142) из ​​избранного».Так что у меня есть доступ только к UserId и вашему собственному UserId, поэтому мне нужно как-то иметь возможность выполнять запрос NHibernate, используя эти два идентификатора, а не уникальный идентификатор.

Может ли кто-нибудь указать мне направлениекак этот случай должен обрабатываться в NHibernate с помощью идеальных методов, чтобы я мог легко и эффективно выполнять эти запросы без использования составных ключей?

Answer 1

Для чистой таблицы отношений вы могли бы пойти на отображение многих ко многим (см. NHibernate Многие ко многим )

Учитывая, что ваша таблица отношений содержит данные какAddDate (может быть, чуть позже), я думаю, что вы должны пойти на UniqueID, а затем иметь сопоставления коллекций

• два один ко многим с обратным = "true" из вашего класса User в класс UserFavourite.
• два многие-к-одному из вашего класса UserFavourite в класс пользователя

Вероятно, вы никогда не будете использовать UniqueId для удаления UserFavourite.Вы просто отфильтруете нужный UserFavourite среди UserFavourites вашего текущего пользователя и удалите его.

Возможно, вы не будете часто использовать AddDate.Я предполагаю, что с правильными атрибутами сопоставления относительно обновлений (каскад, сохранение, обновление, удаление) вы можете комбинировать два метода (сопоставления отношений «многие ко многим +»).