Máy chủ SQL: Giá trị bảng nội tuyến UDF so với dạng xem nội tuyến

Question

Tôi đang làm việc với hệ thống lưu trữ dữ liệu trong một cấu trúc giống như bảng tính - ngày/giờ trong tiêu đề cột, số đo (ví dụ: tên bác sĩ, Rh, nhóm máu) trong cột đầu tiên của mỗi hàng và một giá trị trong ô giao nhau. Các báo cáo dựa trên cấu trúc này thường yêu cầu phải hiển thị 10 hoặc nhiều hơn các biện pháp này.

Vì mục đích báo cáo, tập dữ liệu cần phải có một hàng cho từng bệnh nhân, ngày/giờ đo được thực hiện và cột cho mỗi phép đo. Về bản chất, người ta cần xoay vòng cấu trúc 90 độ.

Tại một thời điểm, tôi thực sự đã sử dụng chức năng PIVOT của SQL Server để thực hiện điều đó. Vì nhiều lý do, nó trở nên rõ ràng rằng cách tiếp cận này sẽ không hoạt động. Tôi quyết định rằng tôi sẽ sử dụng chế độ xem nội tuyến (IV) để xoa bóp dữ liệu sang định dạng mong muốn. Truy vấn đơn giản tương tự như:

SELECT patient_id, 
     datetime, 
     m1.value AS physician_name, 
     m2.value AS blood_type, 
     m3.value AS rh 
    FROM patient_table 
INNER JOIN (complex query here 
       WHERE measure_id=1) m1... 
INNER JOIN (complex query here 
       WHERE measure_id=2) m2... 
LEFT OUTER JOIN (complex query here 
       WHERE measure_id=3) m3... 

Như bạn có thể thấy, trong một số trường hợp, những IV được sử dụng để hạn chế các bộ dữ liệu kết quả (INNER JOIN), trong trường hợp khác họ không hạn chế dataset (LEFT OUTER JOIN). Tuy nhiên, phần 'truy vấn phức tạp' về bản chất là giống nhau đối với từng biện pháp này, ngoại trừ sự khác biệt trong measure_id. Trong khi cách tiếp cận này hoạt động, nó dẫn đến các câu lệnh SQL khá lớn, giới hạn sử dụng lại và cho thấy truy vấn lỗi.

Suy nghĩ của tôi là thay thế cụm từ 'truy vấn phức tạp' và mệnh đề WHERE bằng một bảng giá trị UDF nội tuyến. Điều này sẽ đơn giản hóa các truy vấn một chút, giảm lỗi và tăng tái sử dụng mã. Câu hỏi duy nhất trong đầu tôi là biểu diễn. Cách tiếp cận UDF có dẫn đến giảm đáng kể hiệu suất không? Nó có thể cải thiện vấn đề?

Cảm ơn bạn đã dành thời gian và cân nhắc.

Answer 1

Bạn cũng có tùy chọn thứ ba; một VIEW truyền thống (giả sử rằng bạn có một chìa khóa để tham gia). Về lý thuyết, không nên có sự khác biệt về hiệu năng giữa ba tùy chọn vì SQL Server nên đánh giá và tối ưu hóa các kế hoạch tương ứng. Thực tế là đôi khi điều đó không xảy ra cũng như chúng tôi muốn.

Lợi ích của chế độ xem truyền thống là bạn có thể biến nó thành chế độ xem được lập chỉ mục và cung cấp cho SQL Server một trợ giúp hiệu suất khác; tuy nhiên, bạn sẽ phải kiểm tra và xem.

Answer 2

Câu trả lời Sql Server 2005: Bạn có thể giảm chế độ xem nội tuyến bằng cách sử dụng bảng tạm thời/var. Các vấn đề về Performace trên đây là các chèn tạm thời mà bạn yêu cầu cho mỗi lần truy cập trên truy vấn, nhưng nếu các tập kết quả đủ nhỏ, chúng có thể trợ giúp. bạn có thể sử dụng các khóa chính trên các bảng var và các khóa/chỉ mục chính trên các bảng tạm thời. Khác với belive bình thường, tôi đã tìm thấy một vài bài báo chỉ ra rằng cả hai temp/var bảng được lưu trữ trong db tạm thời.

Chức năng UDF, chúng tôi nhận thấy có ít hiệu suất hơn, khi bạn có nhiều lớp udfs trong các truy vấn phức tạp, nhưng sẽ duy trì khả năng sử dụng. Đảm bảo tạo chức năng chính xác cho các điều kiện khác nhau được chỉ định. Những người sẽ được sử dụng cho các kết nối bên trong, và những cái sẽ được sử dụng cho các phép nối trái.

Vì vậy, nói chung. Chúng tôi sử dụng UDF, nhưng khi chúng tôi thấy rằng hiệu suất làm suy giảm, chúng tôi di chuyển truy vấn để chèn các lựa chọn UDF vào các bảng temp/var và tham gia vào các bảng đó.

Tạo chức năng để dễ sử dụng/bảo trì và áp dụng hiệu suất nơi ở và khi được yêu cầu.

EDIT:

Nếu bạn được yêu cầu để chạy cho pha lê, và bạn có kế hoạch để sử dụng thủ tục lưu trữ, Có, bạn có thể thực hiện câu lệnh SQL bên trong SP để bảng temp/var.

Hãy cho tôi biết nếu bạn định sử dụng SP. Sql sau đó sẽ cache các kế hoạch sp với các tham số đã cho như requied.

Cũng từ kinh nghiệm trước đó với tinh thể, những điều cần tránh, được nhóm trong Crystal có thể được thực hiện trong SP, số trang nếu không được yêu cầu. và các cuộc gọi chức năng, nếu điều này có thể được xử lý trên máy chủ.

Answer 3

TVF được xác định chính xác sẽ không giới thiệu bất kỳ sự cố nào. Bạn sẽ tìm thấy nhiều xác nhận quyền sở hữu trên các TVF cho nổ mìn cho các vấn đề về hiệu năng so với các khung nhìn và các biến và các biến tạm thời. Điều bình thường không được hiểu là TVF hoạt động khác với quan điểm. Một định nghĩa khung nhìn được đặt vào truy vấn gốc và sau đó trình tối ưu hóa sẽ sắp xếp lại cây truy vấn khi nó thấy phù hợp (trừ khi mệnh đề NOEXPAND được sử dụng trên các khung nhìn được lập chỉ mục). TVF có ngữ nghĩa khác nhau và đôi khi, đặc biệt khi cập nhật dữ liệu, kết quả đầu ra TVF này được đặt cho haloween protection. Nó giúp đánh dấu chức năng WITH SCHEMABINDING, xem Improving query plans with the SCHEMABINDING option on T-SQL UDFs.

Ngoài ra, điều quan trọng là phải hiểu khái niệm về hàm xác định và chính xác. Mặc dù chúng áp dụng chủ yếu cho funcitons giá trị vô hướng, TVF cũng có thể bị ảnh hưởng. Xem User-Defined Function Design Guidelines.

Answer 4

Vì bạn cần chuỗi SQL và có thể không có khả năng thêm chế độ xem hoặc UDF vào hệ thống, bạn có thể muốn sử dụng WITH ... AS để giới hạn truy vấn phức tạp đến một địa điểm (Ít nhất cho câu lệnh này .).

WITH complex(patientid, datetime, measure_id, value) AS 
(Select... Complex Query) 
SELECT patient_id 
,  datetime 
,  m1.value AS physician_name 
,  m2.value AS blood_type 
,  m3.value AS rh 
FROM patient_table 
INNER JOIN (Select ,,,, From complex WHERE measure_id=1) m1... 
INNER JOIN (Select ,,,, From complex WHERE measure_id=2) m2... 
LEFT OUTER JOIN (Select ,,,, From complex WHERE measure_id=3) m3...