Entity Framework: tabla sin clave primaria

Creo que esto es resuelto por Tillito:

Entity Framework y SQL Server View

Citaré su entrada a continuación:

Teníamos el mismo problema y esta es la solución:

Para forzar a entity framework a usar una columna como clave primaria, use ISNULL.

Para forzar a entity framework a no usar una columna como clave primaria, use NULLIF.

Una manera fácil de aplicar esto es envolver la instrucción select de su vista en otra seleccionar.

Ejemplo:

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

Respondida el 26 de abril del 10 a las 17: 00 por Tillito

Las claves compuestas también se pueden hacer con 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 });
        ...
     }
}

En mi caso tuve que asignar una entidad a una vista, que no tenía clave primaria. Además, no se me permitió modificar esta vista. Afortunadamente, esta vista tenía una columna que era una cadena única. Mi solución fue marcar esta columna como clave principal:

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

Engañó a EF. Funcionó perfectamente, nadie se dio cuenta... :)

ESTA SOLUCIÓN FUNCIONA

No necesita mapear manualmente incluso si no tiene un PK. Solo necesita decirle a EF que una de sus columnas es index y la columna index no es nullable.

Para hacer esto, puede agregar un número de fila a su vista con la función isNull como la siguiente

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

ISNULL(id, number) es el punto clave aquí porque le dice a EF que esta columna puede ser clave primaria

EF no requiere una clave primaria en la base de datos. Si lo hiciera, no podría vincular entidades a vistas.

Puede modificar la SSDL (y la CSDL) para especificar un campo único como clave principal. Si usted no tiene un campo único, entonces creo que está regado. Pero realmente debería tener un campo único (y un PK), de lo contrario se encontrará con problemas más adelante.

Erick

Si quiero usarlos y modificar datos, ¿debo necesariamente agregar un PK a esas tablas, o hay una solución para que no tenga que hacerlo?

Para aquellos que llegan a esta pregunta y están utilizando Entity Framework Core, ya no es necesario agregar necesariamente un PK a esas tablas o hacer cualquier solución. Desde EF Core 2.1 tenemos una nueva característica Tipos de consulta

Los tipos de consulta deben usarse para:

• Sirviendo como el tipo de retorno para ad hoc Consultas FromSql ().
• Asignación a vistas de base de datos.
• Asignación a tablas que no tienen definida una clave primaria.
• Asignación a consultas definidas en el modelo.

Así que en su DbContext simplemente agregue la siguiente propiedad de tipo DbQuery<T> en lugar de DbSet<T> como a continuación. Suponiendo que el nombre de la tabla es MyTable:

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

Las respuestas anteriores son correctas si realmente no tiene un PK.

Pero si hay uno pero simplemente no está especificado con un índice en la BD, y no puede cambiar la BD (sí, trabajo en el mundo de Dilbert), puede asignar manualmente el campo(s) para que sea la clave.

Tener una clave de identidad inútil a veces no tiene sentido. Me parece que si el ID no se utiliza, ¿por qué agregarlo? Sin embargo, Entity no es tan indulgente al respecto, por lo que agregar un campo de ID sería lo mejor. Incluso en el caso de que no se use, es mejor que tratar con los errores incesivos de la Entidad sobre la clave de identidad faltante.

Esto es solo una adición a la respuesta de @Erick T. Si no hay una sola columna con valores únicos, la solución es usar una clave compuesta, de la siguiente manera:

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

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

Nuevamente, esto es solo una solución alternativa. La solución real es arreglar el modelo de datos.

1. Cambie la estructura de la tabla y agregue una columna Primaria. Actualizar el Modelo
2. Modificar el .Archivo EDMX en el Editor XML e intente agregar una Nueva columna bajo etiqueta para esta tabla específica (NO FUNCIONARÁ)
3. En lugar de crear una nueva Columna Primaria para salir de la tabla, haga una clave compuesta involucrando todas las columnas existentes (TRABAJADAS)

Entity Framework: Agregar DataTable sin Clave Primaria al Modelo de Entidad.

Esto tal vez tarde para responder...obstante...

Si una tabla no tiene una clave primaria, entonces hay pocos escenarios que deben analizarse para que el EF funcione correctamente. La regla es: EF funcionará con tablas / clases con clave primaria. Así es como hace el seguimiento...

Diga, su mesa 1. Los registros son únicos: la unicidad se realiza mediante una sola columna de clave foránea: 2. Los registros son únicos: la singularidad se realiza mediante una combinación de varias columnas. 3. Los registros no son único (en su mayor parte*).

Para los escenarios #1 y #2 puede agregar la siguiente línea al módulo DbContext OnModelCreating method: modelBuilder.Entidad().HasKey(x => new { x.column_a, x.column_b }); // como tantas columnas como sea necesario para hacer registros únicos.

Para el escenario #3 aún puede usar la solución anterior (#1 + #2) después de estudiar la tabla (*lo que hace que todos los registros sean únicos de todos modos). Si debe incluir TODAS las columnas para hacer que todos los registros sean únicos, es posible que desee agregar un columna de clave primaria a su tabla. Si esta tabla es de un proveedor de terceros, clone esta tabla a su base de datos local (durante la noche o tantas veces como necesite) con la columna de clave primaria agregada arbitrariamente a través de su script de clonación.

Desde un punto de vista práctico, cada mesa even incluso una mesa desnormalizada como una mesa de almacén should debe tener una clave primaria. O, en su defecto, debería tener al menos un índice único, no anulable.

Sin algún tipo de clave única, los registros duplicados pueden (y aparecerán) en la tabla, lo que es muy problemático tanto para las capas OR como para la comprensión básica de los datos. Una tabla que tiene registros duplicados es probablemente un síntoma de mal diseño.

Como mínimo, la tabla debe tener al menos una columna de identidad. Agregar una columna de ID de generación automática tarda aproximadamente 2 minutos en SQL Server y 5 minutos en Oracle. Por ese poco de esfuerzo adicional, muchos, muchos problemas serán evitados.

También encontramos este problema, y aunque teníamos una columna que tenía nulos, lo importante era que teníamos una columna dependiente que no tenía nulos y que la combinación de estas dos columnas era única.

Así que para citar la respuesta dada por Pratap Reddy, funcionó bien para nosotros.

La tabla solo necesita tener una columna que no permita nulls