Các lược đồ SQL Server có gì tốt?

Tôi không phải là người mới bắt đầu sử dụng cơ sở dữ liệu SQL và đặc biệt là SQL Server. Tuy nhiên, tôi chủ yếu là một anh chàng SQL 2000 và tôi luôn bị nhầm lẫn bởi các lược đồ trong năm 2005+. Vâng, tôi biết định nghĩa cơ bản của lược đồ, nhưng chúng thực sự được sử dụng để triển khai SQL Server thông thường là gì?

Tôi đã luôn luôn sử dụng lược đồ mặc định. Tại sao tôi muốn tạo các lược đồ chuyên ngành? Tại sao tôi chỉ định bất kỳ lược đồ tích hợp nào?

EDIT: Để làm rõ, tôi đoán tôi đang tìm kiếm lợi ích của các lược đồ. Nếu bạn chỉ sử dụng nó như một sơ đồ bảo mật, có vẻ như các vai trò cơ sở dữ liệu đã được điền vào đó .. er .. um .. vai trò. Và sử dụng nó như một công cụ xác định không gian tên dường như là điều bạn có thể làm với quyền sở hữu (dbo so với người dùng, v.v.).

Tôi đoán những gì tôi đang làm là, các lược đồ làm gì mà bạn không thể làm với chủ sở hữu và vai trò? Lợi ích cụ thể của họ là gì?

Các lược đồ nhóm bảng logic, thủ tục, quan điểm với nhau. Tất cả các đối tượng liên quan đến nhân viên trong employeelược đồ, v.v.

Bạn cũng có thể cấp quyền cho chỉ một lược đồ, để người dùng chỉ có thể thấy lược đồ họ có quyền truy cập và không có gì khác.

Giống như không gian tên của mã C #.

Họ cũng có thể cung cấp một loại bảo vệ va chạm đặt tên cho dữ liệu plugin. Ví dụ: tính năng Ghi dữ liệu thay đổi mới trong SQL Server 2008 đặt các bảng mà nó sử dụng trong một lược đồ cdc riêng. Bằng cách này, họ không phải lo lắng về xung đột đặt tên giữa bảng CDC và bảng thực được sử dụng trong cơ sở dữ liệu và vì vấn đề đó có thể cố tình che giấu tên của các bảng thực.

Tôi biết đó là một chủ đề cũ, nhưng tôi chỉ nhìn vào các lược đồ và nghĩ rằng sau đây có thể là một ứng cử viên tốt khác cho việc sử dụng lược đồ:

Trong một Datwarhouse, với dữ liệu đến từ các nguồn khác nhau, bạn có thể sử dụng một lược đồ khác nhau cho mỗi nguồn, sau đó, ví dụ: kiểm soát truy cập dựa trên các lược đồ. Cũng tránh các va chạm đặt tên có thể có giữa các nguồn khác nhau, như một poster khác đã trả lời ở trên.

Nếu bạn giữ lược đồ riêng biệt thì bạn có thể mở rộng một ứng dụng bằng cách triển khai một lược đồ đã cho đến một máy chủ DB mới. (Điều này giả sử bạn có một ứng dụng hoặc hệ thống đủ lớn để có chức năng riêng biệt).

Một ví dụ, xem xét một hệ thống thực hiện đăng nhập. Tất cả các bảng ghi nhật ký và SP nằm trong lược đồ [ghi nhật ký]. Ghi nhật ký là một ví dụ tốt bởi vì rất hiếm (nếu có) rằng các chức năng khác trong hệ thống sẽ chồng lấp các đối tượng (đó là nối với) trong lược đồ ghi nhật ký.

Một gợi ý cho việc sử dụng kỹ thuật này - có một chuỗi kết nối khác nhau cho mỗi lược đồ trong ứng dụng / hệ thống của bạn. Sau đó, bạn triển khai các phần tử lược đồ đến một máy chủ mới và thay đổi chuỗi kết nối của bạn khi bạn cần mở rộng quy mô.

Tôi có xu hướng đồng ý với Brent về điều này ... xem cuộc thảo luận này ở đây. http://www.brentozar.com/archive/2010/05/why-use-schemas/

Nói tóm lại ... các lược đồ không hữu ích lắm, ngoại trừ các trường hợp sử dụng rất cụ thể. Làm cho mọi thứ lộn xộn. Không sử dụng chúng nếu bạn có thể giúp nó. Và cố gắng tuân theo quy tắc K (eep) I (t) S (imple) S (ngu ngốc).

Tôi không thấy lợi ích trong việc khử răng cưa người dùng gắn liền với Lược đồ. Đây là lý do tại sao....

Hầu hết mọi người kết nối tài khoản người dùng của họ với cơ sở dữ liệu thông qua vai trò ban đầu, Ngay sau khi bạn gán người dùng cho sysadmin hoặc vai trò cơ sở dữ liệu db_owner, dưới bất kỳ hình thức nào, tài khoản đó sẽ được đặt bí danh cho tài khoản người dùng "dbo" hoặc có đầy đủ quyền trên cơ sở dữ liệu. Khi điều đó xảy ra, bất kể bạn tự gán cho mình một lược đồ nào ngoài lược đồ mặc định của bạn (có cùng tên với tài khoản người dùng của bạn), các quyền dbo đó được gán cho các đối tượng bạn tạo theo người dùng và lược đồ của bạn. Nó thật vô nghĩa ..... và chỉ là một không gian tên và nhầm lẫn quyền sở hữu thực sự trên các đối tượng đó. Thiết kế nghèo nàn của nó nếu bạn hỏi tôi .... bất cứ ai thiết kế nó.

Những gì họ nên làm là tạo "Nhóm", và loại bỏ các lược đồ và vai trò và chỉ cho phép bạn xếp các nhóm nhóm trong bất kỳ kết hợp nào bạn muốn, sau đó ở mỗi tầng sẽ báo cho hệ thống nếu quyền được kế thừa, từ chối hoặc ghi đè bằng tùy chỉnh những cái. Điều này sẽ trở nên trực quan hơn rất nhiều và cho phép DBA kiểm soát tốt hơn ai là chủ sở hữu thực sự trên các đối tượng đó. Ngay bây giờ, hàm ý của nó trong hầu hết các trường hợp, người dùng SQL Server mặc định dbo có các quyền đó .... không phải là người dùng.

Tại một cửa hàng ORACLE mà tôi đã làm việc trong nhiều năm, các lược đồ đã được sử dụng để đóng gói các thủ tục (và các gói) áp dụng cho các ứng dụng mặt trước khác nhau. Lược đồ 'API' khác nhau cho mỗi ứng dụng thường có ý nghĩa vì các trường hợp sử dụng, người dùng và yêu cầu hệ thống khá khác nhau. Ví dụ: lược đồ 'API' dành cho ứng dụng phát triển / cấu hình chỉ được các nhà phát triển sử dụng. Lược đồ 'API' khác là để truy cập dữ liệu khách hàng thông qua chế độ xem và quy trình (tìm kiếm). Mã đóng gói lược đồ 'API' khác được sử dụng để đồng bộ hóa dữ liệu khách hàng và cấu hình và phát triển với một ứng dụng có cơ sở dữ liệu riêng. Một số lược đồ 'API' này, dưới vỏ bọc, vẫn sẽ chia sẻ các quy trình và chức năng chung với nhau (thông qua 'THÔNG TIN' khác

Tôi sẽ nói rằng không có một lược đồ có lẽ không phải là kết thúc của thế giới, mặc dù nó có thể rất hữu ích. Thực sự, việc thiếu các gói trong SQL Server thực sự tạo ra vấn đề trong tâm trí tôi ... nhưng đó là một chủ đề khác.

Tôi nghĩ rằng các lược đồ giống như rất nhiều tính năng mới (cho dù là SQL Server hay bất kỳ công cụ phần mềm nào khác). Bạn cần đánh giá cẩn thận liệu lợi ích của việc thêm nó vào bộ công cụ phát triển của bạn có làm mất đi sự đơn giản trong thiết kế và triển khai hay không.

Đối với tôi, các lược đồ gần tương đương với các không gian tên tùy chọn. Nếu bạn đang ở trong một tình huống mà các tên đối tượng đang va chạm và mức độ chi tiết của các quyền không đủ tốt, thì đây là một công cụ. (Tôi có khuynh hướng nói rằng có thể có các vấn đề thiết kế nên được xử lý ở cấp độ cơ bản hơn trước.)

Vấn đề có thể là, nếu nó ở đó, một số nhà phát triển sẽ bắt đầu sử dụng nó vì lợi ích ngắn hạn; và một khi nó ở trong đó, nó có thể trở thành kudzu.

Trong SQL Server 2000, các đối tượng được tạo được liên kết với người dùng cụ thể đó, như nếu người dùng, nói Sam tạo một đối tượng, giả sử, nhân viên, bảng đó sẽ xuất hiện như sau: Sam.Emprocod. Điều gì sẽ xảy ra nếu Sam rời khỏi công ty hoặc chuyển sang lĩnh vực kinh doanh khác. Ngay khi bạn xóa người dùng Sam, điều gì sẽ xảy ra với bảng Sam.Emp viên? Có thể, trước tiên bạn sẽ phải thay đổi quyền sở hữu từ Sam.Emp viên sang dbo.Employess. Schema cung cấp một giải pháp để khắc phục vấn đề này. Sam có thể tạo tất cả các đối tượng của mình trong một schemam, chẳng hạn như Emp_Schema. Bây giờ, nếu anh ta tạo một đối tượng Nhân viên trong Emp_Schema thì đối tượng đó sẽ được gọi là Emp_Schema.Emp viên. Ngay cả khi tài khoản người dùng Sam cần được xóa, lược đồ sẽ không bị ảnh hưởng.

phát triển - mỗi nhà phát triển của chúng tôi có lược đồ riêng của họ dưới dạng một hộp cát để chơi.

Đây là một ví dụ triển khai tốt về việc sử dụng các lược đồ với SQL Server. Chúng tôi đã có một số ứng dụng truy cập ms. Chúng tôi muốn chuyển đổi chúng thành một cổng thông tin ứng dụng ASP.NET. Mỗi ứng dụng truy cập ms được viết dưới dạng một Ứng dụng cho cổng thông tin đó. Mỗi ứng dụng truy cập ms có các bảng cơ sở dữ liệu riêng. Một số trong số đó có liên quan, chúng tôi đặt chúng trong lược đồ dbo chung của SQL Server. Phần còn lại có sơ đồ riêng của nó. Theo cách đó, nếu chúng ta muốn biết những bảng nào thuộc về một Ứng dụng trên cổng thông tin ứng dụng ASP.NET có thể dễ dàng điều hướng, trực quan hóa và duy trì.