Должен ли я использовать EF6 из функции SQL CLR

Question

Должен ли я использовать EF6 из функции SQL CLR

1

Мне было поручено изучить некоторый сложный код вычисления (в С#) и переместить его в функцию CLR на SQL Server 2012. Сложный характер вычислений означает, что запись этого как классического SQL SP или UDF не является реально жизнеспособной, следовательно, идея использования CLR - код существует и протестирован.

Проблема заключается в том, что в расчетах используется слой данных, который использует EF6. Очевидно, что я бы извлек как можно меньшую часть существующего кода для функций CLR, но мне все равно придется выполнять все зависимости.

Мой вопрос не в том, как я могу это сделать (это произойдет позже :)), насколько я должен это делать? Как-то нехорошо набивать всю EF в саму базу данных, к которой я собираюсь выполнить вычисления - она очень раздута.

Мнения, предложения, мысли, пожалуйста?

благодаря

Mike 28 окт. 2014, в 04:36

Источник

Теги:

sql-server

c#

.net

entity-framework

sqlclr

1 ответ

Ещё вопросы

Solomon Rutzky · Accepted Answer · 2014-10-28T01-22-00.000Z

1

Лучший ответ

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

Нет. Похоже, что это не так, если это возможно. Вам должно понравиться только несколько точек данных, и их очень легко захватить простым SqlConnection используя Context Connection = true; для соединительной строки (то есть входящего соединения).

И, учитывая, что производительность является проблемой (как и должно быть в любом случае, но все же), следовательно, причина для перехода к этому пути SQLCLR для начала, кажется контрпродуктивным добавить в слои и слои кода, которые позволяют легко - слой абстракции использования, который является платформой Entity Framework.

Кроме того, почему вы извлекаете данные из функции вместо того, чтобы передавать ее в функцию? Имеются ли значения, которые передаются, для чего требуются дополнительные поисковые запросы, основанные на их конкретном значении? Вы получите довольно высокую производительность, структурируя скалярную функцию как детерминированную:

Скалярные функции SQLCLR, отмеченные как IsDeterministic = true в SqlFunction имеют свой вывод, кэшированные и сопоставленные с входными параметрами, поэтому их можно искать (в контексте дополнительных строк в одном запросе) и повторно использовать вместо запуска функции снова и
Скалярные функции SQLCLR, помеченные как IsDeterministic = true, AND not marked DataAccess = DataAccessKind.Read, в SqlFunction в параллельных планах. Если либо IsDeterministic не помечен как true либо DataAccess (или даже SystemDataAccess) отмечены как Read, то они будут действовать как обычные функции T-SQL, поскольку они предотвратят любой запрос, который использует их для получения параллельного плана выполнения.

Solomon Rutzky 28 окт. 2014, в 01:22

0

Необходимо, чтобы функциональность вычислений была доступна как из служб SQL (другие SP, службы отчетов, другие системы, которые в настоящее время не были переработаны), так и из традиционных внешних систем. Отсюда необходимость инкапсулировать код только в одном месте, доступном для обеих сред. Код очень сложный, с использованием нескольких поисков и передачи данных - финансового характера. Попытка конвертировать C # в SQL была бы кошмаром, помимо этого у нас есть работающий механизм.
Mike 28 окт. 2014, в 04:03
0

@ Майк: Эй. Я бы сказал, что это важная информация, которая должна быть в вопросе :-). Кроме того, что вы имеете в виду «инкапсулировать код только в одном месте, доступном для обеих сред»? Код SQLCLR размещен на SQL Server и не может быть доступен извне, а также не имеет доступа к чему-то удаленному (хотя он может получить доступ к компоненту COM, зарегистрированному в той же системе). Если расчет выполняется быстрее всего в базе данных, тогда, возможно, центральным местом должна быть функция SQLCLR ;-).
Solomon Rutzky 28 окт. 2014, в 04:13
0

@ Майк, я не видел твоего обновления к твоему комментарию, когда ответил. Как вы собираетесь использовать эту функцию SQLCLR? В предложении SELECT или WHERE (т. Е. Где он будет выполняться для каждой строки набора данных для нескольких строк)? Или как часть большего пакета операторов SQL, который выполняется один раз для этого пакета? Я не говорил, что было бы бесполезно, если бы ему приходилось делать доступ к данным, просто есть большие преимущества, если не делать этого. Но если это невозможно, то ладно. И в целом я согласен с выполнением сложных вещей через SQLCLR (отсюда и SQLsharp.com ;-), просто пытаюсь помочь вам достичь наилучшего результата :).
Solomon Rutzky 28 окт. 2014, в 04:55
0

Я ценю ваши комментарии приятель, не беспокойтесь. Идея состоит в том, что было бы неплохо иметь по существу одну dll (игнорируя проблему зависимости), которая содержит вычисление, которое может быть вызвано напрямую из компонента .net, но которое мы также можем встроить в функцию CLR, чтобы позволить его вызывать изнутри SQL Server - в основном мы хотим поддерживать только одну кодовую базу для него. Я немного упростил сценарий для (я думал) ясности, на самом деле это набор функций, некоторые из которых возвращают отдельные значения, а другие возвращают наборы данных.
Mike 28 окт. 2014, в 05:36
0

@ Майк, я не думаю, что это сработает. SQLCLR - это очень ограниченная среда CLR-хоста. На самом деле у меня возникает желание создать единую кодовую базу, но я здесь реалистичен. Учитывая, что SqlTypes немного отличаются от обычных типов .Net, вам, по крайней мере, понадобятся методы-оболочки для SQLCLR, которые вызывают ваши существующие общие методы. Но в зависимости от того, что они делают, это может потребовать изменений в этой общей кодовой базе. Вы не можете использовать статические переменные уровня класса. И вам может понадобиться импортировать все EF DLL в SQL Server. Это другая среда, и код должен соответствовать этому.
Solomon Rutzky 28 окт. 2014, в 05:53
0

@ Майк, но я не говорю, что тебе не следует пробовать это, если ты думаешь, что это принесет такую пользу и не столкнется с проблемами, которые, я думаю, могут быть там. В конце концов, я действительно не знаю специфики вашей установки, так что, возможно, она может быть структурирована для работы. Базовая концепция разделяемой библиотеки DLL, которая развернута как на сервере приложений, так и на сервере SQL Server, - это доступ к библиотекам DLL в каждой среде, предоставляющей соответствующие оболочки, в порядке, просто сомнительна зависимость на самом низком уровне от EF, что приводит к сомнению. мне интересно, если код делает вещи, которые обычно хорошо, но не в SQLCLR.
Solomon Rutzky 28 окт. 2014, в 06:06
0

Спасибо за обсуждение, приятель. Я склонен согласиться с вами. Это на самом деле просто исследовательская задача на данном этапе, чтобы увидеть, можно ли это сделать. У меня были сомнения из-за «веса» кода, и вы подтвердили большую часть моих опасений. Простой случай ... просто потому, что вы можете, не обязательно означает, что вы должны. Очень признателен.
Mike 29 окт. 2014, в 01:10
0

@ Майк, пожалуйста. Как я уже сказал, если вычисления могут быть абстрагированы таким образом, чтобы DLL могла быть общей, и были ли значения предоставлены через EF или прямые вызовы через Context Connection (почти без накладных расходов на соединение, если таковые вообще имеются), то это могло бы работать. Но ознакомьтесь с моим ответом здесь от более раннего сегодня ( dba.stackexchange.com/a/81290/30859 ), в частности, с предупреждением: вы столкнетесь с той же проблемой при импорте EF DLL. Для получения дополнительной информации посетите sqlservercentral.com/stairway/105855 (серия, над которой я работаю) и / или свяжитесь со мной через SQLsharp.com
Solomon Rutzky 29 окт. 2014, в 01:37

Показать ещё 6 комментариев