.net - studio - entity framework ventajas y desventajas
Entity Framework: tabla sin clave principal (14)
Tengo un DB existente con el que me gustaría construir una nueva aplicación usando EF4.0
Algunas tablas no tienen claves principales definidas de modo que cuando creo un nuevo Modelo de datos de la entidad, recibo el siguiente mensaje: "La tabla / vista TABLE_NAME no tiene una clave principal definida y no se puede inferir ninguna clave primaria válida. Esta tabla / view ha sido excluido. Para usar la entidad, necesitará revisar su esquema, agregar las claves correctas y descomentarlo ".
Si quiero usarlos y modificar los datos, ¿debo agregar necesariamente un PK a esas tablas, o hay una solución para que no sea necesario?
- Cambie la estructura de la tabla y agregue una columna principal. Actualizar el modelo
- Modifique el archivo .EDMX en el Editor XML e intente agregar una Nueva columna debajo de la etiqueta para esta tabla específica (NO FUNCIONARÁ)
- En lugar de crear una nueva columna principal para salir de la tabla, crearé una clave compuesta involucrando todas las columnas existentes ( TRABAJADO )
Entity Framework: Agregar DataTable sin clave principal al modelo de entidad.
Creo que esto es resuelto por Tillito:
Entity Framework y SQL Server View
Citaré su entrada a continuación:
Tuvimos el mismo problema y esta es la solución:
Para forzar que el marco de la entidad use una columna como clave principal, use ISNULL.
Para forzar el marco de la entidad a no usar una columna como clave principal, use NULLIF.
Una forma fácil de aplicar esto es ajustar la declaración de selección de su vista en otra selección.
Ejemplo:
SELECT
ISNULL(MyPrimaryID,-999) MyPrimaryID,
NULLIF(AnotherProperty,'''') AnotherProperty
FROM ( ... ) AS temp
respondió el 26 de abril de 2010 a las 17:00 por Tillito
Desde un punto de vista práctico, cada tabla, incluso una tabla desnormalizada como una mesa de almacén, debe tener una clave principal. O, en su defecto, debería tener al menos un índice único que no admite nulos.
Sin algún tipo de clave única, los registros duplicados pueden aparecer (y aparecerán) en la tabla, lo cual es muy problemático tanto para las capas de ORM 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.
Por lo menos, la tabla debe tener al menos una columna de identidad. Agregar una columna de ID de autogeneración toma aproximadamente 2 minutos en SQL Server y 5 minutos en Oracle. Por ese poco de esfuerzo extra, se evitarán muchos, muchos problemas.
EF no requiere una clave primaria en la base de datos. Si así fuera, no podría vincular entidades a vistas.
Puede modificar el SSDL (y el CSDL) para especificar un campo único como clave principal. Si no tienes un campo único, entonces creo que eres una manguera. Pero realmente debería tener un campo único (y un PK); de lo contrario, se encontrará con problemas más adelante.
Erick
ESTA SOLUCIÓN FUNCIONA
No necesita hacer un mapa manualmente, incluso si no tiene un PK. Solo tiene que decirle al EF que una de sus columnas es un índice y que la columna de índice no puede contener nulos.
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 al EF que esta columna puede ser clave principal
En mi caso, tuve que asignar una entidad a una Vista, que no tenía clave principal. 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; }
EF engañado. Funcionó perfectamente, nadie se dio cuenta ... :)
Esto es solo una adición a la respuesta de @Erick T. Si no hay una sola columna con valores únicos, la solución consiste en utilizar 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; }
De nuevo, esto es solo una solución. La verdadera solución es arreglar el modelo de datos.
La tabla solo necesita tener una columna que no permita valores nulos
Las claves compuestas también se pueden hacer con la API Entity Framework Fluent
public class MyModelConfiguration : EntityTypeConfiguration<MyModel>
{
public MyModelConfiguration()
{
ToTable("MY_MODEL_TABLE");
HasKey(x => new { x.SourceId, x.StartDate, x.EndDate, x.GmsDate });
...
}
}
Las respuestas anteriores son correctas si realmente no tienes un PK.
Pero si hay uno pero no está especificado con un índice en el DB, y no puede cambiar el DB (sí, trabajo en el mundo de Dilbert) puede mapear manualmente los campos para que sean la clave.
Quizás sea demasiado tarde para responder ... sin embargo ...
Si una tabla no tiene una clave principal, existen pocos escenarios que deben analizarse para que el EF funcione correctamente. La regla es: EF trabajará con tablas / clases con clave primaria. Así es como rastrea ...
Digamos, su tabla 1. Los registros son únicos: la singularidad se realiza mediante una única columna de clave externa: 2. Los registros son únicos: la singularidad se realiza mediante una combinación de varias columnas. 3. Los registros no son únicos (en su mayor parte *).
Para los escenarios # 1 y # 2 puede agregar la siguiente línea al módulo DbContext Método OnModelCreating: modelBuilder.Entity (). HasKey (x => new {x.column_a, x.column_b}); // tantas columnas como sea necesario para que los registros sean únicos.
Para el escenario n. ° 3 puede seguir usando la solución anterior (n. ° 1 + n. ° 2) después de estudiar la tabla (* lo que hace que todos los registros sean únicos). Si debe haber incluido TODAS las columnas para que todos los registros sean únicos, puede agregar una columna de clave principal a su tabla. Si esta tabla proviene de un proveedor tercero, clone esta tabla en su base de datos local (de la noche a la mañana o el tiempo que necesite) con la columna de clave principal añadida arbitrariamente a través de su secuencia de comandos de clonación.
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.
Entonces, para citar la respuesta dada por Pratap Reddy, funcionó bien para nosotros.
Tener una clave de identidad inútil no tiene sentido a veces. Me parece que si no se usa el ID, ¿por qué agregarlo? Sin embargo, Entity no es tan indulgente al respecto, por lo que sería mejor agregar un campo de ID. Incluso en el caso de que no se use, es mejor que lidiar con los errores incesantes de la Entidad acerca de la clave de identidad faltante.
El error significa exactamente lo que dice.
Incluso si pudieras evitar esto, créeme, no quieres. La cantidad de errores confusos que se pueden introducir es asombrosa y aterradora, por no mencionar el hecho de que es probable que su rendimiento disminuya.
No trabajes alrededor de esto. Arregla tu modelo de datos
EDITAR: He visto que varias personas están bajando la votación de esta pregunta. Está bien, supongo, pero tenga en cuenta que OP preguntó acerca de mapear una tabla sin una clave principal, no una vista . La respuesta sigue siendo la misma. Trabajar en torno a la necesidad de EF de tener un PK en tablas es una mala idea desde el punto de vista de la capacidad de gestión, la integridad de los datos y el rendimiento.
Algunos han comentado que no tienen la capacidad de corregir el modelo de datos subyacente porque están mapeando a una aplicación de terceros. Esa no es una buena idea, ya que el modelo puede cambiar de debajo de ti. Podría decirse que, en ese caso, desea asignar un mapa a una vista, lo cual, una vez más, no es lo que solicitó el OP.