Làm cách nào để lấy dữ liệu không phải Bảng vào Dịch vụ Báo cáo Máy chủ SQL?

Question

Đưa ra: Một công cụ tính toán C# tải mô hình đối tượng, thu thập một lượng lớn các số và lưu kết quả vào một vài bảng cơ sở dữ liệu khổng lồ được lập chỉ mục khổng lồ trong SQL Server. Các bảng đó cung cấp dữ liệu cho các giao diện web, các mô đun phần mềm khác và các báo cáo SQL Server Reporting Services 2005.

tôi quản lý để làm cho động cơ một nhiều nhanh hơn trong phiên bản mới nhất của phần mềm, đủ nhanh bây giờ mà nó có thể cung cấp dữ liệu theo yêu cầu - đôi khi thậm chí nhanh hơn so với thời gian cần thiết để truy vấn cơ sở dữ liệu cho trước số được tính toán. Tôi rất hạnh phúc về điều này.

Bước đột phá đó có nghĩa là chúng tôi có thể tạo dữ liệu theo yêu cầu cho giao diện web và các mô-đun phần mềm khác. Nhưng các bảng bộ nhớ cache không thể chết được, bởi vì chúng được tiêu thụ bởi các báo cáo SSRS (hoặc cụ thể hơn, bởi các thủ tục lưu trữ truy vấn các bảng và cung cấp dữ liệu cho SSRS.)

Các bảng bộ nhớ cache là một nỗi đau, trong nhiều cùng một cách mà bất kỳ bộ nhớ cache nào cũng là một nỗi đau trong thế giới phần mềm. Nếu không đi vào chi tiết quá nhiều, họ có vấn đề sync'ing, khóa vấn đề, vv vv Các phần mềm sẽ làm việc rất nhiều hơn nữa độc đáo nếu tôi không phải lo lắng về việc giữ những bảng darned đến nay.

Nhưng làm cách nào khác tôi có thể nhận dữ liệu vào SSRS? Tôi đã thực hiện một chút công bằng về nghiên cứu và không có gì có vẻ quá hứa hẹn:

• Chúng tôi có thể cung cấp dữ liệu qua dịch vụ web và sử dụng SSRS XML DPE. Nhưng điều đó có vẻ ghê tởm - tôi có đúng là bạn phải phân tích phong bì SOAP của mình không ?! Và nó không hỗ trợ XPath, nhưng là một phương ngữ XPath-y độc quyền? Các nhà văn báo cáo của chúng tôi biết T-SQL, và đó là những gì họ giỏi nhất.
• Sử dụng SQL CLR để lưu trữ API của chúng tôi là không mong muốn - đó là ứng dụng lớn và bạn không thể làm bất cứ điều gì mà không cần tạo đối tượng ứng dụng và đăng nhập, v.v.
• Sử dụng SQL CLR để liên hệ với dịch vụ web các ứng dụng web - đây là hứa hẹn nhất cho đến nay (bài viết này là hữu ích http://www.simple-talk.com/sql/sql-server-2005/practical-sql-server-2005-clr-assemblies/.) Có ai đã thử phương pháp này? Liệu nó có hoạt động không, nó có thể cung cấp các tập dữ liệu lớn không? OTOH Tôi bị tắt bởi các thiết lập thêm chúng tôi sẽ phải làm trên máy chủ DB khách hàng.
• Bất kỳ đề xuất nào khác sẽ được đánh giá cao.

Answer 1

Nếu tôi hiểu chính xác bạn, bạn đang tạo báo cáo về dữ liệu không phải SQL. Bạn đang lưu trữ dữ liệu trong các bảng cho mục đích cụ thể làm cho chúng có thể báo cáo được.

Tôi có thể nghĩ đến hai giải pháp. Đầu tiên là mở rộng công cụ tính toán C# của bạn với reporting part. Các không gian tên Microsoft.Reporting.WinForms và Microsoft.Reporting.WebForms có thể được sử dụng để xây dựng các báo cáo trên bất kỳ nguồn dữ liệu nào, không chỉ SQL Server. Nếu người dùng cuối sử dụng ứng dụng của bạn làm ứng dụng khách, bạn có thể tạo dữ liệu và báo cáo khi đang di chuyển.

Thứ hai là sử dụng SQL CLR. Bạn có thể sử dụng thủ tục lưu sẵn CLR làm cơ sở cho báo cáo (nhập "exec mysp" làm nguồn dữ liệu.) Thủ tục CLR này là mã C# và có thể bao gồm công cụ tính toán của bạn làm thư viện. Điều này sẽ cho phép bạn tạo báo cáo khi đang di chuyển, trong khi vẫn sử dụng giao diện người dùng của Máy chủ báo cáo.

Thú vị câu hỏi và tôi hy vọng rằng mọi người hiểu biết nhiều hơn có thể cung cấp một câu trả lời tốt hơn :)

Answer 2

Tôi đã ở trong một tình huống tương tự trước đây và thử cả nguồn dữ liệu XML SSRS và phần mở rộng báo cáo rằng Andomar đề cập đến .Khuyến nghị của tôi là sử dụng tính năng nguồn dữ liệu XML SSRS. Nếu cấu trúc dữ liệu được dịch vụ web trả lại rất đơn giản thì XPath cũng đơn giản. Tôi cũng tìm thấy nó dễ dàng hơn để gỡ lỗi. Điều chính để xem ra là thời gian chờ.

Điều tốt với việc sử dụng dịch vụ web là chúng dễ dàng được tiêu thụ bởi nhiều công nghệ khác nhau để chúng có thể trở nên rất tiện dụng để có.

Ngoài ra, đó là một lựa chọn cá nhân nhưng mặc dù các tính năng CLR của SQL tôi vẫn không cảm thấy thoải mái khi đặt mã trong cơ sở dữ liệu. Bằng cách sử dụng một nguồn dữ liệu XML trong SSRS, không cần phải liên quan đến mã CLR tùy chỉnh.

Answer 3

Bạn có thể gói dữ liệu của mình theo số ADO.NET DataSet and use it as a Reporting Services Data Source..

Tôi chưa bao giờ sử dụng cá nhân này nên tôi không thể cung cấp thêm thông tin cho bạn. Tuy nhiên, tôi biết bạn có thể làm điều này từ một lớp SSRS tôi đã tham dự. Ví dụ mà người hướng dẫn đã cho tôi khi bạn làm điều này trong một ví dụ "thế giới thực" sẽ là nếu bạn cần kết hợp dữ liệu từ hai nguồn dữ liệu khác nhau. Ví dụ, bạn sẽ làm điều này nếu bạn muốn tương quan dữ liệu từ SQL Server và Oracle với nhau trong một báo cáo.

Tôi biết đây không phải là những gì bạn muốn làm, nhưng có vẻ như nó sẽ cung cấp cùng một lớp trừu tượng mà bạn cần.

Answer 4

Bạn đã cân nhắc viết trình điều khiển cơ sở dữ liệu tùy chỉnh của riêng mình nằm trên đầu công cụ tính toán của mình chưa? Sau đó bạn có thể chỉ dịch vụ báo cáo ngay tại đó. Điều này sẽ giữ cho mọi thứ nhanh chóng mặc dù nó có thể là một nhiệm vụ phức tạp. Tôi đã xem xét nó trong quá khứ cho phần mềm kho dữ liệu độc quyền tôi đã làm việc trên nhưng không bao giờ có đi trước để xây dựng trình điều khiển.

Câu hỏi tuyệt vời bằng cách này.

Answer 5

Sử dụng CLR SQL để liên lạc với một dịch vụ web trên ứng dụng web

Đây là cách tôi khuyên bạn nên - Tôi đã làm điều này để truy cập vào dữ liệu danh sách SharePoint thông qua các dịch vụ web của họ. Nếu lược đồ dữ liệu có thể được sửa, một CLR SQL CLR có thể phù hợp và mang lại sự linh hoạt lớn nhất. Nếu bạn cần lược đồ được xác định tại thời gian thực thi, thủ tục lưu sẵn SQL CLR là những gì bạn muốn vì nó không bị ràng buộc vào một lược đồ.

Những điều chính mà bạn sẽ cần là:

-- enable CLR on the server 
sp_configure 'clr_enabled', 1 
GO 
RECONFIGURE 
GO 

-- allow your db to execute clr code marked EXTERNAL or UNSAFE 
alter database mydb set trustworthy on 

sau đó tạo ra một dự án sql clr VS (bạn không phải nhưng nó giúp với việc triển khai và gỡ lỗi nó), thiết lập mức độ cho phép để 'bên ngoài'. Nếu bạn sử dụng "Thêm tham chiếu Web" trong dự án VS, bạn sẽ phải bật tính năng tạo chuỗi serialization và CREATE ASSEMBLY để tải nó sau khi bạn xây dựng/triển khai.

Đây là một chút lượn sóng ngay bây giờ - trung thực, tôi đã làm điều này - Tôi sẽ thêm một số chi tiết sau này. Tôi đã nói chuyện về SQL CLR tháng trước. My sample code có dự án GetFibs gọi một dịch vụ web (Fibonnaci) cũng được bao gồm.

Ngoài ra hãy xem ở đây: http://footheory.com/blogs/bennie/archive/2006/12/07/invoking-a-web-service-from-a-sqlclr-stored-procedure.aspx và http://www.codeproject.com/KB/database/SQLCLR.aspx?display=Print

Liệu nó thực hiện được rồi, nó có thể cung cấp tập dữ liệu lớn?

Có, có vẻ như hoạt động tốt.Với một chút công việc phụ, bạn có thể xây dựng nó theo một cách định hướng dòng hơn, nơi nó sẽ không tiêu thụ bộ nhớ cho toàn bộ thiết lập. Xem cách trong mẫu Phạm vi hoặc here.

Answer 6

Tôi chắc chắn sẽ đi xuống số ADO.NET DPE road. Nếu nguồn dữ liệu của bạn có thể cung cấp dữ liệu cần thiết trong thời gian thực, thì nó sẽ có ý nghĩa nhất. Bạn sẽ tiết kiệm cho mình 1,2 hoặc 3 tầng, mà chắc chắn sẽ cải thiện hiệu suất tổng thể. Và không nói về việc bảo trì từng phần mã. Hiển thị số dữ liệu bị nén dưới dạng bộ dữ liệu ADO.NET và cho phép các dịch vụ báo cáo của bạn truy vấn trực tiếp, là ý kiến ​​hay nhất theo ý kiến ​​của tôi.

Answer 7

Trong SQL 2008, bạn có thể sử dụng gói SQL SSIS làm nguồn dữ liệu. Viết một gói SSIS để thực thi công cụ tính toán của bạn khi đang di chuyển và xuất dữ liệu .net trong bộ nhớ (DataReaderDestination). Điều này sau đó có thể được sử dụng để báo cáo.