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

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

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

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

Итак, я думаю, мой вопрос будет в каких ситуациях работает SSRS, какие ситуации не работают? Являются ли мои баллы действительными или я просто скептик?

Ответ 1

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

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

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

Удачи!

Ответ 2

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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