Linq для Sql и Non-PK, уникальные проблемы отношений с FK

Question

Я недавно читал книгу Луи Дэвидсона по проектированию баз данных Sql Server и нашел ее довольно информативной. Я подобрал множество концепций, о которых раньше (или вообще ничего) не знал. В первую очередь - я выбрал способ установки отношений с базой данных, который раньше не пробовал.

В основном вы используете суррогатный ключ в качестве таблицы PK (поле с автоматическим увеличением идентификатора), а затем настраиваете один или несколько альтернативных ключей, состоящих из одного или нескольких уникальных ключей. Этими альтернативными значениями kay будут значения, используемые для отношений (или PK, если это имеет больше смысла для данных отношений).

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

На уровне базы данных это прекрасно работает. Отношения функционируют так, как они должны, а ограничения применяются согласованным и надежным образом.

ОДНАКО

Я не могу заставить его работать должным образом ни в Entity Framework, ни в классах Linq to Sql. Я читал, что в V1 EF это просто не поддержит такого рода отношения - поэтому я переехал в Linq в Sql, чтобы посмотреть, получится ли что-нибудь получше. По-видимому, они сделали, поскольку я автоматически отобразил все отношения, когда импортировал классы из своей базы данных. Проблема в том, что я не могу сохранить данные в базу данных из-за исключительных ситуаций InvalidCastOperation, как только я пытаюсь сохранить данные.

Итак, у меня есть пара вопросов:

1. Это ограничение в Linq To Sql?
2. Если это так, есть ли способ обойти Это? Предпочтительно без реализации sprocs для сохранения, обновления и удаления - безопасность типа это то, что я бы хотел бы сохранить.
3. Это способ проектирования базы данных отношения "правильные" и / или хорошая практика?

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

Большое спасибо!

РЕДАКТИРОВАТЬ - Решение.

Я закончил тем, что сделал это - я вернулся к использованию Entity Framework в сочетании с редизайном схемы базы данных. Я перестроил отношения, чтобы в большинстве случаев полагаться на первичные ключи, а не на альтернативные ключи. Где это было не вариант - я сделал некоторые изменения в макете EF. Я реализовал отношения, которые опирались на АК - в это время EF жалуется. Чтобы обойти это, мне пришлось удалить свойство внешнего ключа на многих сторонах отношения, после чего EF принимает отношение.

Answer 1

1) Да.

2) Если вы можете пометить свой альтернативный ключ как основной в модели L2S и снять реальный PK как PK, он будет работать.

3) С точки зрения БД в этом нет ничего плохого, но, как вы заметили, он не поддерживается L2S или EF. Лично я предпочитаю всегда иметь FK, указывающие на PK, и использовать AK только для поиска.