Sql Server Reporting Services vs Reporting Via .NET Application

Question

Sếp của tôi muốn tôi tạo một vài báo cáo trong tương lai gần và tôi nghĩ anh ta muốn sử dụng Dịch vụ báo cáo SQL Server để triển khai báo cáo. Tôi không chắc rằng đây sẽ là một ý tưởng tuyệt vời khi chúng tôi là một tổ chức khá nhỏ và tôi không thể thấy chúng tôi sử dụng tốt hoặc cần các tính năng mà giải pháp này cung cấp như thiết lập Người dùng, Nhóm và Đăng ký.

Mặc dù trước đây tôi chưa từng sử dụng SSRS, tôi đã xem một hội thảo trên web trong 3 ngày và có vẻ như đây là một trong những điều tốt đẹp và ổn cho các tình huống đơn giản nhưng trở thành nỗi đau & quá giới hạn khi yêu cầu trở nên phức tạp hơn. Tôi sẽ triển khai nhiều báo cáo dưới dạng báo cáo cục bộ (.rdlc) trong ứng dụng .net vì:

1. Tôi sẽ xử lý dữ liệu định dạng & với .NET rồi SQL. Chắc chắn bạn có thể sử dụng CLR, nhưng tuyến đường này chỉ có vẻ như nó sẽ khó khăn hơn để duy trì và ít lý tưởng hơn là chỉ xử lý dữ liệu như tôi thường làm trong một ứng dụng .NET.
2. Giới hạn trên giao diện người dùng khi thêm điều khiển thông số - nếu tôi nhớ bạn không có nhiều quyền kiểm soát bố cục.

Vì vậy, tôi đoán câu hỏi của mình sẽ ở trong tình huống nào SSRS hoạt động tốt, tình huống nào không hoạt động tốt? Điểm của tôi có hợp lệ hay tôi chỉ là một người hoài nghi?

Answer 1

Bạn có thể thiết lập bảo mật cho dịch vụ Báo cáo giống như trong cửa sổ, vì vậy nếu yêu cầu bảo mật thay đổi, bạn chỉ có thể sửa đổi bảo mật trong RS. Nếu nó được nhúng trong một ứng dụng, bạn phải cập nhật ứng dụng (tôi đã không làm điều này vì vậy tôi không biết tất cả các bước) và sau đó triển khai lại ứng dụng để cập nhật bảo mật.

Answer 2

Điểm của bạn hợp lệ.

Đối với ứng dụng nhỏ hơn, tôi sẽ xem xét sử dụng điều khiển ReportViewer trong ứng dụng ASP.NET nếu bạn không cần tất cả chuông và còi. Ngay cả từ quan điểm bảo trì: bạn chỉ phải quản lý một ứng dụng. Nhóm của tôi đang có kế hoạch ngừng sử dụng SSRS.

Tôi biết một số nhóm chị em của chúng tôi có các báo cáo và cấu trúc phức tạp, và cần chuông và còi.

Answer 3

Tôi sử dụng một chút của cả hai và đã nhận thấy rằng có sự cân bằng với mỗi cách tiếp cận.

• Vì lý do gì, nhà thiết kế cho .rdlc hơi khác một chút so với nhà thiết kế cho .rdl. Nó có thể trở nên khá khó hiểu khi một ví dụ trực tuyến đưa ra các giả định về những gì nhà thiết kế của bạn.
• Tôi thường ủng hộ các báo cáo do SSRS triển khai nếu tôi đang cố gắng trở thành khách hàng bất khả tri, vì các báo cáo dựa trên .rdlc yêu cầu bạn cung cấp cho khách hàng.
• Tôi thường ưu tiên báo cáo dựa trênrdlc cho các ứng dụng độc lập, đặc biệt là cho các khách hàng không có trung tâm dữ liệu. Đây là những ứng dụng mà cả ứng dụng lẫn cơ sở dữ liệu đều nằm trên máy khách.
• Tôi thích LINQ và thấy dễ sử dụng như nguồn dữ liệu cho báo cáo dựa trên .rdlc.
• Tôi có mối quan hệ yêu/ghét với báo cáo dựa trên .rdlc khi nói đến tái cấu trúc. Giữ cấu trúc dữ liệu của bạn trong một thư viện riêng biệt so với các báo cáo của bạn là quan trọng; nếu không, việc thay đổi tên thuộc tính sẽ làm cho bản dựng của bạn thất bại trên tài khoản của báo cáo, nhưng thuộc tính mới sẽ không có sẵn trên nguồn dữ liệu cho báo cáo cho đến khi bạn xây dựng.
• Kiểm soát khách hàng (.báo cáo dựa trên rdlc) cung cấp cho bạn tính linh hoạt vô hạn về cách bạn trình bày và thu thập các giá trị tham số, điều này khá hay.

Ở bất kỳ mức nào, tôi nghi ngờ có bất kỳ cách tiếp cận nào theo giáo điều bạn nên dính vào, ngoài "làm điều gì có ý nghĩa". Đối với tôi, trên thực tế, tôi sử dụng các báo cáo dựa trên .rdlc cho các ứng dụng khách nhỏ và triển khai các báo cáo cấp doanh nghiệp cho một máy chủ SSRS.

Chúc may mắn!

Answer 4

Bản năng của bạn tốt, tiếp tục sử dụng chúng.

Nhiều người rơi vào cái bẫy đẩy logic nghiệp vụ phức tạp vào SQL và các công cụ báo cáo. Nơi thích hợp là trong ETL. Đừng bị đe dọa bởi thuật ngữ nó bao gồm các đoạn mã đơn giản đặc biệt cho SSIS phức tạp. Thậm chí sau đó 80% thời gian mọi người sẽ sử dụng SSIS để chỉ trích xuất và tải dữ liệu lưu biến đổi cho báo cáo tại thời gian chạy (Tại sao các báo cáo này quá chậm ?!).

Thậm chí nếu bạn buộc phải cung cấp dữ liệu qua SSRS, hãy giữ lớp chuyển đổi tách biệt khỏi báo cáo bằng công cụ/ngôn ngữ bạn chọn, giữ cho sql của bạn đơn giản và súc tích.

Đối với một cửa hàng nhỏ aspx có lẽ là tốt nhưng hãy ghi nhớ điều này. Bạn nhận được tất cả các công cụ miễn phí từ SSRS với an ninh và xuất khẩu để excel là một cộng lớn cho bạn ông chủ. Báo cáo cũng là một lỗ đen của công việc bận rộn. Các báo cáo đầu tiên của bạn nhanh chóng nhân lên cho những người dùng khác nhau và các lý do kinh doanh khác nhau và trở nên không thể quản lý được. Nếu bạn thiết lập một cơ sở tốt SSRS, bạn có thể di chuyển công việc cho người khác khi thời gian là đúng.

Nếu bạn quan tâm hơn, tôi khuyên bạn nên đọc kho lưu trữ dữ liệu.

Một điều nữa. Lưu ý chạy báo cáo dựa trên dữ liệu trực tiếp. Báo cáo thường có hồ sơ hiệu suất khác với truy vấn OLTP. OLTP = một vài bản ghi thời gian mà các truy vấn Báo cáo (DW) đôi khi yêu cầu quét toàn bộ bảng và có thể gây ra vấn đề về khóa nếu không được thiết lập đúng cách.

Answer 5

Không ai nói gì về Trình tạo báo cáo 2.0 hoặc 3.0. Nó là một ứng dụng tuyệt vời chỉ để xây dựng các báo cáo mà không cần bất kỳ SSRS hoặc bất cứ điều gì. Chỉ cần kích hoạt nó và thiết lập nó để tiêu thụ bất kỳ nguồn dữ liệu nào bạn có sẵn và bạn tốt để đi. Ý tôi là, bạn có thể dễ dàng biên dịch báo cáo này một cách nhanh chóng. Hãy suy nghĩ về nó.

Bạn chắc chắn không cần một giải pháp .NET được tùy chỉnh riêng cho việc này.

Getting Started with Report Builder 3.0