Есть SqlClr-триггер. И образовался у меня в этом триггере достаточно большой и сложный SELECT, с кусками типа:

(CASE WHEN EXISTS(SELECT * FROM INSERTED I WHERE I.ID = R.ID) THEN '1' ELSE '0' END) AS IsUpdated -- Выбираемая строка была только что добавлена?

а также всякими JOIN'ами. Ибо мне удобно получить ровно одну таблицу-отчет со всеми колонками.

Вопрос 1. Можно или нет вынести этот SELECT на сторону сервера? Если да, то как?

Я имею в виду сделать какую-нибудь хранимую процедуру, или функцию, или еще что-то, что поддерживает SQL Server 2005/8, и вызывать эту сущность, а потом читать в цикле датасет.

Два последующих вопроса имеют смысл только если ответ на первый вопрос утвердительный.

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

Вопрос 2. Прав ли я? Ускорит ли это работу?

Кроме того, в моем SELECT'е содержатся константные строки, но они языкозависимые. То есть, в русской версии это ...WHERE R.Status = "Включено"..., а в английской — ...WHERE R.Status = "Enabled"... Сейчас у меня все локализуемое хранится в ресурсах. Поэтому, план такой: создать в SqlClr-триггере два статических метода, назвать их OnCreate и OnDestroy и пометить как хранимки. При регистрации/дерегистрации сборки на сервере инсталлятором вызывать хранимку, соответствующую первому или второму методу соответственно. Внутри OnCreate создавать SELECT и подставлять вместо {0},{1}... нужные константы из ресурсов, а потом все выражение "выносить" на сервер. Тогда локализовать можно будет исключительно ресурсы, про остальное забыть.

Далее, такие вещи как псевдоколонка IsUpdated копипастятся — один раз указаны в скрипте (AS IsUpdated), второй раз — при чтении ((int)reader["IsUpdated"]). Это плохо. Можно их вынести тоже в ресурсы, тогда копипаста исчезнет.

Вопрос 3. Хорошо ли это придумана стратегия локализации? Есть ли готовый атрибут, чтобы помеченные им методы вызывались SQLServer'ом при (де)регистрации сборки автоматически?

Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Есть SqlClr-триггер. И образовался у меня в этом триггере достаточно большой и сложный SELECT, с кусками типа:

Во-первых, не совсем понятно, что вы понимаете под "вынести на сервер" — sqlclr уже там

Во-вторых, sqlclr _не предназначен_ для реализации сложной бизнес-логики, тем более в триггерах. Если есть возможность, логику стоит перенести в обычные t-sql процедуры.

В-третьих, для булевых значений надо использовать bit (или дефолтный int, если влом писать CAST( ... AS bit).

Если так хочется поиздеваться над собой и над сервером — вперёд, гуглить context connection.

Советую подучить матчасть, иначе никак

А>Кроме того, в моем SELECT'е содержатся константные строки, но они языкозависимые. То есть, в русской версии это ...WHERE R.Status = "Включено"..., а в английской — ...WHERE R.Status = "Enabled"...
Мать-мать-мать — привычно разнеслось эхо(c) . Товарищи окружающие! Cкажите мне, кто вас заставляет с такой дивной настойчивостью и изобретательностью изобретать всё новые и новые грабли, м? Ув. Аноним, чем вас так злит поле типа bit? Сложностью написать на клиенте

textBox.Text = data.Enabled? Resources.EnabledMessage: Resources.DisabledMessage;

?
Зачем, зачем тащить локализуемые ресурсы клиента на сервер???


А>Вопрос 3. Хорошо ли это придумана стратегия локализации?
Ну, вы поняли

Здравствуйте, Sinix, Вы писали:

А>>Есть SqlClr-триггер. И образовался у меня в этом триггере достаточно большой и сложный SELECT, с кусками типа:
S>Во-первых, не совсем понятно, что вы понимаете под "вынести на сервер" — sqlclr уже там
S>Во-вторых, sqlclr _не предназначен_ для реализации сложной бизнес-логики, тем более в триггерах. Если есть возможность, логику стоит перенести в обычные t-sql процедуры.

Логика простая — вызвать COM-сервер и результат положить обратно в виде BLOB'а. Почему триггер? А это расширение существующей системы с утерянными исходниками. Работа есть работа, клиент всегда прав etc. Пожалуйста, не надо флейма на эту тему.

Упомянул я про SQLCLR-ность и триггерность только для вопроса номер три. Для вопросов номер 1 и 2 считайте, что это обычный SQL-клиент на ADO.Net.

S>В-третьих, для булевых значений надо использовать bit (или дефолтный int, если влом писать CAST( ... AS bit).

Про дефолтный int я не понял, я не спец в БД — покажете, как улучшить, скажу вам спасибо. Кастить, конечно же, влом — и так сорок бочек арестантов в запросе, читать глаз ломается.

А>>Кроме того, в моем SELECT'е содержатся константные строки, но они языкозависимые. То есть, в русской версии это ...WHERE R.Status = "Включено"..., а в английской — ...WHERE R.Status = "Enabled"...
S>Мать-мать-мать — привычно разнеслось эхо(c) . Товарищи окружающие! Cкажите мне, кто вас заставляет с такой дивной настойчивостью и изобретательностью изобретать всё новые и новые грабли, м? Ув. Аноним, чем вас так злит поле типа bit? Сложностью написать на клиенте
S>

S>textBox.Text = data.Enabled? Resources.EnabledMessage: Resources.DisabledMessage;
S>

S>?
S>Зачем, зачем тащить локализуемые ресурсы клиента на сервер???

Затем, что БД, ее формат, все справочники и пр. — неизменная реальность, данная нам в ощущениях. "Enabled" — это строка, которую видит конечный юзер и она, без изменений, кладется в таблицу БД из справочника, откуда я могу ее прочитать и использовать в SELECT'е. Между прочим, это даже очень хорошее решение разработчиков оригинального приложения / БД, поскольку... долго объяснять, да и офтопик. Главное, что справочник локализуемый и приходится соответствовать.

Вопросы остаются в силе.

Здравствуйте, Аноним, Вы писали:

А>Между прочим, это даже очень хорошее решение разработчиков оригинального приложения / БД, поскольку... долго объяснять, да и офтопик.

Здравствуйте, Аноним, Вы писали:

Я еще немного объяснюсь.

Во-первых, все УЖЕ написано и работает. Мой вопрос не как написать, а как улучшить. Да и для себя хочу разобраться.

Во-вторых, я не спец в вопросах БД — я спец в вопросах генерации BLOB'а и соответствующих алгоритмов. Просто мне надо интегрировать эту генерацию в существующую систему. Считается, что эта задача простая, "в нагрузку", и так оно, в общем-то, и есть.

В-третьих, я подтираю чужое дерьмо — система изначально поставляется без исходников, а для решения таких задач предполагается использование плагинов. Но эту плагинность писал пьяный дятел, оверхед получается 10000% + охеренная куча геморроя (например, дается большой таймаут, но оверхед съедает его весь — формально не придерешься, таймаут большой, но из него мне достаются кошкины слезы). Или, может быть, специально испортили, чтобы плагины заказывали им же. Пришлось делать триггер, так хоть все работает.

Так вот, хоть это все и гавённенько в силу обстоятельств, но это не повод на своем уровне плевать прямо на пол. На своем уровне я хочу сделать все настолько хорошо, насколько возможно. Всю локализацию свести к ресурсам, а не размазывать по коду, вынести SQL в отдельные файлы, за исключением простейших SELECT'ов и так далее.

Здравствуйте, MozgC, Вы писали:

А>>Между прочим, это даже очень хорошее решение разработчиков оригинального приложения / БД, поскольку... долго объяснять, да и офтопик.

MC>

В отличие от плагинности, это действительно хорошо сделано. Но объяснять, как я и написал, слишком долго.

Здравствуйте, Аноним, Вы писали:

Нашел кое-какие ответы сам.

А>Вопрос 1. Можно или нет вынести этот SELECT на сторону сервера? Если да, то как?

Ответ с примерами тут:
http://www.sqlteam.com/article/stored-procedures-returning-data

А>Вопрос 3. Есть ли готовый атрибут, чтобы помеченные им методы вызывались SQLServer'ом при (де)регистрации сборки автоматически?

Изучение Microsoft.SqlServer.Server Namespace показало, что там таких атрибутов нет.

Здравствуйте, Аноним, Вы писали:

А, суровая правда жизни vs солипсизм-идеализм? Тогда прошу прощения за избыточно резкий тон
Посоветовать особо нечего, кроме того, что в таком виде система — представляет из себя жуткий и неустойчивый кошмар, но это вы и без меня знаете

А>Логика простая — вызвать COM-сервер и результат положить обратно в виде BLOB'а.
Насколько знаю (я с таким не сталкивался, поэтому знаю плохо), интероп SQL-CLR с COM (и с COM+/DCOM) [http://stackoverflow.com/questions/3621305/sql-server-2008-and-com-server-programming]официально не поддерживается[/url], поэтому все дальнейшие эксперименты — на свой страх и риск.

А>Почему триггер? А это расширение существующей системы с утерянными исходниками.
В виде хранимой процедуры, в виде job-а по расписанию, или, на крайний, service brocker-ом никак?
Кстати, как вы так умудрились протерять все бэкапы???

А>Упомянул я про SQLCLR-ность и триггерность только для вопроса номер три. Для вопросов номер 1 и 2 считайте, что это обычный SQL-клиент на ADO.Net.
Ага, т.е. по вопросам 1 и 3 у вас отдельный клиент? и как же он вызывается из триггера?

А>Про дефолтный int я не понял, я не спец в БД — покажете, как улучшить, скажу вам спасибо. Кастить, конечно же, влом — и так сорок бочек арестантов в запросе, читать глаз ломается.

CAST(CASE WHEN EXISTS(SELECT * FROM INSERTED I WHERE I.ID = R.ID) THEN 1 ELSE 0 END AS bit) AS IsUpdated

Вы использовали строковые литералы и IsUpdated у вас — строковый. Зачем?

А>>>Кроме того, в моем SELECT'е содержатся константные строки, но они языкозависимые. То есть, в русской версии это ...WHERE R.Status = "Включено"..., а в английской — ...WHERE R.Status = "Enabled"...
А>Затем, что БД, ее формат, все справочники и пр. — неизменная реальность, данная нам в ощущениях. "Enabled" — это строка, которую видит конечный юзер и она, без изменений, кладется в таблицу БД из справочника, откуда я могу ее прочитать и использовать в SELECT'е.
Я уточню на всякий: вы выпускаете (с утерянными исходниками, чтохарактерно) 2 версии софта — англо-и русскоязычную? Если нет, и англоязычные и русскоязычные данные лежат вперемешку — как вы их друг от друга отличаете?

Раз уж у нас вечер извращений — можно завести хранимки Recreate_RU_ru и Recreate_EN_us и вызывать из них соответствующие скрипты. Если непременно надо вызывать автоматом — используйте DDL trigger на CREATE_ASSEMBLY, ALTER_ASSEMBLY.

Временно ушёл, принимайте эстафету

Здравствуйте, Sinix, Вы писали:

S>Во-вторых, sqlclr _не предназначен_ для реализации сложной бизнес-логики, тем более в триггерах. Если есть возможность, логику стоит перенести в обычные t-sql процедуры.

Гм, почему? Мне всегда казалось, что если некоторая логика на tsql работает медленно или с трудом реализуется, то ей прямой путь в sqlclr. Иначе, если сложную логику на clr нельзя, то зачем он вообще нужен?

Здравствуйте, Sshur, Вы писали:

S>>Во-вторых, sqlclr _не предназначен_ для реализации сложной бизнес-логики, тем более в триггерах. Если есть возможность, логику стоит перенести в обычные t-sql процедуры.
S>Гм, почему?
Потому что не нужен (с). Если коротко, лучше не скрещивать декларативный sql с императивщиной непосредственно на уровне СУБД. Отвратительно сказывается на производительности и на сложности поддержки.

S> Иначе, если сложную логику на clr нельзя, то зачем он вообще нужен?
Для расширения t-sql. Вспомогательные функции, агрегаты, генераторы, интероп с внешним миром (в крайних случаях) и тыды и тыпы.

Здравствуйте, Sinix, Вы писали:

S>Потому что не нужен (с). Если коротко, лучше не скрещивать декларативный sql с императивщиной непосредственно на уровне СУБД. Отвратительно сказывается на производительности и на сложности поддержки.

Не согласен. Производительность как раз выигрывает по любому, иначе бы не стоило вообще с clr заморачиваться. Поддержка на первый взгляд более сложная, но только на первый. Внесение изменений и повторное использование кода на c# на порядок легче чем на sql.

Другое дело, что для 90% типичных операций в базах данных sql достаточно. Но есть и остальные 10%, видно вы с ними не сталкивались.

S>> Иначе, если сложную логику на clr нельзя, то зачем он вообще нужен?
S>Для расширения t-sql. Вспомогательные функции, агрегаты, генераторы, интероп с внешним миром (в крайних случаях) и тыды и тыпы.

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

Здравствуйте, Sshur, Вы писали:

S>Не согласен. Производительность как раз выигрывает по любому, иначе бы не стоило вообще с clr заморачиваться.
Единичного скрипта — да, но не всегда. Простыня из T-SQL с курсором внутри может оказаться дешевле.

А вот в высоконагруженных сценариях включение sql-clr-хранимок, использующих context connection, неизменно становилось серьёзной проблемой. Особенно, если используются транзакции. Лучше вынести в sqlclr числомолотилки и включать их в запрос.

S>Поддержка на первый взгляд более сложная, но только на первый. Внесение изменений и повторное использование кода на c# на порядок легче чем на sql.
Если используются VSDB projects, ситуация меняется на обратную.


S>Другое дело, что для 90% типичных операций в базах данных sql достаточно. Но есть и остальные 10%, видно вы с ними не сталкивались.
Сталкивался, и большую часть удалось свести к обычным запросам. Вполне возможно, есть задачи, которые удобно перетащить целиком в sqlclr. Мне таких не попадалось

S>Ну так любую логику можно назвать вспомогательной или генератором. Я использовал clr процедуры например для расчета отчетов с нарастающим итогом
Нарастающий итог лучше считать или в движке отчётов, или на клиенте, есть куча нюансов, чоторые на сервере делать откровенно неудобно: округление с учётом накопленных погрешностей, горячая фильтрация/сортировка и тыды и тыпы.

S>генерации списков по шаблону, проверки сложных условий и сложного парсинга строк. По моему все это части бизнес логики
Если это "пассивный" код — не обращается сам к данным, не рулит поведением приложения, не имеет побочных эффектов — то это как раз вспомогательные методы, и тут нет никакого криминала.

Чтоб дальше не спорить — официальные рекомендации:

Here is a summary of some guidelines we have seen can be used in choosing between CLR and T-SQL:
— Use declarative T-SQL SELECT, INSERT, UPDATE, and DELETE statements whenever possible. Procedural and row-based processing should be used only when the logic is not expressible using the declarative language.
— If the procedure is simply a wrapper for declarative T-SQL commands it should be written in T-SQL.
— If the procedure primarily involves forward-only, read-only row navigation through a result set with some processing of each row, using the CLR is likely more efficient.
— If the procedure involves both significant data access and computation, consider separating the procedural code into a CLR portion that calls into a T-SQL procedure to perform data access, or a T-SQL procedure that calls into the CLR to perform computation. Another alternative is to use a single T-SQL batch that includes a set of queries that are executed once from managed code to reduce the number of round trips of submitting T-SQL statements from managed.

Здравствуйте, Sinix, Вы писали:


S>Единичного скрипта — да, но не всегда. Простыня из T-SQL с курсором внутри может оказаться дешевле.

То что там делают на clr, называется удалением гланд через задницу. Примерно то же самое, что делать update через linq2sql. Умеючи можно что угодно медленно сделать.

S>А вот в высоконагруженных сценариях включение sql-clr-хранимок, использующих context connection, неизменно становилось серьёзной проблемой. Особенно, если используются транзакции. Лучше вынести в sqlclr числомолотилки и включать их в запрос.
Это никак не противоречит тому, что я сказал.

S>>Поддержка на первый взгляд более сложная, но только на первый. Внесение изменений и повторное использование кода на c# на порядок легче чем на sql.
S>Если используются VSDB projects, ситуация меняется на обратную.
? Поясните.

S>Сталкивался, и большую часть удалось свести к обычным запросам. Вполне возможно, есть задачи, которые удобно перетащить целиком в sqlclr. Мне таких не попадалось
см. ниже

S>>генерации списков по шаблону, проверки сложных условий и сложного парсинга строк. По моему все это части бизнес логики
S>Если это "пассивный" код — не обращается сам к данным, не рулит поведением приложения, не имеет побочных эффектов — то это как раз вспомогательные методы, и тут нет никакого криминала.

S>Чтоб дальше не спорить — официальные рекомендации:
S>

S>Here is a summary of some guidelines we have seen can be used in choosing between CLR and T-SQL:
S>- Use declarative T-SQL SELECT, INSERT, UPDATE, and DELETE statements whenever possible. Procedural and row-based processing should be used only when the logic is not expressible using the declarative language.
S>- If the procedure is simply a wrapper for declarative T-SQL commands it should be written in T-SQL.
S>- If the procedure primarily involves forward-only, read-only row navigation through a result set with some processing of each row, using the CLR is likely more efficient.
S>- If the procedure involves both significant data access and computation, consider separating the procedural code into a CLR portion that calls into a T-SQL procedure to perform data access, or a T-SQL procedure that calls into the CLR to perform computation. Another alternative is to use a single T-SQL batch that includes a set of queries that are executed once from managed code to reduce the number of round trips of submitting T-SQL statements from managed.

Выделил то что мне нравится в clr. Вот именно когда надо последовательно обрабывать записи и изменять их в зависимости от значений в предыдущей/последующей строке — тогда clr процедуры оказываются гораздо проще и эффективнее мега запросов с самообъединениями. Например, посчитать вышеупомянутый нарастающий итог. Или, тут был недавно вопрос с планировщиком, когда надо было по стартовой дате и шаблону наступления события сгенерировать последовательность временных интервалов срабатывания события. Тут sql сливает полностью.

Я считаю, что только таких случаев достаточно, чтобы не говорить, что

sqlclr _не предназначен_ для реализации сложной бизнес-логики,

без всяких вариантов...

Здравствуйте, Sshur, Вы писали:

S>>А вот в высоконагруженных сценариях включение sql-clr-хранимок, использующих context connection, неизменно становилось серьёзной проблемой. Особенно, если используются транзакции. Лучше вынести в sqlclr числомолотилки и включать их в запрос.
S>Это никак не противоречит тому, что я сказал.
Хмм? Получается, у нас просто разногласия в терминологии: вы относите к бизнес-логике всякие хелперы, я — нет?

S>>>Поддержка на первый взгляд более сложная, но только на первый. Внесение изменений и повторное использование кода на c# на порядок легче чем на sql.
S>>Если используются VSDB projects, ситуация меняется на обратную.
S>? Поясните.
Это щупать надо Главное преимущество T-SQL — REPL. Практически вживую (разумеется, на тестовом сервере) можно поэксперементировать с парой-тройкой в принципе разных подходов и получить более-менее правдоподобную оценку. VSDB-проекты убирают главные грабли t-sql: никакую верификацию/позднее обнаружение ошибок и сложность в сопровождении и деплойменте охапки скриптов.

S> Вот именно когда надо последовательно обрабывать записи и изменять их в зависимости от значений в предыдущей/последующей строке — тогда clr процедуры оказываются гораздо проще и эффективнее мега запросов с самообъединениями.
1. В тру-реляционке нет такого понятия, как порядок данных. Как только он у вас появился — вы уже пытаетесь натянуть ужа на ежа. Self-join тут — вполне нормальное решение.
2. Пока что у меня накладные расходы на передачу резалтсета туда/обратно неизменно убивали выигрыш.

S>Или, тут был недавно вопрос с планировщиком, когда надо было по стартовой дате и шаблону наступления события сгенерировать последовательность временных интервалов срабатывания события. Тут sql сливает полностью.
это элементарная table-valued function. Какое оно отношение имеет к бизнес-логике?

On 02.01.2011 16:09, Аноним 433 wrote:

> *Вопрос 1*. Можно или нет вынести этот SELECT на сторону сервера? Если да, то как?

> Почему я хочу так сделать — во-первых, мне не нравится держать много SQL-кода
> среди C#-кода.

Да. Можно почти наверняка использовать подготовленное выполнение в .net и
оно создаст курсор или процедуру само. Или ещё вариант-написать хранимую
процедуру и выполнять её из .net кода.

Но это очень сильно зависит от того, какой именно запрос ты хочеш выполнять.
Некоторые запросы так выполнять нельзя. Кроме того, если это триггер, там
тоже есть некие ограничения.

Во-вторых, я полагаю, что если код вынести на сервер, он будет
> выполняться быстрее, ибо SQL Server сможет понять, что надо закешировать такой
> запрос, а если он каждый раз будет получать его заново, то не факт.

Не факт. Зависит от многих факторов, в первую очередь от самого запроса.


>
> *Вопрос 2*. Прав ли я? Ускорит ли это работу?

Зависит от многих факторов, в первую очередь от самого запроса.
>
> Кроме того, в моем SELECT'е содержатся константные строки, но они
> языкозависимые. То есть, в русской версии это ...WHERE R.Status = "Включено"...,
> а в английской — ...WHERE R.Status = "Enabled"... Сейчас у меня все локализуемое
> хранится в ресурсах. Поэтому, план такой: создать в SqlClr-триггере два

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


> Далее, такие вещи как псевдоколонка IsUpdated копипастятся — один раз указаны в
> скрипте (AS IsUpdated), второй раз — при чтении ((int)reader["IsUpdated"]). Это
> плохо. Можно их вынести тоже в ресурсы, тогда копипаста исчезнет.

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

Здравствуйте, Sinix, Вы писали:

S>>Это никак не противоречит тому, что я сказал.
S>Хмм? Получается, у нас просто разногласия в терминологии: вы относите к бизнес-логике всякие хелперы, я — нет?

Получается, да. Я так понимаю, БЛ — любые действия, связанные с предметной областью. Опять же хэлпер — это всего лишь часто повторяющаяся операция, которая выделена отдельно для повторного использования. Все равно это часть БЛ.

S>Это щупать надо Главное преимущество T-SQL — REPL. Практически вживую (разумеется, на тестовом сервере) можно поэксперементировать с парой-тройкой в принципе разных подходов и получить более-менее правдоподобную оценку. VSDB-проекты убирают главные грабли t-sql: никакую верификацию/позднее обнаружение ошибок и сложность в сопровождении и деплойменте охапки скриптов.

Так я не понял, вы говорите что VSDB плохо или хорошо?


S>> Вот именно когда надо последовательно обрабывать записи и изменять их в зависимости от значений в предыдущей/последующей строке — тогда clr процедуры оказываются гораздо проще и эффективнее мега запросов с самообъединениями.
S>1. В тру-реляционке нет такого понятия, как порядок данных. Как только он у вас появился — вы уже пытаетесь натянуть ужа на ежа. Self-join тут — вполне нормальное решение.

В тру- может и нет, но в реальной жизни порядок есть. И тут как раз у sql начинаются проблемы

S>2. Пока что у меня накладные расходы на передачу резалтсета туда/обратно неизменно убивали выигрыш.
Ког
Зачем передавать туда-обратно? У меня пока что было так: хранимка на clr выполняет некоторый sql запрос, который получает предварительные данные, потом их дополнительно обрабатывает и возвращает пользователю. Правда, может быть и обратный вариант -когда пользователь передает в хранимку например xml, который та разбирает и вставляет данные в таблицы



S>>Или, тут был недавно вопрос с планировщиком, когда надо было по стартовой дате и шаблону наступления события сгенерировать последовательность временных интервалов срабатывания события. Тут sql сливает полностью.
S> это элементарная table-valued function. Какое оно отношение имеет к бизнес-логике?

Ну да, у меня оно функцией и было. Если говорить конкретно, то это был график выхода сотрудников на работу. По моему, как раз БЛ.

Здравствуйте, Sshur, Вы писали:

S>Получается, да. Я так понимаю, БЛ — любые действия, связанные с предметной областью. Опять же хэлпер — это всего лишь часто повторяющаяся операция, которая выделена отдельно для повторного использования. Все равно это часть БЛ.
Тогда закругляемся

S>Так я не понял, вы говорите что VSDB плохо или хорошо?S>Так я не понял, вы говорите что VSDB плохо или хорошо?
Хорошо По крайней мере, я не видел ничего сопоставимого по уровню фич.