NHibernate дизайн и составные ключи

Question

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

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

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

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

Так что я подумал о том, как еще я мог бы разработать базу данных, и я полагаю, я мог бы

UserFavourite (UniqueID, UserId, OtherUserId, AddDate)

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

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

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

Answer 1

Для чистой таблицы отношений, вы могли бы пойти на многие-ко-многим (см NHibernate Many-to-many)

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

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

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

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