Có những bất lợi cho cơ sở dữ liệu chứa?

SQL Server 2012 đã giới thiệu khái niệm cơ sở dữ liệu "chứa", trong đó mọi thứ (tốt, chủ yếu là mọi thứ) mà cơ sở dữ liệu cần có trong chính cơ sở dữ liệu. Điều này mang lại lợi thế lớn khi di chuyển cơ sở dữ liệu giữa các máy chủ. Sau đó, tôi muốn biết, nếu đây phải là chiến lược mặc định của tôi khi thiết kế cơ sở dữ liệu mới.

MSDN liệt kê một số nhược điểm của cơ sở dữ liệu chứa, và những cái lớn là thiếu hỗ trợ cho việc theo dõi và nhân rộng thay đổi. Có những người khác? Nếu tôi sẽ không sử dụng các tính năng này, có lý do gì để không sử dụng cơ sở dữ liệu chứa không?

Mục đích chính của cơ sở dữ liệu chứa là giúp việc chuyển cơ sở dữ liệu của bạn sang một máy chủ mới dễ dàng hơn mà không cần nhiều giàn giáo xung quanh nó. Với ý nghĩ đó, tôi sẽ xử lý một số vấn đề tiềm ẩn sẽ khiến việc di chuyển này trở nên khó khăn hơn - và hầu hết xoay quanh thực tế là các cơ sở dữ liệu chứa chỉ được chứa một phần trong SQL Server 2012 (ngăn chặn không thực sự được thi hành).

Chuỗi kết nối

Chuỗi kết nối đến cơ sở dữ liệu chứa phải chỉ định rõ ràng cơ sở dữ liệu trong chuỗi kết nối. Bạn không còn có thể dựa vào cơ sở dữ liệu mặc định của thông tin đăng nhập để thiết lập kết nối; nếu bạn không chỉ định cơ sở dữ liệu, SQL Server sẽ không chuyển qua tất cả các cơ sở dữ liệu được chứa và cố gắng tìm bất kỳ cơ sở dữ liệu nào mà thông tin đăng nhập của bạn có thể khớp.

Truy vấn chéo db

Ngay cả khi bạn tạo cùng một người dùng có cùng mật khẩu trong hai cơ sở dữ liệu chứa khác nhau trên cùng một máy chủ, ứng dụng của bạn sẽ không thể thực hiện các truy vấn cơ sở dữ liệu chéo. Tên người dùng và mật khẩu có thể giống nhau, nhưng họ không phải là cùng một người dùng. Lý do cho điều này? Nếu bạn đã chứa cơ sở dữ liệu trên một máy chủ được lưu trữ, bạn không nên bị ngăn chặn có cùng một người dùng được chứa như một người khác đang sử dụng cùng một máy chủ được lưu trữ. Khi ngăn chặn đầy đủ đến (có thể trong phiên bản sau SQL Server 2012 không bao giờ), truy vấn cơ sở dữ liệu chéo sẽ hoàn toàn bị cấm. Tôi rất, rất, rất khuyến khích bạn không nên tạo thông tin đăng nhập cấp máy chủ có cùng tên với người dùng cơ sở dữ liệu có chứa và cố gắng tránh tạo cùng tên người dùng trong các cơ sở dữ liệu có chứa. Nếu bạn cần chạy các truy vấn đánh vào nhiều cơ sở dữ liệu chứa, hãy sử dụng thông tin đăng nhập cấp máy chủ có các đặc quyền phù hợp (bạn có thể nghĩ rằng đây là sysadmin, nhưng đối với các truy vấn chỉ đọc, đây là CONNECT ANY DATABASEvà SELECT ALL USER SECURABLES).

Từ đồng nghĩa

Hầu hết các tên 3 và 4 phần đều dễ xác định và xuất hiện trong DMV. Tuy nhiên, nếu bạn tạo một từ đồng nghĩa trỏ đến tên 3 hoặc 4 phần, những từ này không hiển thị trong DMV. Vì vậy, nếu bạn sử dụng nhiều từ đồng nghĩa, có thể bạn sẽ bỏ lỡ một số phụ thuộc bên ngoài và điều này có thể gây ra sự cố tại điểm bạn di chuyển cơ sở dữ liệu sang máy chủ khác. Tôi đã phàn nàn về vấn đề này, nhưng nó đã bị đóng là "theo thiết kế" và không tồn tại trong quá trình di chuyển sang hệ thống phản hồi mới . Lưu ý rằng DMV cũng sẽ bỏ lỡ các tên 3 và 4 phần được xây dựng thông qua SQL động.

Chính sách mật khẩu

Nếu bạn đã tạo một người dùng cơ sở dữ liệu chứa trên một hệ thống không có chính sách mật khẩu, bạn có thể khó tạo cùng một người dùng trên một hệ thống khác có chính sách mật khẩu. Điều này là do CREATE USERcú pháp không hỗ trợ bỏ qua chính sách mật khẩu. Tôi đã báo lỗi về vấn đề này và nó vẫn mở (và nó cũng không tồn tại khi di chuyển khi Connect đã nghỉ hưu). Và có vẻ lạ đối với tôi rằng trên một hệ thống có chính sách mật khẩu, bạn có thể tạo thông tin đăng nhập cấp máy chủ dễ dàng bỏ qua chính sách, nhưng bạn không thể tạo người dùng cơ sở dữ liệu như vậy - mặc dù người dùng này vốn đã ít rủi ro bảo mật.

Đối chiếu

Vì chúng tôi không còn có thể dựa vào đối chiếu tempdb, nên bạn có thể cần thay đổi bất kỳ mã nào hiện đang sử dụng đối chiếu rõ ràng hoặc DATABASE_DEFAULTsử dụng CATALOG_DEFAULTthay thế. Xem bài viết BOL này cho một số vấn đề tiềm năng .

IntelliSense

Nếu bạn kết nối với cơ sở dữ liệu chứa dưới dạng người dùng được chứa, SSMS sẽ không hỗ trợ đầy đủ IntelliSense. Bạn sẽ nhận được gạch chân cơ bản cho các lỗi cú pháp, nhưng không có danh sách hoặc chú giải công cụ tự động hoàn thành và tất cả nội dung thú vị. Tôi đã gửi một lỗi về vấn đề này, và nó vẫn mở - và một lỗi nữa không tồn tại được.

Công cụ dữ liệu SQL Server

Nếu bạn dự định sử dụng SSDT để phát triển cơ sở dữ liệu, hiện tại không có hỗ trợ đầy đủ cho cơ sở dữ liệu chứa. Điều đó thực sự có nghĩa là việc xây dựng dự án sẽ không thành công nếu bạn sử dụng một số tính năng hoặc cú pháp phá vỡ sự ngăn chặn, vì SSDT hiện không biết ngăn chặn là gì và điều gì có thể phá vỡ nó.

THAY ĐỔI

Khi chạy một ALTER DATABASElệnh từ trong ngữ cảnh của cơ sở dữ liệu chứa, rRather hơn ALTER DATABASE foobạn sẽ cần sử dụng ALTER DATABASE CURRENT- điều này là để nếu cơ sở dữ liệu được di chuyển, đổi tên, v.v. các lệnh này không cần biết gì về bối cảnh bên ngoài hoặc tham chiếu của chúng .

Một vài người khác

Một số thứ bạn có thể không nên sử dụng nhưng dù sao cũng nên được đề cập trong danh sách những thứ không được hỗ trợ hoặc không được dùng nữa và không nên được sử dụng trong cơ sở dữ liệu chứa:

• thủ tục đánh số
• thủ tục tạm thời
• thay đổi đối chiếu trong các đối tượng ràng buộc
• thay đổi dữ liệu
• theo dõi thay đổi
• nhân rộng

Như đã nói, những điều này không nhất thiết là những bất lợi khi sử dụng cơ sở dữ liệu có chứa, chúng chỉ là những vấn đề bạn cần lưu ý và không được tiết lộ rõ ​​ràng trong tài liệu chính thức.

Bạn cũng cần chắc chắn rằng nếu một cơ sở dữ liệu chứa sẽ được di chuyển, hoặc là một phần của nhóm khả dụng hoặc đang được nhân đôi, thì tất cả các máy chủ đích tiềm năng đều có sp_configuretùy chọn contained database authenticationđược đặt thành 1.

Bạn có thể thấy bài đăng trên blog này hữu ích, cũng như bài này , mặc dù họ đã đăng ký trước RTM.

Đối với những người quan tâm đến việc biết thêm chi tiết về cơ sở dữ liệu chứa, tôi có thể khuyên họ nên đọc bài viết này http://www.sqlshack.com/contained-database-in-sql-server/

Bài viết chỉ ra những ưu điểm / nhược điểm chính của việc sử dụng cơ sở dữ liệu chứa.

Nhược điểm

Cơ sở dữ liệu chứa một phần không thể sử dụng các tính năng như sao chép, thay đổi dữ liệu, theo dõi thay đổi, các đối tượng ràng buộc lược đồ phụ thuộc vào các hàm dựng sẵn với các thay đổi đối chiếu.

Ưu điểm

Mặt khác, như đã đề cập, có một số lợi ích của việc sử dụng DB có chứa, chẳng hạn như:

• Khá dễ dàng để di chuyển cơ sở dữ liệu từ máy chủ này sang máy chủ khác,
  vì sẽ không có vấn đề người dùng mồ côi
• Siêu dữ liệu được lưu trữ trên cơ sở dữ liệu chứa để dễ dàng hơn và dễ mang theo hơn
• Có thể có cả xác thực SQL Server và Windows cho người dùng DB có chứa

Bài viết cũng giúp với:

• tạo một cơ sở dữ liệu chứa mới (bằng cách tạo loại ngăn chặn như một phần trong trang Tùy chọn trong SQL Server và sử dụng truy vấn T-SQL để tạo cơ sở dữ liệu sau đó)
• kết nối với DB được chứa bằng SQL Server Management Studio (cần chỉ định tên DB chứa trong tham số kết nối)
• chuyển đổi cơ sở dữ liệu hiện có sang cơ sở dữ liệu chứa
• làm việc trên một cơ sở dữ liệu chứa và liệt kê tất cả các thông tin đăng nhập thuộc loại người dùng được chứa

Một nhược điểm là người dùng cơ sở dữ liệu chứa có thể bị buộc phải thay đổi mật khẩu của riêng họ như đăng nhập có thể ( MUST_CHANGE). Người dùng không thể quản lý mật khẩu của riêng họ trừ khi bạn cấp cho họ quyền thay đổi người dùng và cho họ biết cách thay đổi mật khẩu bằng câu lệnh SQL. Không có nơi nào dễ dàng để họ quản lý nó thông qua giao diện người dùng hoặc ít nhất là tôi không biết làm thế nào.

Lưu ý thêm là, tôi đã tìm thấy cách sử dụng siêu dữ liệu bất ngờ và không có giấy tờ trong mệnh đề "PIVOT" VÀ "UNPIVOT" mà tôi nghĩ rằng nó chỉ nên có trong danh mục hệ thống (sys.tables / sys.columns / v.v.). Như tài liệu trong msd :

Trong cơ sở dữ liệu chứa, đối chiếu danh mục Latin1_General_100_CI_AS_WS_KS_SC . Đối chiếu này là giống nhau cho tất cả các cơ sở dữ liệu chứa trên tất cả các phiên bản của SQL Server và không thể thay đổi.

Nhưng họ đã không đề cập rằng mệnh đề "PIVOT" VÀ "UNPIVOT" cũng sử dụng các danh mục hệ thống như một cơ chế thực thi. do đó, nó tạo ra một lỗi xung đột đối chiếu ở mọi nơi gần khi sử dụng mệnh đề "PIVOT" VÀ "UNPIVOT" trong quá trình di chuyển. đây là một số lời trách móc:

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

bạn cũng có thể thấy rằng các bài viết về cơ sở dữ liệu chứa hầu hết là không đầy đủ. Vì vậy, quyết định sử dụng nó cần một sự ngẫu hứng rất tốt.