Entity Framework: таблица без первичного ключа

У меня есть существующая БД, с которой я хотел бы создать новое приложение с использованием EF4.0

В некоторых таблицах нет первичных ключей, поэтому, когда я создаю новую модель данных Entity, я получаю следующее сообщение: «В таблице / представлении TABLE_NAME не указан первичный ключ и не может быть выведен допустимый первичный ключ. Эта таблица / view был исключен. Чтобы использовать объект, вам нужно будет просмотреть вашу схему, добавить правильные ключи и раскомментировать ее ».

Если я хочу использовать их и изменять данные, должен ли я обязательно добавлять PK к этим таблицам или есть временное решение, так что мне не нужно?

    14 Solutions collect form web for “Entity Framework: таблица без первичного ключа”

    Я думаю, что это разрешено Тиллито:

    Представление Entity Framework и представление SQL Server

    Я приведу его запись ниже:

    У нас была та же проблема, и это решение:

    Чтобы заставить сущность-структуру использовать столбец в качестве первичного ключа, используйте ISNULL.

    Чтобы заставить сущность Framework не использовать столбец в качестве первичного ключа, используйте NULLIF.

    Простой способ применить это – обернуть оператор выбора вашего представления в другой выбор.

    Пример:

    SELECT ISNULL(MyPrimaryID,-999) MyPrimaryID, NULLIF(AnotherProperty,'') AnotherProperty FROM ( ... ) AS temp 

    ответить 26 апр ’10 в 17:00 Тиллито

    Композитные клавиши также могут быть выполнены с API-интерфейсом Entity Framework Fluent

     public class MyModelConfiguration : EntityTypeConfiguration { public MyModelConfiguration() { ToTable("MY_MODEL_TABLE"); HasKey(x => new { x.SourceId, x.StartDate, x.EndDate, x.GmsDate }); ... } } 

    В моем случае мне пришлось сопоставить сущность с представлением, в котором не было первичного ключа. Более того, мне не разрешили изменять этот вид. К счастью, у этого представления был столбец, который был уникальной строкой. Моим решением было отметить этот столбец как первичный ключ:

     [Key] [DatabaseGenerated(DatabaseGeneratedOption.None)] [StringLength(255)] public string UserSID { get; set; } 

    Обманутый EF. Работала отлично, никто не заметил … 🙂

    ЭТО РЕШЕНИЕ РАБОТЫ

    Вам не нужно вручную отображать карту, даже если у вас нет ПК. Вам просто нужно сообщить EF, что один из ваших столбцов – это индексный и индексный столбцы, которые не имеют значения NULL.

    Для этого вы можете добавить номер строки к вашему представлению с помощью функции isNull, как показано ниже.

     select ISNULL(ROW_NUMBER() OVER (ORDER BY xxx), - 9999) AS id from a 

    ISNULL(id, number) является ключевым моментом здесь, потому что он сообщает EF, что этот столбец может быть первичным ключом

    EF не требует первичного ключа в базе данных. Если это так, вы не можете привязывать сущности к представлениям.

    Вы можете изменить SSDL (и CSDL), чтобы указать уникальное поле в качестве основного ключа. Если у вас нет уникального поля, то я считаю, что вас обманули. Но у вас действительно должно быть уникальное поле (и ПК), иначе вы столкнетесь с проблемами позже.

    Erick

    Вышеуказанные ответы верны, если у вас действительно нет ПК.

    Но если он есть, но он просто не указан с индексом в БД, и вы не можете изменить БД (да, я работаю в мире Дилберта), вы можете вручную сопоставить поле (ы) как ключ.

    Наличие бесполезного ключа идентификации бессмысленно. Я считаю, что если идентификатор не используется, зачем его добавлять? Однако Entity не так прощает об этом, поэтому лучше всего добавить поле ID. Даже в том случае, когда он не используется, это лучше, чем иметь дело с непредсказуемыми ошибками Entity относительно недостающего ключа идентификации.

    Это просто дополнение к ответу @Erick T. Если нет единственного столбца с уникальными значениями, обходным путем является использование составного ключа, как показано ниже:

     [Key] [Column("LAST_NAME", Order = 1)] public string LastName { get; set; } [Key] [Column("FIRST_NAME", Order = 2)] public string FirstName { get; set; } 

    Опять же, это всего лишь обходной путь. Реальное решение – исправить модель данных.

    Если я хочу использовать их и изменять данные, должен ли я обязательно добавлять PK к этим таблицам или есть временное решение, так что мне не нужно?

    Для тех, кто достигает этого вопроса и использует Entity Framework Core, вам больше не нужно обязательно добавлять PK в таблицы thoses или делать какие-либо обходные пути. Начиная с EF Core 2.1 у нас есть новая функция Типы запросов

    Типы запросов должны использоваться для:

    • Работа в качестве возвращаемого типа для специальных запросов FromSql ().
    • Отображение в представлениях базы данных.
    • Отображение таблиц, для которых не указан первичный ключ.
    • Отображение запросов, определенных в модели.

    Поэтому в вашем DbContext просто добавьте следующее свойство типа DbQuery вместо DbSet как DbSet ниже. Предполагая, что имя вашей таблицы – MyTable :

     public DbQuery MyTables { get; set; } 
    1. Измените структуру таблицы и добавьте первичный столбец. Обновить модель
    2. Измените файл .EDMX в редакторе XML и попробуйте добавить тег New Column под этой конкретной таблицей (НЕ РАБОТАЕТ)
    3. Вместо создания новой таблицы «Первичный столбец в выход» я создам составной ключ, используя все существующие столбцы ( WORKED )

    Entity Framework: добавление DataTable без основного ключа к модели Entity.

    Возможно, поздно ответить … однако …

    Если таблица не имеет первичного ключа, то есть несколько сценариев, которые необходимо проанализировать, чтобы сделать работу EF должным образом. Правило: EF будет работать с таблицами / classами с первичным ключом. Вот как он отслеживает …

    Скажем, ваша таблица 1. Записи уникальны: уникальность сделана одним столбцом внешнего ключа: 2. Записи уникальны: уникальность производится комбинацией нескольких столбцов. 3. Записи не уникальны (по большей части *).

    Для сценариев №1 и №2 вы можете добавить следующую строку в модуль DbContext. Метод OnModelCreating: modelBuilder.Entity (). HasKey (x => new {x.column_a, x.column_b}); // столько столбцов, сколько требуется, чтобы сделать записи уникальными.

    Для сценария №3 вы можете использовать вышеупомянутое решение (# 1 + # 2) после изучения таблицы (* то, что делает все записи уникальными в любом случае). Если вы должны включить ВСЕ столбцы, чтобы сделать все записи уникальными, вы можете захотеть добавить столбец первичного ключа в свою таблицу. Если эта таблица принадлежит стороннему поставщику, то клонируйте эту таблицу в свою локальную базу данных (в одночасье или столько раз, сколько вам нужно), когда столбец первичного ключа добавлен произвольно через ваш скрипт клона.

    С практической точки зрения каждая таблица – даже денормализованная таблица, такая как таблица склада, должна иметь первичный ключ. Или, в противном случае, он должен, по крайней мере, иметь уникальный, не нулевой индекс.

    Без какого-либо уникального ключа в таблице могут отображаться (и будут) повторяющиеся записи, что очень проблематично как для слоев ORM, так и для базового понимания данных. Стол, имеющий дубликаты, вероятно, является симптомом плохого дизайна.

    По крайней мере, таблица должна иметь хотя бы столбец идентификаторов. Добавление столбца автогенерирующего идентификатора занимает около 2 минут в SQL Server и 5 минут в Oracle. Для этого дополнительного усилия можно избежать многих, многих проблем.

    Мы столкнулись с этой проблемой, и хотя у нас был столбец с нулями, важно было, чтобы у нас был зависимый столбец, у которого не было нhive, и что комбинация этих двух столбцов была уникальной.

    Поэтому, чтобы процитировать ответ, данный Пратапом Редди, он отлично работал для нас.

    В таблице просто должен быть один столбец, который не допускает null

    Давайте будем гением компьютера.