Entity Framework: bảng không có khóa chính

Tôi có một DB hiện có mà tôi muốn xây dựng một ứng dụng mới bằng cách sử dụng EF4.0

Một số bảng không có khóa chính được xác định để khi tôi tạo Mô hình dữ liệu thực thể mới, tôi nhận được thông báo sau:

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.

Nếu tôi muốn sử dụng chúng và sửa đổi dữ liệu, tôi nhất thiết phải thêm PK vào các bảng đó hay có cách giải quyết nào để tôi không phải làm vậy không?

Lỗi có nghĩa chính xác những gì nó nói.

Ngay cả khi bạn có thể giải quyết vấn đề này, hãy tin tôi, bạn cũng không muốn. Số lượng lỗi khó hiểu có thể được giới thiệu là đáng kinh ngạc và đáng sợ, chưa kể thực tế là hiệu suất của bạn có thể sẽ đi xuống các ống.

Đừng làm việc xung quanh việc này. Sửa mô hình dữ liệu của bạn.

EDIT: Tôi đã thấy rằng một số người đang bỏ qua câu hỏi này. Điều đó tốt, tôi cho rằng, nhưng hãy nhớ rằng OP đã hỏi về việc ánh xạ một bảng mà không có khóa chính, không phải là một khung nhìn . Câu trả lời vẫn vậy. Làm việc xung quanh nhu cầu của PK để có PK trên các bảng là một ý tưởng tồi từ quan điểm về khả năng quản lý, tính toàn vẹn dữ liệu và hiệu suất.

Một số người đã nhận xét rằng họ không có khả năng sửa mô hình dữ liệu cơ bản vì họ đang ánh xạ tới ứng dụng của bên thứ ba. Đó không phải là một ý tưởng tốt, vì mô hình có thể thay đổi từ bên dưới bạn. Có thể cho rằng, trong trường hợp đó, bạn sẽ muốn ánh xạ tới một khung nhìn, một lần nữa, đó không phải là những gì OP yêu cầu.

Tôi nghĩ điều này được giải quyết bởi Tillito:

Khung thực thể và SQL Server View

Tôi sẽ trích dẫn mục của anh ấy dưới đây:

Chúng tôi đã có cùng một vấn đề và đây là giải pháp:

Để buộc khung thực thể sử dụng cột làm khóa chính, hãy sử dụng ISNULL.

Để buộc khung thực thể không sử dụng cột làm khóa chính, hãy sử dụng NULLIF.

Một cách dễ dàng để áp dụng điều này là bọc câu lệnh chọn của chế độ xem của bạn trong vùng chọn khác.

Thí dụ:

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

đã trả lời 26 tháng 4, 10 lúc 17:00 bởi Tillito

Nếu tôi muốn sử dụng chúng và sửa đổi dữ liệu, tôi nhất thiết phải thêm PK vào các bảng đó hay có cách giải quyết nào để tôi không phải làm vậy không?

Đối với những người tiếp cận câu hỏi này và đang sử dụng Entity Framework Core, bạn không còn cần thiết phải thêm PK để xóa bảng hoặc thực hiện bất kỳ cách giải quyết nào. Kể từ EF Core 2.1, chúng tôi có một loại Truy vấn tính năng mới

Các loại truy vấn phải được sử dụng cho:

• Phục vụ như kiểu trả về cho các truy vấn ad hoc FromSql ().
• Ánh xạ tới các khung nhìn cơ sở dữ liệu.
• Ánh xạ tới các bảng không có khóa chính được xác định.
• Ánh xạ tới các truy vấn được xác định trong mô hình.

Vì vậy, trong DbContext của bạn chỉ cần thêm thuộc tính sau của loại DbQuery<T>thay vì DbSet<T>như dưới đây. Giả sử tên bảng của bạn là MyTable:

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

Các khóa tổng hợp cũng có thể được thực hiện với 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 });
        ...
     }
}

Trong trường hợp của tôi, tôi phải ánh xạ một thực thể vào Chế độ xem, không có khóa chính. Hơn nữa, tôi không được phép sửa đổi Chế độ xem này. May mắn thay, Chế độ xem này có một cột là một chuỗi duy nhất. Giải pháp của tôi là đánh dấu cột này làm khóa chính:

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

Lừa dối EF. Hoạt động hoàn hảo, không ai để ý ... :)

EF không yêu cầu khóa chính trên cơ sở dữ liệu. Nếu có, bạn không thể liên kết các thực thể với các khung nhìn.

Bạn có thể sửa đổi SSDL (và cơ sở dữ liệu) để chỉ định một trường duy nhất làm khóa chính của bạn. Nếu bạn không có một lĩnh vực độc đáo, thì tôi tin rằng bạn đang bị lừa. Nhưng bạn thực sự nên có một trường duy nhất (và PK), nếu không bạn sẽ gặp vấn đề sau này.

Erick

Có một khóa nhận dạng vô dụng đôi khi là vô nghĩa. Tôi tìm thấy nếu ID không được sử dụng, tại sao thêm nó? Tuy nhiên, Entity không tha thứ cho nó, vì vậy thêm trường ID sẽ là tốt nhất. Ngay cả trong trường hợp nó không được sử dụng, vẫn tốt hơn là xử lý các lỗi không liên tục của Entity về khóa nhận dạng bị thiếu.

CÔNG TRÌNH GIẢI PHÁP NÀY

Bạn không cần lập bản đồ thủ công ngay cả khi bạn không có PK. Bạn chỉ cần nói với EF rằng một trong các cột của bạn là cột chỉ mục và cột chỉ mục là không thể rỗng.

Để thực hiện việc này, bạn có thể thêm số hàng vào chế độ xem của mình bằng hàm isNull như sau

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

ISNULL(id, number) là điểm chính ở đây vì nó cho EF biết rằng cột này có thể là khóa chính

Các câu trả lời trên là chính xác nếu bạn thực sự không có PK.

Nhưng nếu có một nhưng nó chỉ không được chỉ định với một chỉ mục trong DB và bạn không thể thay đổi DB (vâng, tôi làm việc trong thế giới của Dilbert), bạn có thể ánh xạ thủ công các trường thành khóa.

Đây chỉ là một bổ sung cho câu trả lời của @Erick T. Nếu không có cột nào có giá trị duy nhất, cách giải quyết là sử dụng khóa tổng hợp, như sau:

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

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

Một lần nữa, đây chỉ là một cách giải quyết. Giải pháp thực sự là sửa chữa mô hình dữ liệu.

Điều này có thể đến trễ để trả lời ... tuy nhiên ...

Nếu một bảng không có khóa chính thì sẽ có một vài kịch bản cần được phân tích để làm cho EF hoạt động chính xác. Quy tắc là: EF sẽ làm việc với các bảng / lớp với khóa chính. Đó là cách nó theo dõi ...

Nói, bảng của bạn 1. Bản ghi là duy nhất: tính duy nhất được tạo bởi một cột khóa ngoại duy nhất: 2. Bản ghi là duy nhất: tính duy nhất được tạo bởi sự kết hợp của nhiều cột. 3. Bản ghi không phải là duy nhất (đối với hầu hết các phần *).

Đối với các kịch bản # 1 và # 2, bạn có thể thêm dòng sau vào mô-đun DbContext Phương thức OnModelCreating: modelBuilder.Entity (). HasKey (x => new {x.column_a, x.column_b}); // càng nhiều cột càng cần thiết để tạo bản ghi duy nhất.

Đối với kịch bản # 3, bạn vẫn có thể sử dụng giải pháp trên (# 1 + # 2) sau khi bạn nghiên cứu bảng (* điều gì làm cho tất cả các bản ghi là duy nhất). Nếu bạn phải bao gồm TẤT CẢ các cột để làm cho tất cả các bản ghi là duy nhất thì bạn có thể muốn thêm một cột khóa chính vào bảng của mình. Nếu bảng này là của nhà cung cấp bên thứ 3 hơn là sao chép bảng này vào cơ sở dữ liệu cục bộ của bạn (qua đêm hoặc bao nhiêu lần bạn cần) với cột khóa chính được thêm tùy ý thông qua tập lệnh sao chép của bạn.

1. Thay đổi cấu trúc Bảng và thêm Cột Chính. Cập nhật mô hình
2. Sửa đổi tệp .EDMX trong Trình soạn thảo XML và thử thêm Cột mới dưới thẻ cho bảng cụ thể này (S NOT KHÔNG LÀM VIỆC)
3. Thay vì tạo một Cột chính mới để thoát khỏi bảng, tôi sẽ tạo một khóa tổng hợp bằng cách liên quan đến tất cả các cột hiện có ( LÀM VIỆC )

Khung thực thể: Thêm DataTable không có Khóa chính cho Mô hình thực thể.

Cập nhật câu trả lời của @CodeNotFound .

Trong EF Core 3.0 DbQuery<T>đã không được chấp nhận, thay vào đó, bạn nên sử dụng các loại thực thể Keyless được cho là làm điều tương tự. Chúng được cấu hình với HasNoKey()phương thức ModelBuilder . Trong lớp DbContext của bạn, hãy làm điều này

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

}

Có những hạn chế, đáng chú ý là:

• Không bao giờ được theo dõi các thay đổi trong DbContext và do đó không bao giờ được chèn, cập nhật hoặc xóa trên cơ sở dữ liệu.
• Chỉ hỗ trợ một tập hợp con các khả năng ánh xạ điều hướng, cụ thể:
  • Họ có thể không bao giờ đóng vai trò là người kết thúc chính của một mối quan hệ.
  • Họ có thể không có sự điều hướng đến các thực thể thuộc sở hữu
  • Chúng chỉ có thể chứa các thuộc tính điều hướng tham chiếu trỏ đến các thực thể thông thường.
  • Các thực thể không thể chứa các thuộc tính điều hướng đến các loại thực thể không cần khóa.

Điều này có nghĩa là cho câu hỏi về

Nếu tôi muốn sử dụng chúng và sửa đổi dữ liệu, tôi nhất thiết phải thêm PK vào các bảng đó hay có cách giải quyết nào để tôi không phải làm vậy không?

Bạn không thể sửa đổi dữ liệu theo cách này - tuy nhiên bạn có thể đọc. Người ta có thể hình dung bằng cách khác (ví dụ: ADO.NET, Dapper) để sửa đổi dữ liệu - đây có thể là một giải pháp trong trường hợp bạn hiếm khi cần thực hiện các thao tác không đọc và vẫn muốn gắn bó với EF Core cho các trường hợp đa số của bạn.

Ngoài ra, nếu bạn thực sự cần / muốn làm việc với các bảng heap (không cần khóa) - hãy xem xét việc bỏ qua EF và sử dụng một cách khác để nói chuyện với cơ sở dữ liệu của bạn.

Từ quan điểm thực tế, mỗi bảng - ngay cả một bảng không chuẩn hóa như bảng kho - nên có một khóa chính. Hoặc, không thành công, ít nhất nó phải có một chỉ mục duy nhất, không thể rỗng.

Nếu không có một số loại khóa duy nhất, các bản ghi trùng lặp có thể (và sẽ) xuất hiện trong bảng, điều này rất có vấn đề đối với cả các lớp ORM và cả về sự hiểu biết cơ bản của dữ liệu. Một bảng có các bản ghi trùng lặp có lẽ là một triệu chứng của thiết kế xấu.

Ít nhất, bảng ít nhất phải có một cột định danh. Việc thêm cột ID tự động tạo mất khoảng 2 phút trong SQL Server và 5 phút trong Oracle. Đối với một chút nỗ lực, nhiều, nhiều vấn đề sẽ được tránh.

Chúng tôi cũng gặp phải vấn đề này và trong khi chúng tôi có một cột có null, điều quan trọng là chúng tôi có một cột phụ thuộc không có null và sự kết hợp của hai cột này là duy nhất.

Vì vậy, để trích dẫn câu trả lời được đưa ra bởi Pratap Reddy, nó hoạt động tốt với chúng tôi.

Tôi rất vui vì vấn đề của tôi đã được giải quyết.

Không thể cập nhật Entityset - vì nó có DefiningQuery và không tồn tại phần tử <UpdateFunction>

và làm điều này: Nhìn bên dưới dòng đó và tìm thẻ. Nó sẽ có một tuyên bố chọn ol 'lớn trong đó. Xóa thẻ và nội dung của nó ..

bây giờ mà không thay đổi DB TI có thể chèn vào bảng không có PK

cảm ơn tất cả và cảm ơn Pharylon

Trong EF Core 5.0, bạn cũng có thể xác định nó ở cấp thực thể.

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

Tham khảo: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/whatsnew#use-ac-attribution-to-indicate-that-an-entity- không có chìa khóa

Bảng chỉ cần có một cột không cho phép null