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

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

В некоторых таблицах не определены первичные ключи, поэтому при создании новой модели данных сущностей я получаю следующее сообщение:

The table/view TABLE_NAME does not have a primary key defined 
and no valid primary key could be inferred. This table/view has 
been excluded. To use the entity, you will need to review your schema, 
add the correct keys, and uncomment it.

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

Ошибка означает именно то, что говорится.

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

Не работай над этим. Исправьте вашу модель данных.

РЕДАКТИРОВАТЬ: Я видел, что ряд людей отрицательно относятся к этому вопросу. Это нормально, я полагаю, но имейте в виду, что OP спросил о сопоставлении таблицы без первичного ключа, а не представления . Ответ все тот же. Обходить EF необходимостью иметь PK на таблицах - плохая идея с точки зрения управляемости, целостности данных и производительности.

Некоторые отмечают, что у них нет возможности исправить базовую модель данных, поскольку они сопоставляются со сторонним приложением. Это не очень хорошая идея, так как модель может измениться из-под вас. Возможно, в этом случае вы захотите сопоставить с представлением, что, опять же, не то, что спросил ОП.

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

Entity Framework и SQL Server View

Я процитирую его запись ниже:

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

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

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

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

Пример:

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

ответил 26.04.10 в 17:00 Тиллито

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

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

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

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

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

public DbQuery<MyTable> MyTables { get; set; }

Составные ключи также можно сделать с помощью Entity Framework Fluent API

public class MyModelConfiguration : EntityTypeConfiguration<MyModel>
{
     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 не требует первичного ключа в базе данных. Если это так, вы не сможете привязать сущности к представлениям.

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

Erick

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

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

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

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

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

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

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

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

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

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

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

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

Это может быть поздно, чтобы ответить ... однако ...

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

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

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

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

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

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

Обновление до ответа @CodeNotFound .

В EF Core 3.0 DbQuery<T>устарела, вместо этого вы должны использовать типы сущностей Keyless, которые предположительно делают то же самое. Они настраиваются с помощью HasNoKey()метода ModelBuilder . В вашем классе DbContext, сделайте это

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<YourEntityType>(eb =>
        {
            eb.HasNoKey();
        });

}

Хотя есть ограничения, а именно:

• Никогда не отслеживаются на предмет изменений в DbContext и, следовательно, никогда не вставляются, не обновляются и не удаляются в базе данных.
• Поддерживает только подмножество возможностей отображения навигации, а именно:
  • Они могут никогда не выступать в качестве основного конца отношений.
  • Они могут не иметь навигации к принадлежащим лицам
  • Они могут содержать только ссылочные навигационные свойства, указывающие на обычные объекты.
  • Объекты не могут содержать свойства навигации к типам объектов без ключа.

Это означает, что для вопроса

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

Вы не можете изменять данные таким способом - однако вы можете читать. Можно было бы предположить использование другого способа (например, ADO.NET, Dapper) для изменения данных - это может быть решением в тех случаях, когда вам редко требуется выполнять операции, не связанные с чтением, и вы все равно хотели бы придерживаться EF Core в большинстве случаев.

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

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

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

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

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

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

Я очень рад, что моя проблема решена.

Невозможно обновить EntitySet - потому что у него есть DefiningQuery и отсутствует элемент <UpdateFunction>

и сделайте это: посмотрите ниже этой строки и найдите тег. В нем будет большое старое утверждение. Удалите тег и его содержимое.

Теперь без изменения БД TI можно вставить в таблицу, в которой нет PK

спасибо всем и спасибо Pharylon

В EF Core 5.0 вы сможете определить его и на уровне сущности.

[Keyless]
public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public int Zip { get; set; }
}

Ссылка: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/whatsnew#use-ac-attribute-to-indicate-that-an-entity- не имеет-не-ключ

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