Какие соображения связаны с интеграцией SQL/CLR, когда база данных работает и изменения происходят часто?

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

Мой вопрос: если я нажму «управление F5» и позволю VS выполнить волшебное развертывание моих пользовательских функций и т. д. в мою базу данных — что, если есть текущие подключения к этой базе данных с использованием предыдущей версии?

Я надеюсь, что это будет бесшовно.

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

РЕДАКТИРОВАТЬ: я решил указать, для чего я собираюсь использовать это в первую очередь, основываясь на отзывах, которые я в последний раз размещал с этим тегом.

Я не хочу поддерживать логику на двух языках, поэтому я собираюсь преобразовать следующее в C#:

CREATE FUNCTION [dbo].[tousd] 
(@Currency char(3), @Amount money)
RETURNS money
AS
BEGIN
declare @Return money
if(@Currency = 'USD')
    return @Amount * 1.0
else if(@Currency = 'EUR')
    return (@Amount * 1.3065)
else if(@Currency = 'GBP')
    return (@Amount * 1.5552)
else if(@Currency = 'CAD')
    return (@Amount * 0.9789)
else if(@Currency = 'AUD')
    return (@Amount * 0.9613)
else
    return 0.0
return @Return
end

Заранее спасибо, Аарон


person Aaron Anodide    schedule 16.12.2010    source источник
comment
Хм, а не должно ли что-то подобное (где фактические факторы, вероятно, регулярно меняются) вместо этого управлялось таблицей? Я не ожидал увидеть факторы, жестко закодированные в SQL или C#.   -  person Damien_The_Unbeliever    schedule 16.12.2010
comment
Под таблицей вы имеете в виду, что вместо жестко запрограммированных множителей я извлекаю их из таблицы БД? Да определенно. Но сделаете ли вы это совершенно по-другому или у вас будет такая функция, которая выполняет поиск в другой таблице? Я намного лучше пишу код на C#, чем на TSQL, поэтому меня интересует интеграция с SQLCRR.   -  person Aaron Anodide    schedule 16.12.2010
comment
да, я бы ожидал таблицу коэффициентов умножения. Как только я получу эту таблицу, я не уверен, что стал бы возиться с функцией (там так мало возможностей). Быть лучше в написании C#, чем SQL, не является веской причиной для перевода рабочего SQL в C# — это хорошая причина узнать больше о SQL. Как правило, CLR следует использовать в тех областях, где TSQL слаб, например, при работе со строками.   -  person Damien_The_Unbeliever    schedule 16.12.2010
comment
я собираюсь нажать кнопку удаления, так как я узнал больше об этой теме с тех пор, как опубликовал сообщение, и не думаю, что это имеет большое значение   -  person Aaron Anodide    schedule 13.02.2011


Ответы (1)


Не конвертируйте tsql в C# только потому, что он вам удобнее. Базы данных оптимизированы для лучшей работы с SQL, а не с C#. CLR доступны только для того, что SQL не может делать. Если вы можете сделать это в SQl, сделайте это в SQL.

Не делайте больше никакой работы, пока у вас не будет настоящей среды разработки. Возиться с вещами, которые люди на самом деле используют, непрофессионально и опасно для данных и может быстро потерять ваших клиентов.

person HLGEM    schedule 16.12.2010
comment
Это не непрофессионально, если вы делаете все именно так, как говорит вам ваш начальник. PS - я не хочу, чтобы эта тема стала самоуверенной, иначе я не получу ответа :) - person Aaron Anodide; 16.12.2010
comment
@Gabriel: тогда, возможно, вам следует спросить своего босса, каково взаимодействие между магией VS и существующими пользователями. - person Remus Rusanu; 16.12.2010