Đường dẫn di chuyển / triển khai từ giải pháp LocalDB sang đối tượng Enterprise là gì?

Đưa ra định nghĩa mở rộng cho LocalDB của SQL Server 2012 là

SqlLocalDB là một công cụ cơ sở dữ liệu chi phí thấp, cục bộ của SQL Server 2012 (và các phiên bản trong tương lai) cho phép các nhà phát triển tập trung vào phát triển thay vì cấu hình hoặc bảo mật cá thể.

Tôi đã tò mò con đường từ phát triển trong LocalDB đến một cá thể sản xuất sẽ như thế nào, đặc biệt là về các vấn đề với các cá thể người dùng (ca. SQL 2005) và cố gắng thúc đẩy một trong số chúng đến sản xuất và các nhà phát triển sẽ không biết về trường hợp nào họ đã thực sự cố gắng để thúc đẩy. Một tìm kiếm nhanh trên StackOverflow phản bội các vấn đề như vậy dưới nhiều hình thức khác nhau. LocalDB có cải thiện / hợp lý hóa việc triển khai trong các trường hợp như vậy không?

Tôi đã tò mò con đường từ phát triển trong LocalDB đến một cá thể sản xuất sẽ như thế nào

...

LocalDB có cải thiện / hợp lý hóa việc triển khai trong các trường hợp như vậy không?

Không thực sự khác biệt nhiều, phải trung thực. Mặc dù User Instanceskhông còn là một yếu tố, nhưng nhà phát triển vẫn rất dễ dàng tạo ra một loạt các trường hợp SqlLocalDb và không biết ai sẽ giữ phiên bản "thật" của sự thật.

Những gì LocalDb làm là loại bỏ nhu cầu thiết lập một phiên bản đầy đủ dựa trên dịch vụ của SQL Server (Express hoặc cách khác) và giảm độ phức tạp của mô hình bảo mật. Nhà phát triển hoặc nhóm vẫn phải thực hiện các thực tiễn phát triển âm thanh liên quan đến kiểm soát và quảng bá nguồn. Như được thể hiện trong các ý kiến, có một số cách để thúc đẩy mã từ một cá thể cục bộ sang sản xuất (hy vọng thông qua một số loại hệ thống kiểm tra / QA trước tiên):

• phục hồi dữ liệu đã lưu
• dự án cơ sở dữ liệu thông qua VS / SSDT
• Các công cụ so sánh bên thứ 3 như SQL So sánh
• sắp xếp thủ công lược đồ / script / dữ liệu trong điều khiển nguồn
• tạo tập lệnh thủ công tại thời điểm triển khai
• nhập / xuất trình hướng dẫn dữ liệu (báo trước: Tôi chưa thử trình hướng dẫn chống lại SqlLocalDb)

. có nguồn.)

Cho dù bất kỳ vấn đề nào trong số này ít nhiều có cùng loại với các vấn đề như hiện nay, phụ thuộc nhiều vào kỷ luật nhóm và quy trình được thiết lập hơn là việc họ sử dụng Express hay LocalDb để phát triển địa phương. IMHO.

Điều thú vị mà LocalDb cung cấp qua các phiên bản người dùng là nếu bạn kết nối với một phiên bản LocalDb, bạn sẽ không gặp phải trường hợp cụ thể mà mỗi khi bạn sử dụng, AttachDbFileNamebạn sẽ nhận được một bản sao mới của cơ sở dữ liệu. Phần có vấn đề nhất là bạn thay đổi một bảng trong một trường hợp, sau đó gặp lỗi từ ứng dụng của bạn vì nó được kết nối với một bản sao không thay đổi bảng của bạn. Như bạn đã chỉ ra, điều này đã dẫn đến một dòng nhầm lẫn không bao giờ kết thúc và các câu hỏi tương tự trên SO. Trong thực tế, SqlLocalDb vẫn hỗ trợ AttachDbFileName, nhưng tôi nghĩ rằng nó sẽ được sử dụng rất phổ biến, nếu có bao giờ.

Với LocalDb, ít có khả năng bạn gặp phải những vấn đề này, nhưng chúng vẫn tồn tại. Đó là một công cụ khác với một số ưu điểm nhưng nó vẫn có thể được sử dụng không phù hợp.