Có nên tránh lược đồ dbo?


29

Khi nói đến lược đồ dbo:

  • Có phải là một cách thực hành tốt nhất để tránh sử dụng lược đồ dbo khi tạo các đối tượng cơ sở dữ liệu?
  • Tại sao lược đồ dbo nên tránh hoặc nên?
  • Người dùng cơ sở dữ liệu nào nên sở hữu lược đồ dbo?

Một số chuyên gia tư vấn nói rằng nên tránh lược đồ dbo và luôn tạo các lược đồ do người dùng xác định và gán các vật cản vào các lược đồ này.
jrara

Tôi cũng tìm thấy tuyên bố này từ Alexander Kuznetsov trong các bình luận của bài đăng trên blog này :
jrara

Vâng, tránh nó ngay bây giờ. dba.stackexchange.com/a/4109/630dba.stackexchange.com/q/8511/630stackoverflow.com/q/6502222/27535 @JNK: FYI cho bạn cũng vậy
gbn

Câu trả lời:


21

Nó có thể là một thực tiễn tốt vì khi bạn có người dùng khác sử dụng cơ sở dữ liệu, bạn muốn có thể giới hạn quyền truy cập của họ bằng các lược đồ. Ví dụ trong cơ sở dữ liệu bạn có các bảng sau.

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

Là giám đốc nhân sự, tôi có thể truy cập mọi thứ trong HRlược đồ, với tư cách là ITgiám đốc tôi có thể thấy tên người dùng và cấp độ truy cập của nhân viên. Bộ Engineeringphận có thể xem các trang web công việc nào đang hoạt động, v.v ... Nếu dbo là lược đồ được thiết lập cho tất cả các bảng, tôi sẽ gặp khó khăn hơn trong việc phân chia dữ liệu của mình và cung cấp vai trò truy cập.

Tôi tin rằng, trong SQL Server là cung cấp một sản phẩm có thể được truy cập và truy vấn bởi các bộ phận khác nhau. Trong thực tế, chỉ có các DBA / DBDev thực sự truy cập vào cơ sở dữ liệu và nó thường chỉ lưu trữ dữ liệu ứng dụng.

Nó cũng giúp với khả năng đọc và quản lý. Lúc đầu, tôi có thể dễ dàng xác định bảng nào chứa dữ liệu nào và cách tách dữ liệu.

Cá nhân tôi thích xác định các lược đồ như là một thực tiễn chung. Ghi nhớ lược đồ là tiếng Hy Lạp cho kế hoạch, có cấu trúc lược đồ được đặt ra giúp bạn lập kế hoạch và xác định dữ liệu.


6

Tôi nghĩ rằng điều này thực sự phụ thuộc vào sở thích của người dùng vì không có lý do công nghệ thực sự để làm điều này. Trong thực tế, để đơn giản, tôi nói luôn luôn sử dụng dbo trừ khi các yêu cầu bảo mật của bạn quy định khác. Tất nhiên, bạn luôn có thể làm điều đó cho mục đích tổ chức là tốt.


1
100% đằng sau phương pháp này. Tôi thường để các bảng "lõi" trong lược đồ dbo để đơn giản và bắt đầu thêm khi cần. Thông thường, lược đồ riêng đầu tiên tôi thêm là "Giai đoạn" hoặc "Giai đoạn", để nhóm các bảng phân tầng của tôi một cách riêng biệt. Một ví dụ khác là thêm dữ liệu từ một nguồn bên ngoài, nói Twitter. Thay vì tiền tố tất cả các bảng (ví dụ: TwitterAccount, TwitterStatus, v.v.) tôi sẽ tạo một lược đồ "Twitter".
robopim

5

Nếu bất cứ điều gì, nên tránh dbo vì nó là mặc định cho SQL Server, nó cũng không mô tả chút nào. Giống như tất cả các tên mặc định khác, vì nó được biết trước, nó làm cho cuộc sống của hacker trở nên dễ dàng hơn nhiều (mặc dù nếu họ đang cố gắng tìm ra tên lược đồ của bạn thì có lẽ bạn đã bị mắc kẹt).

Nơi tôi làm việc, chúng tôi sử dụng các lược đồ để phân chia cơ sở dữ liệu thành các phần logic và gán quyền cho các lược đồ.

Ví dụ, chúng tôi có thể có một hệ thống kiểm kê với cơ sở dữ liệu. Các bảng chính có thể nằm trong lược đồ inv. Nếu chúng ta nhập bất cứ thứ gì vào cơ sở dữ liệu thì một lược đồ phân tầng sẽ được sử dụng như một phần của quy trình nhập. Nếu chúng tôi có bất kỳ quy trình lưu trữ hệ thống nào mà người dùng không cần truy cập, chúng tôi sẽ đặt chúng vào một lược đồ sp.


1
+1 cho "tránh nó vì nó là mặc định". Buộc người dùng ít nhất phải suy nghĩ về nó một chút khi họ tạo ra một đối tượng.
BradC

4

Đây không phải là cách thực hành tốt nhất trước đây vì các lược đồ đã bị ẩn trước SQL 2005, mọi thứ được đưa vào lược đồ dbo. Nhóm máy chủ SQL hiển thị nó như một cách thực hành tốt nhất và đã xuất bản một bài viết về nó: Thực tiễn tốt nhất về máy chủ SQL - Thực hiện các lược đồ đối tượng cơ sở dữ liệu

Theo như câu hỏi khác của bạn về người nên sở hữu nó: lược đồ dbo được sở hữu bởi tài khoản người dùng dbo.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.