Tiêu chí quyết định khi nào nên sử dụng lược đồ không dbo so với Cơ sở dữ liệu mới

Tôi hầu hết là một nhà phát triển ứng dụng nhưng thấy mình phải làm tất cả các công việc cơ sở dữ liệu trước cho dự án hiện tại của mình ( btw ... MS SQL Server 2008 của nó ). Như một quyết định đầu tiên, tôi đang cố gắng tìm hiểu xem nên phân chia trạng thái của mình bằng cách sử dụng Cơ sở dữ liệu riêng biệt hay sử dụng Schema riêng biệt trong cùng một cơ sở dữ liệu. Tôi đã đọc một chút về Lược đồ máy chủ SQL và có vẻ như là một cách tự nhiên để phân tách các miền đối tượng ( mà tôi thích ), nhưng tôi không chắc liệu có thể có chi phí ẩn cho mẫu này không.

Những điều thiết thực hơn tôi nên xem xét khi lựa chọn giữa hai cách tiếp cận này là gì? Nếu tôi tránh được sự dbo.mytableủng hộ, myschema.mytabletôi sẽ tạo ra những thách thức ( hoặc vấn đề ) khác cho kiến ​​trúc của mình chứ?

Như một lưu ý phụ ... Tại một số điểm, điều này sẽ được chuyển giao cho một DBA thực sự để duy trì / hỗ trợ vì vậy tôi đang cố gắng đảm bảo rằng tôi không làm cho cuộc sống của họ khó khăn hơn.

Tôi sẽ bắt đầu bằng cách nói đừng coi lược đồ là không gian tên hoặc miền đối tượng theo nghĩa OO. Các lược đồ về cơ bản là các thùng chứa quyền với một số giá trị gia tăng (xem bên dưới)

Ngoài ra, "lược đồ riêng" hoặc "cơ sở dữ liệu riêng biệt" là 2 khái niệm khác nhau. Dữ liệu cần phải được giao dịch và tham chiếu nhất quán cần phải nằm trong cùng một cơ sở dữ liệu. Xem một cơ sở dữ liệu hoặc mười? bài viết blog để biết thêm.

Trong cơ sở dữ liệu đó, bạn có thể hoặc không thể sử dụng các lược đồ để tổ chức các đối tượng của mình.

Cá nhân, tôi là một fan hâm mộ của các lược đồ và luôn sử dụng chúng nhưng cho những thứ như quyền và nhóm hợp lý. Vì thế, tôi sẽ giới thiệu cho bạn những câu hỏi trước đây để bạn có thể thấy ý kiến ​​chung có lợi cho họ:

• Thiết kế lược đồ - thực hành tốt nhất?
• Tôi nên tuân theo tiêu chuẩn nào khi đặt tên bảng và khung nhìn?
• Sử dụng quá mức / sử dụng đúng các lược đồ?

Đối với trường hợp cho các cơ sở dữ liệu riêng biệt, hãy xem câu trả lời của Aaron , nhưng tất cả đều xoay quanh yêu cầu "nhất quán về mặt giao dịch và tham chiếu".

Đồng ý với @gbn. Tôi đã kiến ​​trúc các giải pháp sử dụng các lược đồ để phân tách và cơ sở dữ liệu để phân tách và tôi thấy việc sử dụng cơ sở dữ liệu là thực tế hơn nhiều. Một vài lý do:

1. Để ứng dụng của bạn kết nối với cơ sở dữ liệu cụ thể theo ngữ cảnh và sau đó chạy các truy vấn tương tự dễ dàng hơn nhiều so với việc truy vấn của bạn được đặt <schema>trước tất cả các tham chiếu đối tượng. Điều này cho vay rất nhiều SQL động, rất nhiều thông tin đăng nhập ứng dụng khác nhau với các lược đồ mặc định (có nghĩa là mã của bạn sẽ không sử dụng tiền tố lược đồ, dựa vào lược đồ mặc định của người dùng ứng dụng - có thể dẫn đến lỗi bộ nhớ cache kế hoạch lớn và gỡ lỗi khó khăn), hoặc rất nhiều thủ tục được lưu trữ để quản lý (hình ảnh chỉ là một báo cáo đơn giản, nếu bạn cần một quy trình cho mỗi lược đồ, thì mã sẽ thay đổi, bây giờ bạn phải thay đổi cùng một mã nhiều lần, cho mỗi lược đồ).
2. Việc tách biệt bằng cơ sở dữ liệu cho phép bạn linh hoạt di chuyển các cơ sở dữ liệu bận rộn sang lưu trữ / trường hợp nhanh hơn hoặc khác nhau mà không phải tách các đối tượng ra khỏi một cơ sở dữ liệu bao gồm tất cả lớn. Hầu hết mọi người không nghĩ về điều này trước cho đến nay, nhưng nó chắc chắn là một vấn đề quy mô tiềm năng. Đặc biệt là nếu bạn kết thúc việc có một lược đồ "tiếp quản" và yêu cầu hầu hết các tài nguyên trên máy chủ, thì việc tách chúng ra có thể là một nhiệm vụ cực kỳ cồng kềnh, ngay cả khi chúng đã được phân tách bằng lược đồ.
3. Các cơ sở dữ liệu riêng biệt cũng có thể cho phép bạn có lịch bảo trì và sao lưu khác nhau cho mỗi bộ phận. Tôi không chắc ý của bạn là gì khi "chia theo trạng thái" nhưng giả sử bạn có nghĩa là cô lập khách hàng, bạn có thể có những khách hàng có yêu cầu khác nhau và khả năng chịu mất dữ liệu, bảo trì chỉ số, v.v.
4. Bạn có thể kết thúc với những khách hàng, theo luật pháp hoặc theo chính sách của công ty, cần bạn tách biệt dữ liệu của họ với bất kỳ ai khác. Điều này thường được chấp nhận ở cấp cơ sở dữ liệu, nhưng mức lược đồ thường sẽ không đủ. Bạn có thể không có những khách hàng này ngay bây giờ, nhưng nó có thể trở thành một vấn đề thực sự sau này nếu bạn làm như vậy.