Công cụ dữ liệu và thực thể máy chủ Sql - có bất kỳ sức mạnh tổng hợp nào ở đây không?

Ra khỏi một dự án sử dụng Linq2Sql, tôi nghi ngờ rằng cái tiếp theo (lớn hơn) có thể đẩy tôi vào vòng tay của Entity Framework. Tôi đã thực hiện một số bài đọc về chủ đề này, nhưng những gì tôi chưa tìm thấy là một câu chuyện mạch lạc về cách Công cụ dữ liệu SQL và Khung công cụ thực thể nên / có thể được sử dụng cùng nhau.

• Có phải họ đã quan niệm hoàn toàn riêng biệt, và sử dụng chúng cùng nhau đang vuốt ve sai cách?
• Có phải chúng bằng cách nào đó hoàn toàn trực giao và tôi đang thiếu điểm?

Một số lý do tại sao tôi nghĩ rằng tôi có thể muốn cả hai:

• SSDT là tuyệt vời để có 'lược đồ' (đã kiểm tra) và dễ dàng phiên bản sql và lược đồ
• Nhưng câu chuyện 'di chuyển / cập nhật' của SSDT không thuyết phục (với tôi): "Cập nhật mọi thứ" hoạt động tốt cho lược đồ, nhưng không có cách nào (AFAIK) mà nó có thể hoạt động đối với dữ liệu.
• Mặt khác, tôi đã không thử di chuyển EF để biết liệu nó có vấn đề tương tự không, nhưng các bit Lên / Xuống trông khá tiện dụng.

Hãy để tôi đưa vào một quan điểm khác. Bảo trì cơ sở dữ liệu khung thực thể hoàn toàn vô dụng trong bất kỳ doanh nghiệp hoặc dự án cơ sở dữ liệu lớn nào.

Vấn đề là:

• Cập nhật lược đồ tự động. Đây hoàn toàn không phải là điều tôi muốn vì nó hoàn toàn vi phạm các nguyên tắc cơ bản của bảo trì cơ sở dữ liệu. Vấn đề là: (a) ai đó đang chạy phiên bản mới hơn cập nhật cơ sở dữ liệu thay vì gặp sự cố và (b) các bản cập nhật được lên lịch với dba thường lấy bản sao lưu FIRST. Vì vậy, cập nhật tự động là vô ích.

• Tạo Db chỉ hoạt động trên các trường hợp cạnh suy thoái về cơ bản. Thậm chí không thử sử dụng các tính năng cơ sở dữ liệu nâng cao - bất kể cái nào. Ví dụ về máy chủ Sql: bao gồm các trường trong chỉ mục, bộ lọc trên chỉ mục, phân vùng, nén, quy tắc xác thực cho các trường.

• Di chuyển - giả định các trường hợp cạnh suy biến một lần nữa: không dễ dàng chuyển đổi dữ liệu hoặc cập nhật nhiều bước. Ví dụ: Bảng X có trường "người dùng" lịch sử ghi lại người dùng thực hiện việc gì đó. Thiết lập mới có bảng Người dùng, do đó, người ta cần tạo bảng người dùng, sau đó tạo người dùng, sau đó tạo trường tham chiếu người dùng trong bảng x, sau đó cập nhật bảng này với người dùng từ bảng người dùng, sau đó xóa trường người dùng.

Cách hợp lý duy nhất để đối phó với các kịch bản này là các kịch bản tạo và di chuyển và phiên bản phù hợp.

Bây giờ, SSDT - đó là một công cụ tuyệt vời để phiên bản một phiên bản cơ sở dữ liệu cụ thể tốt hơn nhiều so với Entity Framework vì nó thực sự - hoạt động. Như trong: nó ghi lại tất cả các tính năng. Trên bất kỳ cơ sở dữ liệu nào tôi có, tôi gần như có thể sử dụng mã trước tiên - bởi vì chúng tôi luôn có các chỉ số được lọc ít nhất;) EF thậm chí sẽ không đưa tôi đến 10% những gì tôi cần.

Cách tiếp cận của chúng tôi là:

• Thiết kế cơ sở dữ liệu trong cơ sở dữ liệu, sau đó đồng bộ hóa xuống mô-đun SSDT được kiểm tra. Đồng bộ hóa lược đồ cho phép các nhà phát triển cập nhật phiên bản của họ nhanh chóng. Luôn có một cơ sở dữ liệu chính có thẩm quyền với phiên bản hiện tại ở đâu đó (trên một máy chủ đặc biệt) để chúng tôi có phiên bản tham chiếu để làm việc.

• Tạo các tập lệnh delta khi cần cho các bản phát hành cũng được phiên bản và có một cơ chế tốt để triển khai chúng vào cơ sở dữ liệu.

Có nhiều hơn một cách để sử dụng EF với cơ sở dữ liệu SQL Server.

1. Code-First ... Bạn viết các lớp và EF tạo các bảng liên quan
2. Cơ sở dữ liệu Đầu tiên ... Bạn thiết kế các bảng và EF tạo các lớp.

EF sẽ không nhất thiết phải làm tất cả công việc cho bạn. EF sẽ giúp bạn có khoảng 80 đến 95 phần trăm ở đó. 5 đến 20 phần trăm nỗ lực phát triển cơ sở dữ liệu khác của bạn sẽ được bổ sung các tối ưu hóa như Chế độ xem và Thủ tục lưu trữ.

Vì vậy, không, chúng không trực giao. Nhưng bạn sẽ phải quyết định chiến lược thiết kế tổng thể của mình sẽ là gì, và sau đó dựa vào các công cụ như SSDT để giúp bạn tối ưu hóa những phần mà EF tạo ra ít hơn kết quả lý tưởng.