Sql Server Reporting Services против отчетов через приложение .NET

Question

Мой начальник хочет, чтобы я создал несколько отчетов в ближайшем будущем, и я думаю, что он хочет использовать службы отчетов SQL Server для развертывания отчетов. Я не уверен, что это будет отличной идеей, учитывая, что мы довольно маленькая организация, и я не вижу, чтобы мы эффективно использовали или нуждались в функциях, предлагаемых этим решением, таких как настройка пользователей, групп и подписок.

Хотя я раньше не использовал SSRS, я смотрел трехдневный вебинар по нему, и похоже, что это одна из тех вещей, которые хороши и подходят для простых ситуаций, но становятся болезненными и слишком ограниченными, когда требования более сложный. Я бы очень развернул отчеты в виде локальных отчетов (.rdlc) в приложении .net, потому что:

1. Я бы предпочел обрабатывать и форматировать данные с использованием .NET, а не SQL. Конечно, вы можете использовать CLR, но кажется, что этот маршрут будет сложнее поддерживать и он менее идеален, чем просто обработка данных, как обычно в приложении .NET.
2. Ограничения для пользовательского интерфейса при добавлении элементов управления параметрами - если я помню, у вас нет большого контроля над макетом.

Так что я думаю, что мой вопрос будет в том, в каких ситуациях SSRS работает хорошо, в каких ситуациях он не работает хорошо? Мои очки верны или я просто скептик?

Answer 1

Я использую немного того и другого и обнаружил, что с каждым подходом есть компромиссы.

• По какой-то причине конструктор для .rdlc немного отличается от конструктора для.RDL.Это может привести к путанице, когда пример в сети делает предположения о том, кто является вашим дизайнером.
• Я обычно предпочитаю отчеты, развернутые в SSRS, если я пытаюсь быть независимым от клиента, так как отчеты на основе .rdlc требуют от васпредоставить клиенту.
• Я обычно предпочитаю отчеты на основе .rdlc для автономных приложений, особенно для клиентов, у которых нет центра обработки данных.Как правило, это приложения, где и приложение, и база данных находятся на клиентском компьютере.
• Мне нравится LINQ, и мне проще использовать его в качестве источника данных для отчетов на основе .rdlc.
• У меня есть отношения любовь / ненависть с отчетами на основе .rdlc, когда дело доходит до рефакторинга.Важно хранить ваши структуры данных в отдельной библиотеке, чем ваши отчеты;в противном случае изменение имени свойства приведет к сбою сборки из-за отчета, но новое свойство не будет доступно в источнике данных для отчета, пока вы не создадите.
• Управление клиентом (.rdlcотчет на основе) дает вам безграничную гибкость при представлении и сборе значений параметров, что очень приятно.

В любом случае, я сомневаюсь, что есть какой-то догматический подход, который вы должны придерживаться, кроме «делай то, что имеет смысл».На практике я использую отчеты на основе .rdlc для небольших клиентских приложений и развертываю отчеты корпоративного уровня на сервере SSRS.

Удачи!

Answer 2

Никто ничего не сказал о построителе отчетов 2.0 или 3.0.Это отличное приложение для создания отчетов без необходимости использования SSRS или чего-либо еще.Просто запустите его и настройте на использование любого источника данных, который у вас есть, и все готово.Я имею в виду, вы можете легко составить этот отчет в кратчайшие сроки.Думаю об этом.

Для этого вам определенно не нужно другое специальное решение .NET.

Начало работы с построителем отчетов 3.0

Answer 3

Ваши инстинкты хороши, продолжайте использовать их.

Многие люди попадают в ловушку внедрения сложной бизнес-логики в инструменты SQL и создания отчетов. Правильное место в ETL. Не пугайтесь того, что термин охватывает простые специальные perl-скрипты для сложных служб SSIS. Даже тогда 80% времени люди будут использовать SSIS только для извлечения и загрузки данных, сохраняя преобразование для отчета во время выполнения (Почему эти отчеты такие медленные ?!).

Даже если вы вынуждены обслуживать данные через SSRS, держите слой преобразования отдельно от отчета на выбранном вами инструменте / языке, сохраняя простоту и краткость в SQL.

Для небольшого магазина aspx, вероятно, хорошо, но имейте это в виду. Вы получаете множество бесплатных вещей от SSRS с безопасностью и экспортом, чтобы стать отличным плюсом для вашего босса. Отчеты - это тоже черная дыра занятой работы. Ваша первая горстка отчетов быстро размножается для разных пользователей и разных бизнес-причин и становится неуправляемой. Если вы настроили хорошую базу SSRS, вы можете перенести работу на другого человека, когда придет время.

Если вам больше интересно, я предлагаю прочитать хранилище данных.

Еще одна вещь. Будьте в курсе запуска отчетов против реальных данных. Отчеты обычно имеют профиль производительности, отличный от запросов OLTP. OLTP = несколько записей времени, когда запросы отчетов (DW) иногда требуют полного сканирования таблиц и могут вызвать проблему блокировки, если не настроены должным образом.

Answer 4

Вы можете настроить безопасность для служб отчетов точно так же, как в Windows, поэтому, если требование безопасности изменится, вы можете просто изменить безопасность в RS.Если оно встроено в приложение, вам придется обновить приложение (я не сделал этого, поэтому я не знаю всех шагов), а затем повторно развернуть приложение для обновления безопасности.

Answer 5

Ваши баллы действительны.

Для небольшого приложения я хотел бы рассмотреть возможность использования элемента управления ReportViewer в приложении ASP.NET, если вам не нужны все навороты.Даже с точки зрения обслуживания: вам нужно управлять только одним приложением.Моя команда планирует прекратить использование SSRS.

Я знаю, что у некоторых из наших сестринских команд есть сложные отчеты и структуры, и им нужны навороты.