Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Приветствую всех.

Есть хранимка, в котором вызывается метод класса, обращение к веб-сервису.
Веб-сервис написан другими разработчиками, и на их стороне поменять невозможно. Данный веб-сервис, на некоторые запросы возвращает некорректный header, из-за чего .NET'овский WebRequest отваливается из-за ошибки в заголовке:
error
The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF


в консольном приложении, или в Win Forms приложении игнорирование ошибки в заголовке можно настроить через app.config
useUnsafeHeaderParsing
или эту же настройку изменить путем вызова настроек приложения в коде, и все работает.

А в .NET CLR хранимке невозможно добавить app.config, по крайней мере я не нашел как это сделать.
Как и настроить программным способ эту опцию, так как выходит ошибка при обращении к элементу
System.Net.Configuration.SettingsSectionInternal.get_Section()

что можете посоветовать?
В данный момент рассматриваю вариант выноса работы с веб-сервисами в отдельный проект подключаемой библиотеки (dll)
которую и потом можно будет вызывать из .NET CLR хранимки.

Спасибо за внимание.
20 мар 12, 00:36    [12278254]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Если кому интересно,

решил пока что следующим образом, вынес работу с данным сервисом в отдельный class library, в котором прописал настройки игнорирования ошибки в заголовке HTTP пакет

и подключил данный class library в SQL Server через CREATE ASSEMBLY
Затем добавил ссылку на эту библиотеку в .NET CLR хранимке и все заработало
Короче, извиняюсь за выражение, "через *опу".
Было бы хорошо если такие настройки сразу были добавлены в HttpRequest в .NET

Если у кого будет получше решение, поделитесь, пожалуйста
20 мар 12, 09:56    [12279136]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Для работы с SOAP хватает и без .Net работать.
5933931
20 мар 12, 17:11    [12282947]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
orunbek
Если кому интересно,

решил пока что следующим образом, вынес работу с данным сервисом в отдельный class library, в котором прописал настройки игнорирования ошибки в заголовке HTTP пакет

и подключил данный class library в SQL Server через CREATE ASSEMBLY
Затем добавил ссылку на эту библиотеку в .NET CLR хранимке и все заработало
Короче, извиняюсь за выражение, "через *опу".
Было бы хорошо если такие настройки сразу были добавлены в HttpRequest в .NET

Если у кого будет получше решение, поделитесь, пожалуйста


вы можете хранить настройки в базе, к ним будет просто добраться из SQLCLR
20 мар 12, 17:25    [12283070]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior,

там не совсем SOAP

Winnipuh,
настройки игнорирования ошибок в http

http://msdn.microsoft.com/ru-ru/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing.aspx
20 мар 12, 21:05    [12284170]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek, согласен вам не по зубам отредактировать эту простую процедуру под вам нужный протокол.
Кстати, под WebService обычно и подразумевают SOAP. Иначе говорят WCF али ещё как. IMXO

orunbek
А в .NET CLR хранимке невозможно добавить app.config, по крайней мере я не нашел как это сделать.
Как и настроить программным способ эту опцию, так как выходит ошибка при обращении к элементу
Считает что нет и не нужно. Если нужно, значит вы что-то делаете не так.
Хотя на самом деле пишут что оно есть и работает, если конфигурировать файл в директории самого скуля. Но мол настройки подымутся раз или надо перегружать сервак. Короче правильно пишут что типа нельзя.

Зачем вам настройки, вы разве не можете (не знаете как) сразу в коде прописать явно?

На счёт подхода, считаю (и не я один) что делать из скуля (базы) панацею - зло. Точнее у вас по топикам явно прослеживается мешанина, всё загнать в кучу, которую потом никто не разберёт, а вы потом сами забьёте проект. Всегда всё разделяйте. "*nix way" - это не просто красивые слова.
Каждая вещь в современном программировании вопит об этом.

Почему мне ещё не нравиться компилируемый код (CLR) для случая с WebService? Да потому что надо мудохаться каждый раз чтоб добавить или изменить вызов. Скриптовый язык удобнее. Можно за 3 сек. вызвать что угодно.

Ранее уже писал о возможном варианте: ServiceBroker как средство коммуникации с .Net (нативным) сервисом...
21 мар 12, 02:54    [12285238]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
orunbek,

Пишите линейно.
Поможет.
21 мар 12, 07:12    [12285344]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior
orunbek, согласен вам не по зубам отредактировать эту простую процедуру под вам нужный протокол.
Кстати, под WebService обычно и подразумевают SOAP. Иначе говорят WCF али ещё как. IMXO

orunbek
А в .NET CLR хранимке невозможно добавить app.config, по крайней мере я не нашел как это сделать.
Как и настроить программным способ эту опцию, так как выходит ошибка при обращении к элементу
Считает что нет и не нужно. Если нужно, значит вы что-то делаете не так.
Хотя на самом деле пишут что оно есть и работает, если конфигурировать файл в директории самого скуля. Но мол настройки подымутся раз или надо перегружать сервак. Короче правильно пишут что типа нельзя.

Зачем вам настройки, вы разве не можете (не знаете как) сразу в коде прописать явно?
....
....

уже приводил ссылку на эту настройку
http://msdn.microsoft.com/ru-ru/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing.aspx
покажите пример настройки из кода CLR-проекта, доступ к данной настройке из CLR-хранимки не нашел, по крайней мере в рамках стандарных MS'овских библиотек.
Может быть есть сторонние библиотеки работы с http-протоколом, с возможностью более гибкой настройки парсинга ответов, не знаю.

Mnior
...
...
На счёт подхода, считаю (и не я один) что делать из скуля (базы) панацею - зло. Точнее у вас по топикам явно прослеживается мешанина, всё загнать в кучу, которую потом никто не разберёт, а вы потом сами забьёте проект. Всегда всё разделяйте. "*nix way" - это не просто красивые слова.
Каждая вещь в современном программировании вопит об этом.

Почему мне ещё не нравиться компилируемый код (CLR) для случая с WebService? Да потому что надо мудохаться каждый раз чтоб добавить или изменить вызов. Скриптовый язык удобнее. Можно за 3 сек. вызвать что угодно.

Ранее уже писал о возможном варианте: ServiceBroker как средство коммуникации с .Net (нативным) сервисом...

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

По данной теме (проблеме), .NET CLR хранимка нужна для следующей задачи
из web-клиента вызывается метод Web-сервиса (ASMX), который регистрирует запрос в базе, затем ответ для данного запроса формируется на основе работы с чужим "web-сервисом".

Поэтому используется связка (приложенный файл).

Требования на данный момент, при поступлении запроса, обязательно нужна регистрация запроса, чтобы "не потерять запросы клиентов" и ответ возвращается тем же методом Web-сервиса (ASMX).
Если предложите более конструктивный метод в рамках .NET + IIS + MSSQL, восприму на ура, предложенный способ решения данной задачи.

К сообщению приложен файл. Размер - 16Kb
21 мар 12, 07:12    [12285345]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
orunbek,

практически любой "чужой" web-сервис можно зарегить в MSSQL как "другой сервер", и залить в него информацию.
Ну, я имею в виду, что любой удалённый WEB работает с какой-то СУБД.

MySQL, или PostgreSql.
Интерфейсы - ЕСТЬ ИХ!

заливай - не хочу!
21 мар 12, 07:19    [12285355]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Makar4ik
orunbek,

практически любой "чужой" web-сервис можно зарегить в MSSQL как "другой сервер", и залить в него информацию.
Ну, я имею в виду, что любой удалённый WEB работает с какой-то СУБД.

MySQL, или PostgreSql.
Интерфейсы - ЕСТЬ ИХ!

заливай - не хочу!


забыл добавить, чужих "web-сервисов" может быть несколько, на данный момент 2
и работа с каждым из них отличается, у каждого из них свой протокол взаимодействия.
Ответы возвращаются в xml-виде, но достаточно сложно в виде.
Не просто
<?xml...>
<response>
...
</response>
и т.д., а многоуровневая вложенность, для одного типа запроса один формат, для второго запроса тоже по другому.
При этом нужно проверять различные параметры, в ответе.
Грубо говоря, нужно из разрозненных источников, обрабатывать информацию и возвращать в унифицированном виде.
И таких источников может быть неограниченное количество (на данный момент их у меня 2), поэтому использую внешний .NET CLR SP, который вызывает для каждого источника заранее заготовленный метод из Class Library, который и возвращает в унифицированном виде информацию.
При этом есть риски, того, что нет гарантии что эти чужие веб-сервисы буду возвращать ответы или работать адекватно.
Вот уже с первым возникла проблема, в том что объев возвращаемой информации не соответствует Content-length'у в заголовке, из-за чего и вылетает стандартный парсинг, и возникла необходимость включать опцию игнорирования ошибок в http-заголовке.
21 мар 12, 07:32    [12285369]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
orunbek,

ну, это уже логика программы.
генерировать ХМЛ-и из MSSQL на порядок проще, чем разбирать их средствами tSQL.
Кстати, генерить, я их в своё время предпочитал именно на стороне сервера.
А вот разбирать проще демоном, или каким-то ещё клиентом.

..в любом случае, разрозненные источники - подразумевают разрозненные каналы. И разные форматы ХМЛ. И разные парсеры.
Ну, и так далее... Понятно, да?
Слона-едят-по-частям.
И не нужно всего слона пытаться проглотить целиком. Чревато.
21 мар 12, 07:41    [12285376]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Makar4ik
orunbek,

ну, это уже логика программы.
генерировать ХМЛ-и из MSSQL на порядок проще, чем разбирать их средствами tSQL.
Кстати, генерить, я их в своё время предпочитал именно на стороне сервера.
А вот разбирать проще демоном, или каким-то ещё клиентом.

..в любом случае, разрозненные источники - подразумевают разрозненные каналы. И разные форматы ХМЛ. И разные парсеры.
Ну, и так далее... Понятно, да?
Слона-едят-по-частям.
И не нужно всего слона пытаться проглотить целиком. Чревато.


ёклмн, вот именно я это и делаю
для разных каналов, разные парсеры, реализованные в виде .NET Class Library, подключенный к SQL-серверу
и используемый в .NET CLR хранимке, прочитайте тему с начала, а не с последнего сообщения
21 мар 12, 07:50    [12285383]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
orunbek,

дотнет я НИФИГА не знаю.
Я знаю только как разрабатывать проекты.

Но не под дотнет ))))

основное правило - перемещать максимум на сторону сервера, пока это не мешает функциональности.

Если для функциональности надо сделать клиентов на 20% круче, то лучше выбрать укручение сервера на 200%.
Один сервер, и 10-30-70 клиенов.

У меня были проекты... Просили подтирать какашки за предыдущими разработчиками.
Клиент кушал 2 гига памяти. На ВСЕХ компах. Своп не переставал работать.
И ведь первый разраб с самого начала - думал о лучшем...
...А вышло как всегда.
21 мар 12, 08:01    [12285389]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Makar4ik,

вот именно вынос на сторону сервера
клиенты, это web-клиенты сайта, на стороне которых только вызов методом Web-сервиса посредством ajax, посмотрите схему
а по теме, нюансы работы .NET CLR Хранимки под MS SQL было, а именно настройка игнора ошибки в HTTP-пакетов в .NET CLR хранимке
21 мар 12, 08:26    [12285421]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek
... Схема ...
Схема думаю знакома многим.
Единственное что вместо .Net CLR SP стоит отдельный сервис.

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

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

Банально, в данном вопросе стоит задача активного элемента. Сами понимаете что клиент только источник запроса, но не контроллер.
Ставить скуль, как активного контроллера? Не знаю, пока мало огрёб проблем, чтобы полноценно аргументировать. Но многое настораживает.
---------------------
По порядку.

В одно время было что логика взаимодействия с внешней системой была на скуле и сильно завязана. В итоге чёрт ногу сломит, поэтому унифицировал и вынес нафиг. Стало намного легче. Скуль вообще не знает ничего внешнего. Кроме как о порядке взаимодействия (обыкновенные парадигмы контроля и связи) в стандартных интерфейсах близких по духу скулю.

Про "активный элемент", возможно слишком сильно зависит от задачи. И в каждом случае разная стратегия для случая сбоя конкретного/каждого блока системы.

Мне кажется найдутся люди, которые покроют толстым слоем говна данную схему (Почему? Религия?). И будут настаивать на классическом методе, что сам WebService и должен обращаться к внешней системе. Мол Аппликейшин сервер центральное звено, а база это только база.

Но это уже в форум разработка.

В одном случае мне видеться один вариант, в другом другой. Хотя я тоже любитель на скуле логику разворачивать, но я часто вижу крайности. Некоторые (б%$ть, большинство) банально не видят где грань между логикой предметной, интерфейсной, скульной, аппликативной, клиентской и т.п.

Само по себе взаимодействие с внешней системой не имеет ничего общего со скулем совершенно. Более того бывает партнёр (внешняя система) закрутит в таких невъе&$енных понятих, не то что данные, само взаимодействие, что выравнивание этого г**на занимает дофига кода. И лучше это далать нативно (.Net и т.п.) и отдельно.

Но есть случаи когда на многое можно закрыть глаза. Например когда система сверх-малая и сверх-специализированная. Тогда в принципе можно экономить на количестве элементов - упрощая жизнь заказчику. Некоторые поэтому даже воют, что HTTP из скуля вырезали.
22 мар 12, 02:14    [12292479]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior,

ну здесь вариант переноса вызова внешних веб-сервисов в SQL, был выбран не только тем, что все решение будет на стороне сервера, но и из-а Service Broker'а. Расскажу об этом подробнее.

Вот вы сами участвовали в моем предыдущем топике, по поводу переноса некоторого функционала в T-SQL процедуру.
Данный топик, и вышеуказанный топик не по одному и тому же проекту. Но есть схожие места.

В проекте, часть проблемы из которой освещена в предыдущем топике, раньше и была использована схема внешнего приложения, т.е. SQL "отвечает" только за данные, а обработка запросов была вынесена во внешнее приложения.
Запросы на обработку могли поступать из различных источников: web-клиент, мобильный клиент, SMS-запросы, win32-клиент. При поступлении запроса, в зависимости от вида запроса, обрабатывается в различных веб-сервисах, в некоторых случаях "нормальный" веб-сервис, взаимодействие с которым строго описано в документации, а другие просто сайт, не расчитанный на автоматизацию.
При поступлении запроса он добавлялся в базу со статусом "не обработан" (TblQueries.Status = 0), внешние приложения периодически проверяют базу на наличие не обработанных запросов (UPDATE TblQueries... WHERE Status=0) и при их наличие резервируют эту обработку для себя, чтобы другие тоже не начали обрабатывать и т.д. И в такой схеме были проблемы с возникновением deadlock'ов и масштабированием (при увеличении запросов, нужно было увеличивать количество обработчиков) и т.д.
В случае Service Broker'а, все обработчики вынес во внешние .NET CLR хранимки, которые активируются при поступлении сообщения в очередь SB. А сообщение передается путем вызова триггера на вставку в таблицу запросов, т.е. при поступлении запроса автоматически вызывается обработчик, т.е. не нужно решать проблему конфликтов резервирования, и увеличение количества обработчиков решается путем настройки очереди (увеличиваю MAX_QUEUE_READERS), и многие проблемы организации очереди берет на себя Service Broker.
Понимаю, может быть можно было и другими способами, решить эту проблему. Скажем написать подобное Service Broker'у, во внешнем приложении.
Но я решил попробовать для решения проблемы в этом проекте Service Broker, и результат прекрасный, по крайней мере в моем случае, он прекрасно справляется с поставленной задачей.

Согласен что может быть "масштабы проблемы не те", и узкопрофильность проекта, поэтому и вариант выноса многих решений в сторону SQL не создают проблемы.
В любом случае спасибо за участие в дискуссии, тем более в таких дискуссиях и рождается, как говорится, истина.
И тем более не малую часть того опыта который я имею сейчас, я получил именно из форума sql.ru.
22 мар 12, 07:32    [12292601]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Кстати, забыл добавить, кто либо использовал Service Broker в достаточно нагруженных системах?
И насколько хорошо он справляется с поставленными задачами, было бы хорошо узнать о цифрах, количество сообщений в очереди, количество самих очередей
22 мар 12, 07:35    [12292603]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek, вы немного не видите основной разницы.
Вы говорите сделал одно - перенёс на SB.
Но на самом деле вы сделали две вещи:
1. Воспользовались механизмом очереди
2. Перенесли обработку сообщений на скуль

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

Если вы хотите управлять количеством процессов согласно мезанизму скуля (MAX_QUEUE_READERS), то вы можете подписать ваше приложение на WMI Event-ы, и по их появлению создавать дополнительные потоки/процессы. Или активировать через Job к примеру. Тысячи их.
Вот тоже самое только в BOL-е.

SB не заставляет делать всё на скуле. Это просто одно из вариантов. Т.к. просто бывают обработчки серверной логики, а не как у вас клиентсокой/внешней.

Воэтому я повторюсь, для правильных решений вы обязаны знать инструменты досконально. Читайте BOL.
22 мар 12, 12:52    [12294351]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior,

ок, спасибо за инфу
попробую реализовать обработку сообщений на внешнем приложении, без SQL сервера
и оценить эффективность
22 мар 12, 16:39    [12296644]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek
попробую реализовать обработку сообщений на внешнем приложении, без SQL сервера
и оценить эффективность
Адекватность редкая штука.
Хотя изначально было видно.


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

КО.
22 мар 12, 22:36    [12298641]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior
orunbek
попробую реализовать обработку сообщений на внешнем приложении, без SQL сервера
и оценить эффективность
Адекватность редкая штука.
Хотя изначально было видно.
...
...


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

вот меня меня интересует другой момент .NET CLR хранимок, насколько отличается скорость доступа к объектам базы данных
хранимки .NET CLR и внешнего .NET приложения?
Только тем, что в хранимке объект Connection быстрее подключиться? или и скоростью выполнения запросов и т.д.?
23 мар 12, 06:46    [12299367]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31983
orunbek
вот меня меня интересует другой момент .NET CLR хранимок, насколько отличается скорость доступа к объектам базы данных
хранимки .NET CLR и внешнего .NET приложения?
Только тем, что в хранимке объект Connection быстрее подключиться? или и скоростью выполнения запросов и т.д.?
Запросам всё равно, они же на сервере выполняются.

Внутри будет быстрее соединение и получение результата, как минимум из за ненужности передачи данных между процессами.
23 мар 12, 09:13    [12299603]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
alexeyvg,

спасибо за подсказку
23 мар 12, 15:00    [12302495]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek
вот меня меня интересует другой момент .NET CLR хранимок, насколько отличается скорость доступа к объектам базы данных
хранимки .NET CLR и внешнего .NET приложения?
Только тем, что в хранимке объект Connection быстрее подключиться? или и скоростью выполнения запросов и т.д.?
Вопрос чуть странный. Внешний обработчик не должен иметь представления об логике на скуле. Он должен махом получить все данные одним запросом (к примеру xml от скуля прямиком сериализовать в объект на .Net) а далее переформатировать в запрос к внешней системе. Поэтому особой разницы нет, т.к. поток данных простой и однонаправленный, т.е. если закрыть глаза на мелочи это сравнимо с дополнительным рутером в сети.

Не должно быть такого, чтоб обработчик делал дополнительные запросы к скулю, это нарушает принцип "разделения". О которых я слишком много талдычу.

Банальный вызов процедуры по кругу spPutResultAndGetNextMessage, пока не закончится очередь.

Тут возникают проблемы другого рода - это контроль выполнения. Банально выпадения ловить и обрабатывать становится по другому. И не надо забывать уделить этому пристальное внимание.
25 мар 12, 13:32    [12309696]     Ответить | Цитировать Сообщить модератору
 Re: Возможность добавления app.config в .NET CLR хранимку?  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Mnior
orunbek
вот меня меня интересует другой момент .NET CLR хранимок, насколько отличается скорость доступа к объектам базы данных
хранимки .NET CLR и внешнего .NET приложения?
Только тем, что в хранимке объект Connection быстрее подключиться? или и скоростью выполнения запросов и т.д.?
Вопрос чуть странный. Внешний обработчик не должен иметь представления об логике на скуле. Он должен махом получить все данные одним запросом (к примеру xml от скуля прямиком сериализовать в объект на .Net) а далее переформатировать в запрос к внешней системе. Поэтому особой разницы нет, т.к. поток данных простой и однонаправленный, т.е. если закрыть глаза на мелочи это сравнимо с дополнительным рутером в сети.

Не должно быть такого, чтоб обработчик делал дополнительные запросы к скулю, это нарушает принцип "разделения". О которых я слишком много талдычу.

Банальный вызов процедуры по кругу spPutResultAndGetNextMessage, пока не закончится очередь.

Тут возникают проблемы другого рода - это контроль выполнения. Банально выпадения ловить и обрабатывать становится по другому. И не надо забывать уделить этому пристальное внимание.


данный нюанс, т.е. скорость доступа к объектам из .NET CLR хранимки, актуален для меня тем что
по логике приложения, и в зависимости от исходных данных вызываются различные хранимки, их не так много в принципе
и... если время выполнения этой хранимки не должна превышать 2х секунд, поэтому и скорость доступа к объектам очень критична
и дело не в алогоритме обработки данных, а именно выполнение и доступ к объектам БД
27 мар 12, 10:47    [12318715]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить