Estrutura de entidades: tabela sem chave primária

Eu tenho um banco de dados existente com o qual gostaria de criar um novo aplicativo usando EF4.0

Algumas tabelas não têm chaves primárias definidas para que, quando eu crie um novo modelo de dados de entidade, receba a seguinte mensagem:

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.

Se eu quiser usá-los e modificar dados, devo necessariamente adicionar uma PK a essas tabelas ou há uma solução alternativa para que eu não precise?

O erro significa exatamente o que diz.

Mesmo se você pudesse resolver isso, confie em mim, não quer. O número de bugs confusos que podem ser introduzidos é assustador e assustador, sem mencionar o fato de que seu desempenho provavelmente será prejudicado.

Não trabalhe com isso. Corrija seu modelo de dados.

Edição: Eu vi que um número de pessoas estão votando esta questão. Tudo bem, suponho, mas lembre-se de que o OP perguntou sobre o mapeamento de uma tabela sem uma chave primária, não uma visualização . A resposta ainda é a mesma. Contornar a necessidade da EF de ter um PK nas tabelas é uma má ideia do ponto de vista de gerenciamento, integridade de dados e desempenho.

Alguns comentaram que não têm a capacidade de corrigir o modelo de dados subjacente porque estão mapeando para um aplicativo de terceiros. Essa não é uma boa ideia, pois o modelo pode mudar de baixo de você. Indiscutivelmente, nesse caso, você desejaria mapear para uma exibição, que, novamente, não é o que o OP pediu.

Eu acho que isso é resolvido por Tillito:

Estrutura de entidades e exibição do SQL Server

Vou citar sua entrada abaixo:

Tivemos o mesmo problema e esta é a solução:

Para forçar a estrutura da entidade a usar uma coluna como chave primária, use ISNULL.

Para forçar a estrutura da entidade a não usar uma coluna como chave primária, use NULLIF.

Uma maneira fácil de aplicar isso é agrupar a instrução select da sua visualização em outra seleção.

Exemplo:

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

respondeu Apr 26 '10 às 17:00 por Tillito

Se eu quiser usá-los e modificar dados, devo necessariamente adicionar uma PK a essas tabelas ou há uma solução alternativa para que eu não precise?

Para aqueles que alcançam essa pergunta e estão usando o Entity Framework Core, não é mais necessário adicionar necessariamente uma PK a essas tabelas ou executar qualquer solução alternativa. Desde o EF Core 2.1, temos um novo recurso Tipos de Consulta

Os tipos de consulta devem ser usados ​​para:

• Servindo como o tipo de retorno para consultas ad hoc FromSql ().
• Mapeando para visualizações de banco de dados.
• Mapeamento para tabelas que não possuem uma chave primária definida.
• Mapeamento para consultas definidas no modelo.

Portanto, no seu DbContext, basta adicionar a seguinte propriedade do tipo, em DbQuery<T>vez de DbSet<T>como abaixo. Supondo que o nome da sua tabela seja MyTable:

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

As chaves compostas também podem ser feitas com a API Fluente do Entity Framework

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

No meu caso, tive que mapear uma entidade para uma View, que não tinha chave primária. Além disso, eu não tinha permissão para modificar essa visualização. Felizmente, este View tinha uma coluna que era uma string única. Minha solução foi marcar esta coluna como uma chave primária:

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

EF enganado. Funcionou perfeitamente, ninguém notou ... :)

O EF não requer uma chave primária no banco de dados. Caso isso aconteça, você não poderá vincular entidades a visualizações.

Você pode modificar o SSDL (e o CSDL) para especificar um campo exclusivo como sua chave primária. Se você não tem um campo único, acredito que você está em uma mangueira. Mas você realmente deve ter um campo exclusivo (e um PK), caso contrário, terá problemas mais tarde.

Erick

Ter uma chave de identidade inútil às vezes é inútil. Acho que se o ID não é usado, por que adicioná-lo? No entanto, a Entidade não perdoa tanto, portanto, é melhor adicionar um campo de ID. Mesmo no caso de não ser usado, é melhor do que lidar com os erros incessivos da Entidade sobre a chave de identidade ausente.

ESTA SOLUÇÃO FUNCIONA

Você não precisa mapear manualmente, mesmo se não tiver um PK. Você só precisa informar ao EF que uma de suas colunas é index e a coluna index não é anulável.

Para fazer isso, você pode adicionar um número de linha à sua visualização com a função isNull, como a seguinte

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

ISNULL(id, number) é o ponto principal aqui, porque informa à EF que esta coluna pode ser a chave primária

As respostas acima estão corretas se você realmente não tiver um PK.

Mas se houver um, mas ele simplesmente não for especificado com um índice no banco de dados, e você não puder alterar o banco de dados (sim, eu trabalho no mundo de Dilbert), você pode mapear manualmente o (s) campo (s) para ser a chave.

Esta é apenas uma adição à resposta de @Erick T. Se não houver uma única coluna com valores exclusivos, a solução alternativa é usar uma chave composta, da seguinte maneira:

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

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

Novamente, isso é apenas uma solução alternativa. A solução real é consertar o modelo de dados.

Talvez seja tarde demais para responder ... no entanto ...

Se uma tabela não possui uma chave primária, existem poucos cenários que precisam ser analisados ​​para que o EF funcione corretamente. A regra é: A EF funcionará com tabelas / classes com chave primária. É assim que ele rastreia ...

Diga sua tabela 1. Os registros são únicos: a exclusividade é feita por uma única coluna de chave estrangeira: 2. Os registros são únicos: a exclusividade é feita por uma combinação de várias colunas. 3. Os registros não são exclusivos (na maior parte *).

Para os cenários 1 e 2, você pode adicionar a seguinte linha ao método OnModelCreating do módulo DbContext: modelBuilder.Entity (). HasKey (x => new {x.column_a, x.column_b}); // quantas colunas forem necessárias para tornar os registros exclusivos.

Para o cenário nº 3, você ainda pode usar a solução acima (nº 1 + nº 2) depois de estudar a tabela (* o que torna todos os registros exclusivos de qualquer maneira). Se você precisar incluir TODAS as colunas para tornar todos os registros exclusivos, convém adicionar uma coluna de chave primária à sua tabela. Se esta tabela for de um fornecedor de terceiros, clone-a no banco de dados local (durante a noite ou quantas vezes você precisar) com a coluna de chave primária adicionada arbitrariamente por meio do script de clone.

1. Altere a estrutura da tabela e adicione uma coluna principal. Atualizar o modelo
2. Modifique o arquivo .EDMX no XML Editor e tente adicionar uma nova coluna sob a tag para esta tabela específica (NÃO FUNCIONARÁ)
3. Em vez de criar uma nova tabela Coluna Primária para Saída, farei uma chave composta envolvendo todas as colunas existentes ( WORKED )

Estrutura de Entidades: Adicionando DataTable sem Chave Primária ao Modelo de Entidade.

Atualizar para @CodeNotFound a resposta de .

No EF Core 3.0 DbQuery<T>foi preterido, você deve usar os tipos de entidade sem chave que supostamente fazem a mesma coisa. Eles são configurados com o HasNoKey()método ModelBuilder . Na sua classe DbContext, faça isso

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

}

Existem restrições, porém:

• Nunca são rastreados para alterações no DbContext e, portanto, nunca são inseridos, atualizados ou excluídos no banco de dados.
• Suporta apenas um subconjunto de recursos de mapeamento de navegação, especificamente:
  • Eles podem nunca agir como o principal objetivo de um relacionamento.
  • Eles podem não ter navegações para entidades próprias
  • Eles podem conter apenas propriedades de navegação de referência apontando para entidades regulares.
  • As entidades não podem conter propriedades de navegação para tipos de entidade sem chave.

Isso significa que, para a questão de

Se eu quiser usá-los e modificar dados, devo necessariamente adicionar uma PK a essas tabelas ou há uma solução alternativa para que eu não precise?

Você não pode modificar os dados dessa maneira - no entanto, pode ler. No entanto, pode-se imaginar usar outra maneira (por exemplo, ADO.NET, Dapper) para modificar dados - isso pode ser uma solução nos casos em que você raramente precisa executar operações de não leitura e ainda gostaria de usar o EF Core para os casos de maioria.

Além disso, se você realmente precisa / deseja trabalhar com tabelas de pilha (sem chave) - considere abandonar o EF e use outra maneira de conversar com seu banco de dados.

Do ponto de vista prático, toda tabela - mesmo uma tabela desnormalizada como uma tabela de armazém - deve ter uma chave primária. Ou, na sua falta, deve ter pelo menos um índice exclusivo e não nulo.

Sem algum tipo de chave exclusiva, os registros duplicados podem (e serão) exibidos na tabela, o que é muito problemático para as camadas ORM e também para a compreensão básica dos dados. Uma tabela que possui registros duplicados é provavelmente um sintoma de design incorreto.

No mínimo, a tabela deve ter pelo menos uma coluna de identidade. A adição de uma coluna de ID de geração automática leva cerca de 2 minutos no SQL Server e 5 minutos no Oracle. Por esse esforço extra, muitos, muitos problemas serão evitados.

Também encontramos esse problema e, embora tivéssemos uma coluna que tinha nulos, o importante era que tivéssemos uma coluna dependente que não tinha nulos e que a combinação dessas duas colunas era única.

Então, para citar a resposta de Pratap Reddy, funcionou bem para nós.

Estou muito feliz que meu problema esteja resolvido.

Não foi possível atualizar o EntitySet - porque ele possui um DefiningQuery e nenhum elemento <UpdateFunction> existe

e faça o seguinte: olhe abaixo dessa linha e encontre a tag. Ele terá uma grande e velha declaração de seleção. Remova a tag e seu conteúdo.

agora sem alterar o DB TI pode inserir em uma tabela que não possui PK

obrigado a todos e obrigado Pharylon

No EF Core 5.0, você também poderá defini-lo no nível da entidade.

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

Referência: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/whatsnew#use-ac-attribute-to-indicate-that-an-entity- não tem chave

A tabela só precisa ter uma coluna que não permita valores nulos