Как получить данные из таблицы в SQL Server Reporting Services?

Учитывая: механизм вычисления С#, который загружает объектную модель, сжимает огромное количество чисел и сохраняет результаты в пару гигантских мегаиндексированных таблиц базы данных в SQL Server. Эти таблицы предоставляют данные для веб-интерфейсов, других программных модулей и отчетов SQL Server Reporting Services 2005.

Мне удалось сделать двигатель намного быстрее в последней версии программного обеспечения, достаточно быстро, чтобы он мог предоставлять данные по запросу - иногда даже быстрее, чем время, необходимое для запроса базы данных для предварительно рассчитанных чисел, Я очень доволен этим.

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

Кэш-таблицы - это боль, во многом так же, как любой кеш - это боль в мире программного обеспечения. Не вдаваясь в подробности, у них есть проблемы с синхронизацией, проблемы с блокировкой и т.д. И т.д. Программное обеспечение будет работать гораздо лучше, если мне не придется беспокоиться о том, чтобы обновлять эти проклятые таблицы.

Но как еще я могу получить данные в SSRS? Я провел несколько исследований и ничего не выглядел многообещающе:

  • Мы можем предоставить данные через веб-службу и использовать SSRS XML DPE. Но это выглядит отвратительно - я прав, что вам нужно самостоятельно разобрать свой SOAP-конверт?! И он не поддерживает XPath, а проприетарный диалект XPath-y? Наши авторы отчетов знают T-SQL и что они лучше всего.
  • Использование SQL CLR для размещения нашего API нежелательно - это большое приложение, и вы ничего не можете сделать без создания объекта приложения и входа в систему и т.д.
  • Использование SQL CLR для связи с веб-службой в веб-приложении - это наиболее перспективно до сих пор (эта статья была полезной http://www.simple-talk.com/sql/sql-server-2005/practical-sql-server-2005-clr-assemblies/.) Кто-нибудь пробовал этот подход? Он работает нормально, может ли он предоставлять большие наборы данных? OTOH Я отключен дополнительной настройкой, которую нам нужно будет делать на клиентских серверах БД.
  • Приветствуются любые другие предложения.

Ответ 1

Если я правильно вас понимаю, вы создаете отчет о данных, отличных от SQL. Вы храните данные в таблицах с конкретной целью сделать их отчетными.

Я могу думать о двух решениях. Первый заключается в расширении вашего механизма вычисления С# с помощью части отчета. Пространства имен Microsoft.Reporting.WinForms и Microsoft.Reporting.WebForms могут использоваться для создания отчетов по любому источнику данных, а не только по SQL Server. Если конечные пользователи используют ваше приложение в качестве клиента, вы можете генерировать данные и отчеты на лету.

Вторым является использование SQL CLR. Вы можете использовать хранимую процедуру CLR в качестве основы для отчета (введите "exec mysp" в качестве источника данных.) Эта процедура CLR является кодом С# и может включать в себя ваш механизм вычислений в виде библиотеки. Это позволит вам генерировать отчеты "на лету", все еще используя пользовательский интерфейс сервера отчетов.

Интересный вопрос, и я надеюсь, что более знающие люди могут дать лучший ответ:)

Ответ 2

Ранее я был в аналогичной ситуации и пытался использовать как источник данных SSRS XML, так и расширение отчетности, которое упоминает Andomar. Моя рекомендация - использовать функцию источника данных SSRS XML. Если структура данных, возвращаемая веб-службой, проста, XPath также прост. Мне также стало легче отлаживать. Главное, на что нужно следить, - это тайм-ауты.

Хорошая вещь с использованием веб-сервисов заключается в том, что они легко потребляются многими различными технологиями, поэтому они могут стать очень удобными в любом случае.

Кроме того, это личный выбор, но, несмотря на возможности SQL CLR, мне все еще не очень удобно размещать код в базе данных. Используя источник данных XML в SSRS, нет необходимости включать пользовательский код CLR вообще.

Ответ 3

Вы можете обернуть свои данные в ADO.NET DataSet и использовать его как источник данных служб Reporting Services.

Я никогда лично не использовал это, поэтому я не могу дать вам больше информации. Тем не менее, я знал, что вы можете сделать это из класса SSRS, в котором я учился. Пример, который преподаватель дал мне, когда вы сделаете это в примере "реального мира", будет, если вам нужно объединить данные из двух разных источников данных. Например, вы сделали бы это, если бы вы хотели сопоставить данные из SQL Server и Oracle вместе в одном отчете.

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

Ответ 4

Считаете ли вы, что вы пишете свой собственный драйвер базы данных, который находится поверх вашего вычислительного механизма? Затем вы можете указать службы отчетности прямо на него. Это будет держать вещи быстро, хотя это может быть сложной задачей. Я уже рассматривал это в прошлом для запатентованного программного обеспечения хранилища данных, над которым я работал, но так и не получил, чтобы построить драйвер.

Великий вопрос кстати.

Ответ 5

Использование SQL CLR для связи с веб-сайтом службы в веб-приложении

Так я бы рекомендовал - я сделал это, чтобы получить доступ к данным списка SharePoint через их веб-службы. Если схема данных может быть исправлена, SQL CLR TVF может быть хорошо подходит и обеспечивает максимальную гибкость. Если вам нужно определить схему во время выполнения, то хранимая процедура SQL CLR - это то, что вы хотите, поскольку оно не привязано к схеме.

Ключевыми вещами, которые вам понадобятся, является:

-- 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

затем создайте проект VS sql clr (вам не обязательно, но он помогает при развертывании и отладке), установите уровень разрешений на "внешний". Если вы используете "Добавить веб-ссылку" в проекте VS, вам нужно будет включить генерацию сборки сериализации и CREATE ASSEMBLY, чтобы загрузить ее после сборки/развертывания.

Теперь это немного волнистая рука - честно, я сделал это - я добавлю еще несколько деталей позже. В прошлом месяце я рассказал о SQL CLR. В моем примере кода есть проект GetFibs, который вызывает также веб-службу (Fibonnaci).

Также смотрите здесь: http://footheory.com/blogs/bennie/archive/2006/12/07/invoking-a-web-service-from-a-sqlclr-stored-procedure.aspx и < а2 >

Выполняется ли это нормально, может ли он обеспечить большие наборы данных?

Да, кажется, он работает хорошо. С небольшой дополнительной работой вы можете построить ее более ориентированной на поток, где она не будет потреблять память для всего набора. См. Пример в примере диапазона или здесь.

Ответ 6

Я бы окончательно спустился по дороге ADO.NET DPE. Если ваш источник данных может предоставить необходимые данные в реальном времени, тогда это будет иметь смысл. Вы сэкономите 1,2 или 3 уровня, что, несомненно, улучшит общую производительность. И не говорить о поддержании каждого уровня кода. Покажите количество данных с хрустальными данными как набор данных ADO.NET и позвольте вашим службам отчетов напрямую запрашивать его. Это наилучшее, на мой взгляд.

Ответ 7

В SQL 2008 вы можете использовать пакет SSIS SQL в качестве источника данных. Напишите пакет SSIS для выполнения вашего вычислительного механизма "на лету" и вывода массива данных .net(DataReaderDestination). Затем это можно использовать для отчетов.