I was just practicing code first new database entity framework from msdn, I wanna know whether a table without primary key can be created in code first new database EF?
No you can't because Entity Framework needs to know the key to keep track on the object when you make an update or delete operation.
Anyway it's not a good idea to have a table without a PrimaryKey
Sometimes adding PK is not possible because it can be read-only, super protected database of a client which you have to use. EF throws exception even on SELECT operations. When I faced that issue I was able to solve it like this (names are artificial):
[Table( "WeirdTable", Schema = "SomeSchema" )]
public class WeirdTable
{
[Column( "ID1" )]
public int Id1 { get; set; }
[Column( "ID2" )]
public int Id2 { get; set; }
}
In the code file of context:
protected override void OnModelCreating( DbModelBuilder model_builder )
{
base.OnModelCreating( model_builder );
model_builder.Entity<WeirdTable>().HasKey(
t => new { t.Id1, t.Id2 }
);
}
So basically you just need to specify which columns can be primary key.
Starting with .NET Core 2.1, EF Core supports models without primary key.
This is realized through a concept of Query Types instead of Enitity Types.
See https://docs.microsoft.com/en-us/ef/core/modeling/query-types
Some of the main usage scenarios for query types are:
- Serving as the return type for ad hoc FromSql() queries.
- Mapping to database views.
- Mapping to tables that do not have a primary key defined.
- Mapping to queries defined in the model.
Query Types have limits though. They cannot be inserted, updated or deleted on the database. And they have only limited support of navigation properties.
EF.Core 5 will have [Keyless]
attribute allowing to have an entity without PK.
But it is still under development.
EF.Core 5 what's new
If your SQL table does not have a primary key, you can still model it in Entity Framework, you will just need to define a key for that Entity. Pick one or more (possibly all) columns on the Entity that, when combined, will uniquely identify that instance within a collection of the entities. Note this is only important for updating or deleting entities, in that they need to be uniquely identified against the others in that collection to target the change. Find/Select and Add/Insert do not require this consistency.
There is a great difference between what EF can do with a database, and what is possible with a database.
Most databases allow for a table to be without a primary key. Most databases also allow for a table to be without a clustered index / Index Organized Table (or what ever it is the specific term for it in other database systems).
There is nothing wrong with that, and one should not state that it is a bad idea to have a table without a PK.
As always, it dependes on the needs and usage of the specific table. e.g. a log table, does not need a PK. It will never be used as a FK, so what is it use?
Bottom line, EF does not support tables without a key out of the box, there are some weird workarounds, but none that I have seen is good enough. That is a shame.