Là lồng nhau xem một thiết kế cơ sở dữ liệu tốt?

Tôi đã đọc ở đâu đó từ lâu. Cuốn sách nói rằng chúng ta không nên cho phép có một khung nhìn lồng nhau trong SQL Server. Tôi không chắc chắn lý do tại sao chúng ta không thể làm điều đó hoặc tôi có thể nhớ tuyên bố không chính xác.

Sinh viên

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

Giáo viên

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

Trường học

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

Tại nơi làm việc của tôi, tôi đã điều tra một trong những ứng dụng cơ sở dữ liệu trong nhà của chúng tôi. Tôi đã kiểm tra thông qua các đối tượng phát hiện ra rằng có hai hoặc ba lớp khung nhìn xếp chồng lên nhau. Vì vậy, đó là nhắc nhở tôi về những gì tôi đọc trong quá khứ. Có ai có thể giúp giải thích nó?

Nếu nó không ổn để làm như vậy, tôi muốn biết rằng nó chỉ giới hạn ở SQL Server hoặc nói chung là dành cho thiết kế cơ sở dữ liệu.

Thông tin bổ sung: Tôi đã cập nhật một ví dụ từ công ty của tôi. Tôi thay đổi một chút để tổng quát hơn mà không cần quá nhiều kỹ thuật (quá nhiều cột trong ví dụ này). Chủ yếu là khung nhìn lồng nhau mà chúng ta sử dụng dựa trên khung nhìn trừu tượng hoặc tổng hợp. Ví dụ, chúng tôi có một bảng sinh viên lớn với hàng trăm cột. Nói, Eligible Student Viewđược dựa trên các sinh viên ghi danh năm nay. Và chế độ xem đủ điều kiện của sinh viên có thể được sử dụng ở những nơi khác như trong thủ tục lưu trữ.

Bất kể nền tảng, các nhận xét sau đây áp dụng.

(-) Các khung nhìn lồng nhau:

• khó hiểu và gỡ lỗi hơn

  ví dụ: cột xem cột này đề cập đến cái gì? Hãy tìm hiểu qua 4 cấp độ của định nghĩa xem ...

• làm cho trình tối ưu hóa truy vấn khó hơn để đưa ra kế hoạch truy vấn hiệu quả nhất

  Xem cái này , cái này , cái này và cái này cho bằng chứng giai thoại. So sánh với điều này , điều này cho thấy trình tối ưu hóa thường đủ thông minh để giải nén chính xác các khung nhìn lồng nhau và chọn một gói tối ưu, nhưng không phải không có chi phí biên dịch.

  Bạn có thể đo chi phí hiệu suất bằng cách so sánh truy vấn xem với một truy vấn tương đương được viết với các bảng cơ sở.

(+) Mặt khác, các khung nhìn lồng nhau cho phép bạn:

• tập trung và tái sử dụng tập hợp hoặc quy tắc kinh doanh
• trừu tượng hóa cấu trúc cơ bản của bạn (giả sử, từ các nhà phát triển cơ sở dữ liệu khác)

Tôi thấy rằng chúng hiếm khi cần thiết.

Trong ví dụ của bạn, bạn đang sử dụng các khung nhìn lồng nhau để tập trung và sử dụng lại các định nghĩa kinh doanh nhất định (ví dụ: "Sinh viên đủ điều kiện là gì?"). Đây là một sử dụng hợp lệ cho các khung nhìn lồng nhau. Nếu bạn đang duy trì hoặc điều chỉnh cơ sở dữ liệu này, hãy cân nhắc chi phí để giữ chúng so với việc loại bỏ chúng.

• Giữ: Bằng cách giữ các quan điểm lồng nhau, bạn phải chịu những lợi thế và bất lợi được liệt kê ở trên.

• Xóa: Để xóa các khung nhìn lồng nhau:

  1. Bạn cần thay thế tất cả các lần xuất hiện của các khung nhìn bằng các truy vấn cơ sở của chúng.

  2. Bạn phải nhớ cập nhật tất cả các truy vấn có liên quan nếu định nghĩa của bạn về học sinh / giáo viên / trường đủ điều kiện thay đổi, trái ngược với việc chỉ cập nhật định nghĩa chế độ xem có liên quan.

Đôi khi các khung nhìn lồng nhau được sử dụng để ngăn chặn các tập hợp lặp lại. Giả sử bạn có chế độ xem đếm tin nhắn và nhóm chúng theo userid, bạn có thể có chế độ xem số lượng người dùng có> 100 tin nhắn, loại đó. Điều này hiệu quả nhất khi chế độ xem cơ sở là chế độ xem được lập chỉ mục - bạn không nhất thiết muốn tạo một chế độ xem được lập chỉ mục khác để thể hiện dữ liệu với một nhóm khác một chút, bởi vì bây giờ bạn đang trả tiền cho bảo trì chỉ mục hai lần, nơi hiệu suất có thể là đầy đủ so với quan điểm ban đầu.

Nếu tất cả chỉ là các chế độ xem lồng nhau trong đó bạn đang chọn * nhưng thay đổi thứ tự hoặc trên cùng, có vẻ như điều này sẽ được gói gọn hơn dưới dạng một thủ tục được lưu trữ với các tham số (hoặc các hàm có giá trị bảng nội tuyến) so với một loạt các khung nhìn lồng nhau. IMHO.

Các phiên bản sau này của SQL (2005+) có vẻ tốt hơn trong việc tối ưu hóa việc sử dụng các khung nhìn. Lượt xem là tốt nhất để củng cố các quy tắc kinh doanh. EG: nơi tôi làm việc, chúng tôi có một cơ sở dữ liệu sản phẩm viễn thông. Mỗi sản phẩm được gán cho một kế hoạch tỷ lệ và kế hoạch tỷ lệ đó có thể được hoán đổi và tỷ lệ trên kế hoạch tỷ lệ có thể được kích hoạt / hủy kích hoạt khi tỷ lệ được tăng hoặc sửa đổi.

Để làm cho nó dễ dàng, chúng ta có thể làm cho các khung nhìn lồng nhau. Chế độ xem thứ nhất chỉ tham gia các tỷ lệ theo tỷ lệ của chúng bằng cách sử dụng bất kỳ bảng nào là cần thiết và trả lại bất kỳ dữ liệu cần thiết nào mà các mức xem tiếp theo sẽ cần. (Các) chế độ xem thứ 2 chỉ có thể cách ly các tỷ lệ hoạt động và tỷ lệ hoạt động của chúng. Hoặc, chỉ là giá khách hàng. Hoặc giá nhân viên (để giảm giá nhân viên). Hoặc kinh doanh so với tỷ lệ khách hàng dân cư. (tỷ lệ có thể nhận được phức tạp). Vấn đề là, khung nhìn nền tảng đảm bảo logic kinh doanh tổng thể của chúng tôi cho các tỷ lệ và tỷ lệ được kết hợp với nhau đúng cách tại một địa điểm. Lớp quan điểm tiếp theo giúp chúng tôi tập trung hơn vào các tỷ lệ cụ thể (loại, hoạt động / không hoạt động, v.v.).

Tôi đồng ý rằng các chế độ xem có thể khiến việc gỡ lỗi trở nên lộn xộn nếu bạn xây dựng các truy vấn và chế độ xem cùng một lúc. Nhưng, nếu bạn đang sử dụng chế độ xem đáng tin cậy, nó sẽ giúp việc gỡ lỗi dễ dàng hơn. Bạn biết rằng chế độ xem đã được thông qua người rung chuông, vì vậy bạn biết rằng rất có thể nó không gây ra vấn đề.

Các vấn đề có thể đến với quan điểm của bạn, mặc dù. "nếu một sản phẩm chỉ liên quan đến kế hoạch tỷ lệ không hoạt động thì sao?" hoặc "nếu tỷ lệ chỉ có tỷ lệ không hoạt động trên đó thì sao?" Chà, điều đó có thể bị bắt ở cấp độ đầu với logic bắt lỗi người dùng. "Lỗi, sản phẩm nằm trong kế hoạch tỷ lệ không hoạt động ... vui lòng sửa". Chúng tôi cũng có thể chạy kiểm tra truy vấn để kiểm tra lại trước khi chạy hóa đơn. (chọn tất cả các gói và rời khỏi tham gia vào chế độ xem tỷ lệ hoạt động, chỉ trả lại các gói không nhận được kế hoạch tỷ lệ hoạt động vì các vấn đề cần được giải quyết).

Điểm hay của việc này là các chế độ xem cho phép bạn ngưng tụ rất nhiều truy vấn để báo cáo, thanh toán, v.v. Bạn có thể có chế độ xem tài khoản khách hàng, sau đó là chế độ xem cấp 2 chỉ dành cho khách hàng đang hoạt động. Đội ngũ với một cái nhìn của địa chỉ khách hàng. Nhóm có quan điểm về (các) sản phẩm (đã tham gia vào những sản phẩm mà khách hàng có). Đội ngũ để xem kế hoạch tỷ lệ sản phẩm. Đội ngũ với quan điểm của các tính năng sản phẩm. Xem, xem, xem, từng thử-n-sai để đảm bảo tính toàn vẹn. Truy vấn cuối của bạn bằng cách sử dụng các khung nhìn là rất nhỏ gọn.

biên tập:

Như một ví dụ về cách xem sẽ tốt hơn so với chỉ một truy vấn phẳng của các bảng ... chúng tôi đã có một nhà thầu tạm thời đến để thực hiện một số thay đổi. Họ nói với anh ta có quan điểm cho mọi thứ, nhưng anh ta quyết định làm phẳng tất cả các truy vấn của mình. Thanh toán đã loại bỏ một số truy vấn của anh ấy. Họ tiếp tục nhận được nhiều tỷ lệ và tỷ lệ trên mọi thứ. Hóa ra các truy vấn của anh ta thiếu các tiêu chí để chỉ cho phép tỷ lệ hóa đơn nếu chúng nằm trong khoảng thời gian từ ngày bắt đầu và ngày kết thúc, kế hoạch giá được cho là sử dụng tỷ lệ đó / trong thời gian đó. Úi. Nếu anh ta đã sử dụng khung nhìn, thì nó đã tính đến logic đó.

Về cơ bản, bạn phải cân nhắc hiệu suất so với sự tỉnh táo. Có lẽ bạn có thể làm tất cả các loại công cụ ưa thích để tăng hiệu suất của cơ sở dữ liệu. Nhưng, nếu điều đó có nghĩa là đó là một cơn ác mộng đối với một người mới tiếp quản / duy trì, nó có thực sự xứng đáng không? Có thực sự đáng để anh chàng mới phải chơi whack-a-mol phải tìm tất cả các truy vấn cần thay đổi logic của họ (và có nguy cơ anh ta quên / ngón tay mập của họ) b / c ai đó quyết định quan điểm là "xấu" và không hợp nhất một số logic kinh doanh cốt lõi thành một logic có thể được sử dụng trong 100 truy vấn khác? Điều đó thực sự phụ thuộc vào doanh nghiệp của bạn và nhóm IT / IS / DB của bạn. Nhưng, tôi thích sự rõ ràng và hợp nhất nguồn đơn hơn hiệu suất.

Vấn đề thực sự không phải là quan điểm lồng nhau trong chính họ. Vấn đề thực sự là sự phổ biến của các khung nhìn lồng nhau khi các nhà phát triển điều chỉnh lớp bổ sung trên các khung nhìn hiện có. Tôi đã tìm thấy các truy vấn với 4 lớp xem lồng nhau thực sự được nối với một trong các khung nhìn trong định nghĩa của nó. Xu hướng của chúng ta là đưa ra cách dễ dàng hơn là phân tích và giải quyết vấn đề là gốc rễ của vấn đề.

Trong môi trường của tôi, chúng tôi sao chép rất nhiều bảng từ máy chủ sản xuất sang máy chủ báo cáo. Trên máy chủ báo cáo, chúng tôi có rất nhiều khung nhìn dựa trên các bảng sản xuất được nhân rộng VÀ được lồng vào nhau. Trước khi bắt đầu sao chép, chúng tôi phải xóa tất cả các khung nhìn để có thể sao chép (chúng tôi sử dụng thả và tạo vì cấu trúc bảng thường thay đổi trong sản xuất). Sau khi nhân rộng kết thúc, chúng tôi phải xây dựng lại tất cả các quan điểm.

Bây giờ đây là phần thú vị: Vì nhiều chế độ xem được lồng nhau, chúng tôi phải xây dựng lại chúng theo một thứ tự cụ thể. Trong khi thực hiện bất kỳ thay đổi trong định nghĩa quan điểm, chúng ta phải chú ý để giữ trật tự xây dựng lại chính xác. Đó là một mớ hỗn độn. Tôi đặc biệt không khuyến khích sử dụng các khung nhìn lồng nhau nếu bạn sử dụng sao chép hoặc chỉ đơn giản là thả và xây dựng lại các bảng của bạn, đó là nguồn cho các khung nhìn.

Hiệu suất là một điều khác. Các khung nhìn dựa trên các khung nhìn khác không có gì khác ngoài nhiều truy vấn để thực hiện. Dễ dàng hơn để đặt truy vấn lớn hơn cùng nhau, tạo một công việc và tạo một bảng từ đó. Dễ dàng hơn và cải thiện hiệu suất.