Sử dụng quá mức / sử dụng đúng các lược đồ?

Khi được hỏi Câu hỏi này trên Stackoverflow , tôi tự hỏi những gì tôi đã làm là đúng / thực hành tốt nhất.

Về cơ bản, mọi đối tượng mà tôi tạo ra sẽ đi vào một lược đồ với tên lược đồ phản ánh việc sử dụng. Ví dụ, tôi có các lược đồ Auditvà Admin(trong số những người khác).

Điều này lần lượt không để lại đối tượng dbo. Được không Có điều gì khác mà tôi cần phải làm không?

Các lược đồ không chỉ là một công cụ bảo mật tuyệt vời (đó là lý do đủ để sử dụng chúng), mà chúng còn hoàn hảo để phân tách logic. Và dường như đây là những gì bạn đang thực hành.

Ngay cả khi yêu cầu hiện tại không cần bảo mật đặc biệt, hãy nói rõ tất cả các đối tượng cơ sở dữ liệu có liên quan đến Kiểm toán phải được bảo mật cho vai trò cơ sở dữ liệu. Nếu các đối tượng này nằm rải rác trong dbolược đồ, thì bạn sẽ phải cấp denyphép rõ ràng cho các đối tượng riêng lẻ. Nhưng với Auditlược đồ, bạn thực hiện một lần duy nhất denyvà bạn đã thiết lập.

Cá nhân tôi thực hành việc sử dụng các lược đồ. Tuy nhiên, giống như tất cả mọi thứ trong cơ sở dữ liệu, có một phương tiện hạnh phúc. Tôi sẽ không tạo một lược đồ cho từng khía cạnh chi tiết của lớp dữ liệu. Có những thứ như quá nhiều lược đồ và sự tách biệt. Nhưng tôi đoán bạn không ở đâu gần đó.

Một mô hình điển hình là schemas dựa trên quyền, vì vậy bạn phải WebGUI, Desktopvv cho mã vì vậy tất cả đối tượng có permissons cùng từ giản đồ .

Nếu bạn có các nhóm người dùng rõ ràng thì bạn có thể cho phép điều đó, nhưng bạn sẽ kết thúc với các quyền chồng chéo và lộn xộn tại một số điểm. Tôi có xu hướng trì hoãn việc kiểm tra người dùng / nhóm đối với một số kiểm tra bên trong mã và không phải đối tượng quyền: giả sử bạn có người dùng Admin và HR Excel: tất cả đều chạy Desktopmã.

Dữ liệu thường được chia sẻ vì vậy tôi muốn có một Datalược đồ, có thể là một Historyhoặc Archivegiản đồ.

Một số mã không công khai (như UDF hoặc Proc nội bộ) vì vậy tôi sử dụng Helperlược đồ cho mã không được chạy bởi mã máy khách.

Cuối cùng, schemas thích Staginghoặc Systemhoặc Maintenanceđôi khi hữu ích.

Mặc dù không có đối tượng người dùng trong dbolược đồ, người dùng dbosở hữu tất cả các lược đồ.

Không có đối tượng trong dbolược đồ là hoàn toàn tốt. Từ những gì tôi có thể thấy đó không phải là lạm dụng các lược đồ, - mặc dù có bao nhiêu lược đồ là "quá nhiều" là một câu hỏi khá chủ quan (nó có thể so sánh với "Thiết kế OO của tôi có bao nhiêu lớp?").

Điều khác duy nhất tôi muốn đề cập là cấp quyền trên lược đồ chứ không phải các đối tượng riêng lẻ (câu hỏi SO của bạn không chỉ định bất cứ điều gì về quyền).

Tôi muốn sử dụng các lược đồ để phân tách cơ sở dữ liệu theo các mô-đun và mô hình sử dụng. Tôi thấy rằng nó làm cho nó rất dễ hiểu các bảng cơ sở dữ liệu do đó việc bảo trì trở nên dễ dàng hơn. Tôi đã theo các loại lược đồ trong dự án máy chủ sql cuối cùng của tôi. LT - Bảng tra cứu

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Đối với một mô-đun lớn, chúng tôi cũng tách chúng thành nhiều lược đồ hơn. Ví dụ mô-đun personel bao gồm hơn 5 mô-đun.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Chúng tôi cũng bao gồm các lược đồ như cho các hoạt động khác TEMP, MAINTANENCE. Trong studio quản lý, bạn có thể lọc bằng tên lược đồ. Một nhà phát triển chịu trách nhiệm cho MODULE1, lọc theo tên và hoạt động gần như mọi lúc chỉ với các bảng này. Điều này làm cho nó rất dễ dàng cho các nhà phát triển, dbas, người mới đến để hiểu các bảng cơ sở dữ liệu.

Thực tiễn tốt nhất có thể khác với máy chủ sql so với oracle tuy nhiên kinh nghiệm của tôi là càng ít lược đồ thì càng tốt.
Tôi muốn có một lược đồ cho dba / lập trình viên có các đặc quyền đặc biệt và một số mã để bảo trì. Tất cả các dữ liệu kinh doanh nên đi trong một lược đồ để bạn biết nó ở đâu. Các quy ước đặt tên là đủ để phân biệt giữa việc sử dụng bảng hoặc mã được lưu trữ.
Tôi có thể thấy một trường hợp bạn có nhiều đơn vị kinh doanh do có nhiều dữ liệu khác nhau với mỗi đơn vị có lược đồ riêng. Nếu không thì giữ cho nó đơn giản.