Большая структура сущности разделена на многие EDMX.Как действовать между этими? - PullRequest
1 голос
/ 02 сентября 2011

Я работаю над довольно большой базой данных. Всего будет около 200-300 столов. Во-первых, была ли у кого-нибудь такая база данных в одном EDMX? По моему опыту дизайнер становится непригодным для использования, когда вы получаете более 50 или около того сущностей.

В моем случае база данных довольно хорошо разбивается на такие предметные области, как членство, система, активы и т. Д.

Это то, что с EDMX, и все работает более или менее нормально.

Вот проблема, я уверен, что у всех есть. А таблица User живет в отдельном EDMX.

Для операций CUD я могу справиться с этим нормально, потому что у меня есть текущий пользователь. Но для восстановления мне часто нужно отображать ID того, кто создал запись, и для этого мне нужно объединение. Но я не могу присоединиться к таблице в другом EDMX.

Я вижу 2 решения для этого:

  1. Я кеширую список пользователей (он не может быть огромным) и идентификаторы поиска на клиенте
  2. Я добавлю таблицу пользователей во все мои модели и буду присоединяться каждый раз, когда я запрашиваю данные

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

1 Ответ

2 голосов
/ 03 сентября 2011

edmx определяет только концептуальную модель вашей базы данных. Так что можно добавлять пользовательские таблицы в несколько файлов EDMX.

Вариант № 2, кажется, в порядке.

Чтобы избежать конфликта, вам понадобятся разные имена таблиц, которые повторяются в нескольких файлах edmx. Что-то вроде SystemUser, все AssetUser фактически указывают на одну и ту же таблицу User.

Спасибо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...