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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Отличный вопрос, кстати.

Answer 5

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

Answer 6

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

Answer 7

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

Так я бы порекомендовал - я сделал это, чтобы получить доступ к данным списка SharePoint через их веб-сервисы. Если схема данных может быть исправлена, TVF SQL CLR может хорошо подойти и обеспечить наибольшую гибкость. Если вам нужно определить схему во время выполнения, вам нужна хранимая процедура 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 и http://www.codeproject.com/KB/database/SQLCLR.aspx?display=Print

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

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