IT>Ну так MS и в твой генератор ресурсы вкладывать не будет.
как это не будет если они его написали T4 используется в самой студии и для того же линка.
IT>Что касается спроков, то здесь у BLToolkit конкурентов нет. Вообще.
От стор мы отказываемся, для On Demand систем это зло которое затрудняет обновление системы без downtime-а
Tom>>Я проблем пока реальных на примерах так и не увидел. Есть некоторые нюансы конечно но шоу стоперов реальных я пока не вижу.
IT>Дело не в стоперах, дело в замедлителях и заколебателях. Для конкретных примеров, как я уже говорил, заведи себе тетрадочку.
Tom>>Размазывания в виде конткатенаций скорее всего ожидать не стоит, а вот размазывания по разным C# файлам и возможно сборкам вполне (это если писать TSQL в коде)
IT>А ты всё в одном файле и в одном классе собираешься держать?
Tom>>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует. Tom>>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь. IT>Остальные 80% элементарно достигаются применением таблиц-функций и получающимся смешанным стилем клиентский код/SQL.
Не не не не, Дэвид Блэйн, это чёрная магия к тому же имеющая большие ограничения.
IT>PersonNamespace_Person_List_GetPersonByCriteria15?
Игорь, если хочется, то любую идею довести до идиотизма.
Весь разговор сводится к тому что BLToolkit это хорошо, но на мои аргументы я так ответа твоего не услышал. Ещё раз повторю:
При использовании BLToolkit-а приходится:
1. Писать руками классы акцэсоров/resultset-ов. Что в свою очередь:
1.1 Затрудняет поддержку. Так как если селект возвращает новое поле, или не возвращает поля вообще то во время компиляции ты об этом никогда не узнаешь.
1.2 делает невозможным переход на BLToolkit для Legacy прилоджений. Допустим у нас 1000 хранимок возвращабщих resultset. Никто не будет руками писать и поддерживать эту 1000 классов.
2 Поощеряет написание TSQL в коде. Что усложняет поддержку. А именно:
2.1 Проверить синтаксис TSQL можно только в runtime.
2.2 Делает невозможным использовать средства рефакторинга/анализа TSQL кода, такие как VSTS Database Edition GDR и прочие.
2.3 Делает невозможным валидацию кода в compile time средствами, которые являются аналогом Fx Cop но для TSQL. (фактически анализ кода)
Если интересно продолжать то хотелось бы аргументированно и с примерами.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Tom, Вы писали:
Tom>>>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы. Tom>>>>Когда мы пишем руками — мы не имеем ни первого ни второго. IT>>>Как это не имеем? А как же Linq2Sql? Tom>>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет. G>Linq2SQL уже развиваться не будет, смотрите в сторону EF.
В его сторону рано пока смотреть, но я бы сказал ещё в зачаточном состоянии.
Да и двигается он в неправильном направлении, в стороно полного ORM решения.
Если хочется ORM, да ещё и с нормальной поддержкой линка — то лучше пока использовать сторонние решения.
Например LLBGenPro
G>У вас рефакторинг БД случается чаще\имеет больший объем, чем рефакторинг кода?
Это трудно оценить но по сложности база конечно опережает прикладной код.
Tom>>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует. Tom>>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь. G>Инкапсулируйте сложность на уровне БД, создавайте вьюхи для развесистых выборок, используйте хранимки, не возвращающие результат, для операций изменения данных. G>Кроме того Linq2SQL позволяет скалярные функции использовать в теле запросов. EF покачто такого не умеет.
Tom>>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты. G>Со временем ручной кодинг таких вариантов будет отнимать все больше времени.
Здравствуйте, Tom, Вы писали:
IT>>Как это не имеем? А как же Linq2Sql? Tom>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
Только не надо домысливать слова Влада. Я сетовал на то, что Linq не поддерживает DML. Но я никогда не говорил, что Linq идет в лес. Наоборот, я считаю Linq одним из самых перспективных средств доступа к данным.
К тому же уверен, что IT под термином Linq2Sql подразумевал не конкретный провайдер, а сам Linq применительно к доступу к БД. Провайдер же может быть и другой. Скажу тебе по секрету, IT пишет свой провайдер.
Tom>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.
Linq — это не TSQL. Это даже не SQL. Хотя к последнему он ближе.
Что касается рефакторинга БД, я тебе уже говорил. Надо просто развернуть все и по модели строить БД, а не по БД пытаться обновлять код.
В прочем, можно и так. Изменять БД тоже можно. Контроль типов при этом остается.
Tom>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.
Можно конкренее? Что коме CTE не реализовано в linq?
Tom>Какой смысл себя ограничивать так?
TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо?
Tom>Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
Какую мощь? А сожные запросы — это не более чем дерево из более простых. И linq, в отличии от TSQL-я, имеет средства декомпозиции сложных запросов в последовательность простых.
Tom>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.
Это какие-то шаманские танцы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Только не надо домысливать слова Влада. Я сетовал на то, что Linq не поддерживает DML. Но я никогда не говорил, что Linq идет в лес. Наоборот, я считаю Linq одним из самых перспективных средств доступа к данным.
Давай говорить конкретно. Какой провайдер ты предлагаешь?
VD>К тому же уверен, что IT под термином Linq2Sql подразумевал не конкретный провайдер, а сам Linq применительно к доступу к БД. Провайдер же может быть и другой. Скажу тебе по секрету, IT пишет свой провайдер.
Я давно говорил, вашу бы инициативу да в мирное русло
Tom>>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы. VD>Linq — это не TSQL. Это даже не SQL. Хотя к последнему он ближе. VD>Что касается рефакторинга БД, я тебе уже говорил. Надо просто развернуть все и по модели строить БД, а не по БД пытаться обновлять код.
Влад, ты теоретик просто. В реальном приложении это никто не будет делать. У нас майлстоуны не дольше 4-ёх месяцев.
Это означает что каждые 4-ре месяца надо выпускать рабочий продукт. Реально правда он ставится на сервера раз в 9 месяцев.
VD>Можно конкренее? Что коме CTE не реализовано в linq?
ну так как минимум INSERT/DELETE/UPDATE. без них остаётся уже только 25 процентов.
ну а если приглядеться — MERGE/HAVING, хинты, управление уровнем изоляции итп...
VD>TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо?
Потому, что это основной язык который развивает поставщик БД. Я может и не в восторге но другой альтернативы нет пока.
И единственный на сегодняшний день язык который обладает полной мощью для соответствующей БД.
Tom>>Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь. VD>Какую мощь? А сожные запросы — это не более чем дерево из более простых. И linq, в отличии от TSQL-я, имеет средства декомпозиции сложных запросов в последовательность простых.
Tom>>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.
VD>Это какие-то шаманские танцы.
Здравствуйте, Tom, Вы писали:
IT>>Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно. Tom>А, понятно, дело в том что от обезьяны с гранатой спасения нет. Tom>Особенно если туда ещё и условие присобачить. Tom>Но и задачи спастить от идиота не ставится. Tom>Ну и у нас код ревью есть абсолютно всех changeset-ов. Tom>Такое можно вылавливать.
Причем тут идиоты? Тебя спросили как твой генератор будет себя вести в условиях когда разные запросы возвращают один и тот список полей. Будешь формировать разные типы? В linq — это не проблема. Там все типизровано и будет возвращен или конкретный тип, или анонимный тип.
Tom>Конечно из жизни. Тяжёлой и горькой Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький.
С этого места можно по подробнее.
Tom>В наших проектах он не применим из за убогости.
Убогости вашего проекта? Ты извини, но без обоснования эти слова тяжело применить к linq.
Tom>да и смысла применять мёртвый проект я не вижу.
Применяй EF.
Tom>Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.
То что эти слова являются мягко говоря заблуждением тебе уже сказал не раз. Так что не стоит повторяться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Tom>>Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.
VD>То что эти слова являются мягко говоря заблуждением тебе уже сказал не раз. Так что не стоит повторяться.
VD>Причем тут идиоты? Тебя спросили как твой генератор будет себя вести в условиях когда разные запросы возвращают один и тот список полей. Будешь формировать разные типы? В linq — это не проблема. Там все типизровано и будет возвращен или конкретный тип, или анонимный тип.
Будет возвращён конкретный тип или анонимный. В моём варианте и в варианте линка нет разницы. Он так же как и я генерит враперы над хранимками например.
Tom>>Конечно из жизни. Тяжёлой и горькой Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький. VD>С этого места можно по подробнее.
Реальная проблема раз. Поддержка большого количества рукописных resultset классов.
Проблема два, в коде есть TSQL. Некто его правит и допускает мелкую синтаксическую ошибку.
Об этом мы узнаём только когда клиент тыкает на кнопочку.
Проблема три. Намечается большой рефакторинг базы, всех стор, таблиц и запросов.
Как быть с тем TSQL который живёт в C# не совсем понятно.
Тем более непонятно что делать с существующими resultset классами.
Они должны соответствовать новому дизайну базы.
Tom>>В наших проектах он не применим из за убогости.
VD>Убогости вашего проекта? Ты извини, но без обоснования эти слова тяжело применить к linq.
Какой конкретно linq провайдер? И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?
Tom>>да и смысла применять мёртвый проект я не вижу. VD>Применяй EF.
Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?
Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.
Здравствуйте, Tom, Вы писали:
Tom>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Tom, Вы писали:
Tom>>>>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы. Tom>>>>>Когда мы пишем руками — мы не имеем ни первого ни второго. IT>>>>Как это не имеем? А как же Linq2Sql? Tom>>>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет. G>>Linq2SQL уже развиваться не будет, смотрите в сторону EF. Tom>В его сторону рано пока смотреть, но я бы сказал ещё в зачаточном состоянии. Tom>Да и двигается он в неправильном направлении, в стороно полного ORM решения. Tom>Если хочется ORM, да ещё и с нормальной поддержкой линка — то лучше пока использовать сторонние решения. Tom>Например LLBGenPro
Двигается EF в разных направлениях. Видимо разработчики EF хотят покрыть как можно больше сценариев работы с даннми, а не наставить всех на "единственно верный путь".
Даже сейчас EF — очень удачное решение для систем, в которых не требуется особо навороченных функций от БД.
G>>У вас рефакторинг БД случается чаще\имеет больший объем, чем рефакторинг кода? Tom>Это трудно оценить но по сложности база конечно опережает прикладной код.
То что по сложности опережает это понятно, но всетаки мне кажется что база рефакторится не так часто как изменяется код приложения.
Если работать близко к SQL, то затрудняется рефакторинг\изменение функционала приложения.
Здравствуйте, Tom, Вы писали:
VD>>Только не надо домысливать слова Влада. Я сетовал на то, что Linq не поддерживает DML. Но я никогда не говорил, что Linq идет в лес. Наоборот, я считаю Linq одним из самых перспективных средств доступа к данным. Tom>Давай говорить конкретно. Какой провайдер ты предлагаешь?
Я их не создаю, так что мне их рекламировать нет проку.
Использовать можно любой. EF и Linq2sql вполне рабочие решения.
Когда IT доделает свой провайдер, то скорее всего он будет более предпочтителен, так как его не сложно будет оснастить поддержкой DML.
VD>>К тому же уверен, что IT под термином Linq2Sql подразумевал не конкретный провайдер, а сам Linq применительно к доступу к БД. Провайдер же может быть и другой. Скажу тебе по секрету, IT пишет свой провайдер. Tom>Я давно говорил, вашу бы инициативу да в мирное русло
Одни говорят (давно), а другие делают. Улавливаешь разницу?
VD>>Что касается рефакторинга БД, я тебе уже говорил. Надо просто развернуть все и по модели строить БД, а не по БД пытаться обновлять код. Tom>Влад, ты теоретик просто. В реальном приложении это никто не будет делать. У нас майлстоуны не дольше 4-ёх месяцев.
Я просто не приемлю кривые решения основанные на компромиссах. Если делать, то делать хорошо.
Tom>Это означает что каждые 4-ре месяца надо выпускать рабочий продукт. Реально правда он ставится на сервера раз в 9 месяцев.
И что? Применением экстенсивных и кривых методов ты конечно получишь быстрый старт в начале разработки, но чем больше будет становиться проект, тем медленнее он будет развиваться и тем труднее его будет поддерживать. Так что рано или поздно твоя гонка за скоростью даст обратный эффект.
К тому все описанное тобой — это ваши проблемы. Вы сами создали себе условия и рамки.
Насколько я знаю тот же IT использует в старых проектах BLToolkit + linq и работает над собственным linq-провайдером.
В следующем проекте он просто возьмет свой новый провайдер и избавится ото всех компромиссов.
Вы же так и будете убеждать себя, что других путей нет.
VD>>Можно конкренее? Что коме CTE не реализовано в linq? Tom>ну так как минимум INSERT/DELETE/UPDATE. без них остаётся уже только 25 процентов.
Запросы — это 90% работы. А INSERT/DELETE/UPDATE можно оформить в виде библиотеки.
Tom>ну а если приглядеться — MERGE/HAVING, хинты, управление уровнем изоляции итп...
Хинты — это не возможности SQL-я. Это средства оптимизации. Оных можно добиться и без хинтов.
Более того, IT тебе не зря указывал на то, что запрос переписанный из монолитного SQL-я в ряд linq-азпросов решил проблему производительности в одном из мест нашего сервера. Так что многие хинты просто не будут нужны.
В итоге ты так и не показал где же мы теряем в мощности при использовании linq-а. Сдается мне, что дело в другом. linq просто нужно уметь готовить. Он требует других подходов, другого менталитета.
VD>>TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо? Tom>Потому, что это основной язык который развивает поставщик БД. Я может и не в восторге но другой альтернативы нет пока.
Что, простите, развивает? Да он реально не развивается вот уже 10 лет. Так мелкие примочки добавляют при полностью гнилой базе.
При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается.
Tom>И единственный на сегодняшний день язык который обладает полной мощью для соответствующей БД.
Он обладает полной немощью как язык программирования. Этого одного уже достаточно чтобы его никогда не применят. А sql прекрасно коррелирует с linq. Единственная проблема DML, но она как раз решаема.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве.
Ты бы объяснил, для начала, что ты понимаешь под мощью и под сложными запросами? Лучше всего на базе примеров.
Tom>Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.
Можно поставить вопрос по другому. В чем смысл вместо одного языка (например, C#) использовать два (например, C# + TSQL) и тратить кучу времени на обеспечение их взаимодействия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я их не создаю, так что мне их рекламировать нет проку. VD>Использовать можно любой. EF и Linq2sql вполне рабочие решения. VD>Когда IT доделает свой провайдер, то скорее всего он будет более предпочтителен, так как его не сложно будет оснастить поддержкой DML.
И всё же, какой провайдер ты предлагаешь использовать СЕЙЧАС. Не завтра и не после завтра, а сейчас?
VD>Одни говорят (давно), а другие делают. Улавливаешь разницу?
А я по твоему ничего не делаю? Просто ты волен заниматсья тем что тебе интересно, а мне приходится работать в реальных проектах с большой и многолетней историей (более 15 лет) и огромный количеством кода. Если формально посчитать — то более 100 мегабайт.
VD>И что? Применением экстенсивных и кривых методов ты конечно получишь быстрый старт в начале разработки, но чем больше будет становиться проект, тем медленнее он будет развиваться и тем труднее его будет поддерживать. Так что рано или поздно твоя гонка за скоростью даст обратный эффект.
Он уже огромный, и я его уменьшаю в разы. По моим оченкам обьём кода я смогу уменьшить на порядок
VD>К тому все описанное тобой — это ваши проблемы. Вы сами создали себе условия и рамки. VD>Насколько я знаю тот же IT использует в старых проектах BLToolkit + linq и работает над собственным linq-провайдером. VD>В следующем проекте он просто возьмет свой новый провайдер и избавится ото всех компромиссов. VD>Вы же так и будете убеждать себя, что других путей нет.
VD>Хинты — это не возможности SQL-я. Это средства оптимизации. Оных можно добиться и без хинтов. VD>Более того, IT тебе не зря указывал на то, что запрос переписанный из монолитного SQL-я в ряд linq-азпросов решил проблему производительности в одном из мест нашего сервера. Так что многие хинты просто не будут нужны.
VD>В итоге ты так и не показал где же мы теряем в мощности при использовании linq-а. Сдается мне, что дело в другом. linq просто нужно уметь готовить. Он требует других подходов, другого менталитета.
Я тебе обьяснил чего нету в линке. Ты это услышать не захотел. Если не понятно — читай выше.
VD>>>TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо? Tom>>Потому, что это основной язык который развивает поставщик БД. Я может и не в восторге но другой альтернативы нет пока. VD>Что, простите, развивает? Да он реально не развивается вот уже 10 лет. Так мелкие примочки добавляют при полностью гнилой базе.
Какие примочки и причём тут гнилапя база? Для MS SQL Server — а единственный язык общения — это TSQL.
VD>При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается.
От MS реального решения для работы с данными пока нет. И тем более нет решения позволяющего правно смигрировать с существующего кода.
Tom>>И единственный на сегодняшний день язык который обладает полной мощью для соответствующей БД. VD>Он обладает полной немощью как язык программирования. Этого одного уже достаточно чтобы его никогда не применят. А sql прекрасно коррелирует с linq. Единственная проблема DML, но она как раз решаема.
Влад, ты какой нибудь другой язык который понимает SQL сервер?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Tom, Вы писали:
Tom>>В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве.
VD>Ты бы объяснил, для начала, что ты понимаешь под мощью и под сложными запросами? Лучше всего на базе примеров.
ну вот поростой и типичный вариант
CREATE PROCEDURE [dbo].[BvSpCall_Activate]
@SurveySID INT,
@ClassID INT,
@Mode INT,
@BatchID INT,
@Priority INT,
@RoleID INT,
@PersonSID INT,
@ShiftTypeID INT,
@TimeToCall DATETIME
AS
SET XACT_ABORT ON
SET NOCOUNT ON-- IF @ShiftTypeID = 0
-- SET @ShiftTypeID = NULLCREATE TABLE #batch
(
[ID] [int] NOT NULL PRIMARY KEY
)
CREATE TABLE #tz (
[ID] [int] NOT NULL,
TimeZoneID [int] NOT NULL,
Bias [int] NOT NULL,
ShiftTypeID [int] NULL,
ITS [int] NOT NULL
)
DECLARE @result INT,
@ErrorMessage NVARCHAR(4000),
@ErrorNumber INT,
@ErrorSeverity INT,
@ErrorState INT,
@ErrorLine INT,
@ErrorProcedure NVARCHAR(200);
SET @result = 0;
BEGIN TRY
IF (@Mode = 1) -- means activate prepared scheduled callsINSERT INTO #tz
SELECT BvSvySchedule.[ID], ISNULL(BvInterview.TimezoneID, 0), 0, NULL, 0
FROM BvSvySchedule, BvInterview, BvPreparedCalls
WHERE BvPreparedCalls.ItemID = BvSvySchedule.[ID]
AND BvSvySchedule.SurveySID = BvInterview.SurveySID
AND BvSvySchedule.InterviewID = BvInterview.[ID]
AND BvPreparedCalls.BatchID = @BatchID
ELSE IF (@Mode = 2) -- activate prepared suspended callsBEGIN
INSERT INTO #batch( [ID] )
SELECT DISTINCT ItemID FROM BvPreparedCalls WITH( NOLOCK ) WHERE BatchID = @BatchID
INSERT INTO #tz
SELECT BvInterview.[ID], ISNULL(BvInterview.TimezoneID, 0), 0, NULL, BvInterview.TransientState
FROM BvInterview
INNER JOIN #batch ON #batch.[ID] = BvInterview.[ID]
WHERE BvInterview.SurveySID = @SurveySID
AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
WHERE SurveySID = @SurveySID
AND InterviewID = BvInterview.[ID] )
END
ELSE-- (@Mode = 3) -- activate all suspended callsINSERT INTO #tz
SELECT BvInterview.[ID], ISNULL(BvInterview.TimezoneID, 0), 0, NULL, BvInterview.TransientState
FROM BvInterview
WHERE BvInterview.SurveySID = @SurveySID
AND BvInterview.TransientState != 13
AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
WHERE BvSvySchedule.SurveySID = @SurveySID
AND BvSvySchedule.InterviewID = BvInterview.[ID] )
IF (@Mode = 2)
-- check if activation for interview transient state is disabledIF EXISTS(SELECT 1
FROM BvState INNER JOIN #tz ON BvState.StateID = #tz.ITS
WHERE
BvState.StateGroupID = (SELECT BvSurvey.StateGroupID FROM BvSurvey WHERE BvSurvey.SID = @SurveySID) AND
DA = 1)
BEGIN
DELETE BvPreparedCalls WHERE BatchID = @BatchID
SET @result = -1
RAISERROR( 'Restricted records selected, cannot activate calls. No activation performed for this action', 16, 1 )
--RETURN (-1)END
CREATE TABLE #tzb (
TimeZoneID [int] NOT NULL
)
INSERT INTO #tzb SELECT DISTINCT TimeZoneID FROM #tz
-- Check shiftIF ( @ShiftTypeID != 0 AND--any valid we should chek too
@TimeToCall IS NOT NULL )
BEGIN
DECLARE @TimeToCall2 DATETIME
SET @TimeToCall2 = DATEADD( minute, 1, @TimeToCall )
DECLARE @OwnerID INT
SELECT @OwnerID = BvSchedule.Schd_ID
FROM BvSurvey, BvSchedule, BvScrAsgn
WHERE BvSurvey.SID = @SurveySID AND
BvSurvey.SID = BvScrAsgn.ScAsgn_ObjID AND
BvScrAsgn.Scr_ID = BvSchedule.Scr_ID
CREATE TABLE #activeshift(
ShiftID INT NOT NULL,
OwnerID INT NOT NULL,
[ShiftTypeID] INT NOT NULL
)
INSERT INTO #activeshift EXEC BvSpGetActiveShiftsInRelativeTime @TimeToCall, @TimeToCall2
IF NOT EXISTS ( SELECT 1
FROM #activeshift
WHERE OwnerID = @OwnerID AND
( ShiftTypeID = @ShiftTypeID OR @ShiftTypeID = -1))
BEGIN
DROP TABLE #tz
DROP TABLE #tzb
DROP TABLE #activeshift
IF (@Mode != 3)
DELETE BvPreparedCalls WHERE BatchID = @BatchID
SET @result = -1
RAISERROR( 'Time specified is out of shifts of selected type.', 16, 1 )
--RETURN (-1)END
DROP TABLE #activeshift
END-- Init timezones biasDECLARE crTZ CURSOR LOCAL FAST_FORWARD LOCAL
FOR SELECT TimeZoneID FROM #tzb WHERE TimeZoneID <> 0
DECLARE @tzID INT
DECLARE @Bias INT
DECLARE @SiteBias INT
DECLARE @DefaultTZID INT
DECLARE @dt_bias DATETIME
SET @dt_bias = ISNULL( @TimeToCall, GETUTCDATE() )
IF EXISTS( SELECT TimeZoneID FROM #tzb WHERE TimeZoneID <> 0 )
BEGIN-- get default timezone SELECT TOP 1 @DefaultTZID = TimezoneID FROM BvSite
EXEC BvSpGetTZBias @dt_bias, @DefaultTZID, @SiteBias OUTPUT
OPEN crTZ
FETCH NEXT FROM crTZ INTO @tzID
WHILE (@@FETCH_STATUS = 0)
BEGIN
SET @Bias = NULL
EXEC BvSpGetTZBias @dt_bias, @tzID, @Bias OUTPUT
IF @Bias IS NULL BEGIN
SET @result = -2
RAISERROR( 'TimeZone not found, id - %i', 16, 1, @tzID )
--RETURN (-2)END
UPDATE #tz SET Bias = @Bias WHERE TimeZoneID = @tzID
FETCH NEXT FROM crTZ INTO @tzID
END-- close cursorCLOSE crTZ
DEALLOCATE crTZ
END-- Init Shift Type IDIF @ShiftTypeID > 0
UPDATE #tz SET #tz.ShiftTypeID = BvShiftZones.[ID]
FROM BvShiftZones WHERE BvShiftZones.ShiftTypeID = @ShiftTypeID
AND BvShiftZones.TimeZoneID = #tz.TimeZoneID
-- ELSE BEGIN
-- get site biasEXEC BvSpGetDefaultTZBias @TimeToCall, @Bias OUTPUT
UPDATE #tz SET Bias = @Bias WHERE TimeZoneID = 0
-- ENDDECLARE @TimeZoneSet INT
SELECT TOP 1 @TimeZoneSet = -BvSite.TimeZoneID FROM BvSite
--------------------------------------------------------------
-- prepare calls
--------------------------------------------------------------IF (@Mode = 1) BEGIN-- means activate prepared scheduled callsIF @PersonSID <> 0
UPDATE BvSvySchedule
SET TimeInShift = DATEADD( minute, #tz.Bias, @TimeToCall ),
Priority = @Priority,
ShiftTypeID = CASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
THEN - BvInterview.TimeZoneID
WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
THEN @TimeZoneSet
ELSE #tz.ShiftTypeID -- ShiftTypeIDEND,
ExplicitSID = @PersonSID,
ExplicitType = 2,
RoleID = CASE WHEN @RoleID <> 0 AND @RoleID IS NOT NULL
THEN @RoleID ELSE BvSvySchedule.RoleID END
FROM BvSvySchedule
INNER JOIN BvPreparedCalls
ON BvPreparedCalls.ItemID = BvSvySchedule.[ID]
INNER JOIN #tz ON BvSvySchedule.[ID] = #tz.[ID]
INNER JOIN BvInterview ON BvInterview.SurveySID = BvSvySchedule.SurveySID
AND BvInterview.[ID] = BvSvySchedule.InterviewID
WHERE BvPreparedCalls.BatchID = @BatchID
ELSE
UPDATE BvSvySchedule
SET TimeInShift = DATEADD( minute, #tz.Bias, @TimeToCall ),
Priority = @Priority,
ShiftTypeID = CASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
THEN - BvInterview.TimeZoneID
WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
THEN @TimeZoneSet
ELSE #tz.ShiftTypeID -- ShiftTypeIDEND
FROM BvSvySchedule
INNER JOIN BvPreparedCalls
ON BvPreparedCalls.ItemID = BvSvySchedule.[ID]
INNER JOIN #tz ON BvSvySchedule.[ID] = #tz.[ID]
INNER JOIN BvInterview ON BvInterview.SurveySID = BvSvySchedule.SurveySID
AND BvInterview.[ID] = BvSvySchedule.InterviewID
WHERE BvPreparedCalls.BatchID = @BatchID
INSERT INTO BvCachedCallsInsert
SELECT c.InterviewID, @SurveySID
FROM BvSvySchedule c
INNER JOIN BvPreparedCalls p ON p.ItemID = c.[ID]
AND p.BatchID = @BatchID
LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = c.InterviewID
AND ci.SurveySID = @SurveySID
WHERE ci.SurveySID IS NULL
END
ELSE IF (@Mode = 2) BEGIN-- activate prepared suspended callsINSERT INTO BvSvySchedule
SELECT 0, -- AppIDCASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
THEN - BvInterview.TimeZoneID
WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
THEN @TimeZoneSet
ELSE #tz.ShiftTypeID -- ShiftTypeIDEND,
@RoleID,
BvInterview.[ID],
BvInterview.[SurveySID],
2 as PhaseCurrent /*hardcore dbcleanup*/,
@Priority,
DATEADD( minute, #tz.Bias, @TimeToCall), -- TimeInShift
'9999-01-01 00:00:00.000', -- ExpireTime
@PersonSID,
2, -- ExplicitType
'00000000-0000-0000-0000-000000000000'
FROM BvInterview
INNER JOIN #batch ON #batch.[ID] = BvInterview.[ID]
INNER JOIN #tz ON #tz.[ID] = BvInterview.[ID]
WHERE BvInterview.SurveySID = @SurveySID
AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
WHERE SurveySID = @SurveySID
AND InterviewID = BvInterview.[ID] )
UPDATE BvAggregateSurvey WITH(ROWLOCK)
SET ScheduledCallsCountPrev = ScheduledCallsCount,
ScheduledCallsCount = ScheduledCallsCount+@@ROWCOUNT
WHERE SID = @SurveySID
INSERT INTO BvCachedCallsInsert
SELECT #batch.[ID], @SurveySID
FROM #batch
LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = #batch.[ID]
AND ci.SurveySID = @SurveySID
WHERE ci.SurveySID IS NULL
END
ELSE BEGIN-- (@Mode = 3) -- activate all suspended callsINSERT INTO BvSvySchedule
SELECT
0, -- ApptIDCASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
THEN - BvInterview.TimeZoneID
WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
THEN @TimeZoneSet
ELSE #tz.ShiftTypeID -- ShiftTypeIDEND,
@RoleID,
BvInterview.[ID],
@SurveySID,
2 as PhaseCurrent, /*hardcore dbcleanup*/
@Priority,
DATEADD( minute, #tz.Bias, @TimeToCall),-- TimeInShift
'9999-01-01 00:00:00.000', -- ExpireTime
@PersonSID,
2, -- ExplicitType
'00000000-0000-0000-0000-000000000000'
FROM BvInterview
INNER JOIN #tz ON #tz.[ID] = BvInterview.[ID]
INNER JOIN BvSurvey ON BvSurvey.SID = @SurveySID
INNER JOIN BvState ON BvSurvey.StateGroupID = BvState.StateGroupID
AND BvInterview.TransientState = BvState.StateID
AND BvState.DA = 0
WHERE BvInterview.SurveySID = @SurveySID
-- AND BvInterview.TransientState != 13 AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
WHERE BvSvySchedule.SurveySID = @SurveySID
AND BvSvySchedule.InterviewID = BvInterview.[ID] )
UPDATE BvAggregateSurvey WITH(ROWLOCK)
SET ScheduledCallsCountPrev = ScheduledCallsCount,
ScheduledCallsCount = ScheduledCallsCount+@@ROWCOUNT
WHERE SID = @SurveySID
INSERT INTO BvCachedCallsInsert
SELECT #tz.[ID], @SurveySID
FROM #tz
LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = #tz.[ID]
AND ci.SurveySID = @SurveySID
WHERE ci.SurveySID IS NULL
END
IF (@Mode != 3)
DELETE BvPreparedCalls WHERE BatchID = @BatchID
IF ( ( @Mode = 2 OR @Mode = 3 ) AND @PersonSID = 0 )
UPDATE BvSvySchedule SET ExplicitType = 1,
ExplicitSID = BvAssignmentGroup.SID
FROM BvAssignmentGroup
WHERE BvSvySchedule.SurveySID = @SurveySID AND
BvAssignmentGroup.SurveySID = BvSvySchedule.SurveySID AND
BvAssignmentGroup.Phase = BvSvySchedule.Phase AND
BvAssignmentGroup.RoleID = BvSvySchedule.RoleID AND
BvSvySchedule.ExplicitSID = 0
DROP TABLE #tz
DROP TABLE #tzb
DROP TABLE #batch
if @PersonSID = 0 begin
truncate table BvUniqueAssignments
insert into BvUniqueAssignments
select distinct ExplicitSID from BvSvySchedule
LEFT JOIN BvUniqueAssignments bua ON (ExplicitSID = bua.sid)
WHERE bua.SID IS NULL
end
else
exec BvSpAddUniqueAssignment @PersonSID
-- exec BvSpCache_NotifyUpdatedEND TRY
BEGIN CATCH
SELECT @ErrorNumber = ERROR_NUMBER(),
@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE(),
@ErrorLine = ERROR_LINE(),
@ErrorProcedure = ISNULL(ERROR_PROCEDURE(), '-');
SELECT @ErrorMessage =
N'Error %d, Level %d, State %d, Procedure %s, Line %d, ' +
'Message: '+ ERROR_MESSAGE();
RAISERROR( @ErrorMessage,
@ErrorSeverity,
1,
@ErrorNumber,
@ErrorSeverity,
@ErrorState,
@ErrorProcedure,
@ErrorLine
);
RETURN @result;
END CATCH
RETURN @result
Tom>>Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв. VD>Можно поставить вопрос по другому. В чем смысл вместо одного языка (например, C#) использовать два (например, C# + TSQL) и тратить кучу времени на обеспечение их взаимодействия.
Обьясню. Каждый язык имеет область применения.
C# никак не предназначен на сегодняшний день для манипуляции данными. Тем боллее, что серверов БД существует великое множество. И у каждого свой SQL диалект.
Tom>раз заблужденим, то тебе не составит труда ответить по каждому из пунктов?
Там нет ни одного пункта интересующего мнея. BLToolkit меня интересует так же слабо как твои идеи размещения запросов в отдельных файлах.
Лучшим подходом, на мой взгляд, является размещение запросов в виде встроенного (типизированного) DSL внутри кода приложения. Короче говоря подход а-ля linq.
Собственно проблемы linq-а известны:
1. Отсутствие поддержки DML.
2. Некоторая расточительность вызванная тем, что вся генерация SQL производится в рнтайме (не делается никаких предвычислений), а весь код встроенный в linq-запросы каждый раз компилируется во время выполнения.
3. Ограничения конкретных провайдеров. Так EF не предоставляет некоторую функциональность (хранимые функции, работа с датой и временем и т.п.), а linq2sql не умеет работать с СУБД отличными от MS SQL.
Согласен, что серьезные проблемы, но, на мой взгляд, разумнее устранить их нежели заниматься скрещиванием TSQL, C# и текстовых файлов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Там нет ни одного пункта интересующего мнея. BLToolkit меня интересует так же слабо как твои идеи размещения запросов в отдельных файлах. VD>Лучшим подходом, на мой взгляд, является размещение запросов в виде встроенного (типизированного) DSL внутри кода приложения. Короче говоря подход а-ля linq.
Такой DSL уже есть. Называется TSQL. Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?
VD>Согласен, что серьезные проблемы, но, на мой взгляд, разумнее устранить их нежели заниматься скрещиванием TSQL, C# и текстовых файлов.
Я попробую всё же, ибо пока другого решения я просто не вижу.
Думаю первый же гемор будет давольно скоро (на этих выходных например , ) попробую потом свой опят описать.
PS
linq по многим причинам не подходит как полноценное и всеобьемлющее решения для работы с данными. Пока он не дорос.
Здравствуйте, Tom, Вы писали:
VD>>Причем тут идиоты? Тебя спросили как твой генератор будет себя вести в условиях когда разные запросы возвращают один и тот список полей. Будешь формировать разные типы? В linq — это не проблема. Там все типизровано и будет возвращен или конкретный тип, или анонимный тип. Tom>Будет возвращён конкретный тип или анонимный. В моём варианте и в варианте линка нет разницы. Он так же как и я генерит враперы над хранимками например.
Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных?
Tom>Реальная проблема раз. Поддержка большого количества рукописных resultset классов.
Это чё за зверь? Ты о linq говоришь? В нем большого количества не получается. Получается или класс описывающий таблицу БД, или анонимный тип (а-ка запись).
Tom>Проблема два, в коде есть TSQL.
Ну, дык, вот это конечно не хорошо. С этим и надо бороться.
Tom>Некто его правит и допускает мелкую синтаксическую ошибку.
Не фига было править. Надо выбрасывать и заменять linq-запросами.
Tom>Об этом мы узнаём только когда клиент тыкает на кнопочку.
Это следствие...
Tom>Проблема три. Намечается большой рефакторинг базы, всех стор, таблиц и запросов. Tom>Как быть с тем TSQL который живёт в C# не совсем понятно.
Не допускать такого идиотизма. Типизированный linq-код сам подскажет что и где нужно поменять (при компиляции).
Tom>Тем более непонятно что делать с существующими resultset классами.
Это тоже какой-то пережиток.
Tom>Они должны соответствовать новому дизайну базы.
Дык устрани их и проблем не будет. Есть только две рабочие схемы:
1. Набор классов описывающих сущности БД. Их нужно тупо генерировать по БД.
2. Описание модели данных по которой генерируется (или обновляется) БД и необходимый код.
По любому не должно быть никаких классов которые вручную синхронизируются с БД.
VD>>Убогости вашего проекта? Ты извини, но без обоснования эти слова тяжело применить к linq. Tom>Какой конкретно linq провайдер?
Какой вам больше по душе. Если вы ориентируетесь исключительно на MS SQL Server, то наверно linq2sql — лучший выбор.
Tom>И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?
Из изначально не надо писать на чем попало. Но уж если вы хотите перевести на новые технологии старый проект, то следует сначала провести рефакторинг и заменить весь TSQL на linq.
Tom>>>да и смысла применять мёртвый проект я не вижу. VD>>Применяй EF. Tom>Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?
Ты просто плохо в нем разобрался. Там есть лишнее, но его можно не использовать. Проблемы EF в другом. Он плохо поддерживает функционал конкретной СУБД. Работа с датами, например, там не к черту не годится. Отсюда многие агрегатные запросы могут просто не получиться реализовать.
В общем, вам конечно лучше использовать linq2sql. И не надо о мертвых проектах. Проект который вошел в состав фрэймворка будет поддерживаться по гроб жизни этого фрэймворка. Говорят, что возможно даже его исходники откроют.
Tom>Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.
С LLBGen не знаком. Но если у него есть приемущества, то почему бы и нет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Какой конкретно linq провайдер? И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?
Tom>>>да и смысла применять мёртвый проект я не вижу. VD>>Применяй EF. Tom>Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0? Tom>Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.
Я правильно понимаю, что твои претензии относятся к конкретным провайдерам, а не самому подходу linq в целом?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Какой вам больше по душе. Если вы ориентируетесь исключительно на MS SQL Server, то наверно linq2sql — лучший выбор.
Опять двадцать пять. Этот проект мёртв. Ещё предложения? И что всё таки делать с linq & DML?
Tom>>И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера? VD>Из изначально не надо писать на чем попало. Но уж если вы хотите перевести на новые технологии старый проект, то следует сначала провести рефакторинг и заменить весь TSQL на linq.
Понятно, спасибо. Это на мой взгляд невозможно, и глупо. невозможно потому что linq как ты сам писал не поддерживает DML а глупо потому что от того что масло станет маслянным качество проекта не улучшится.
Tom>>>>да и смысла применять мёртвый проект я не вижу. VD>>>Применяй EF. Tom>>Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?
VD>Ты просто плохо в нем разобрался. Там есть лишнее, но его можно не использовать. Проблемы EF в другом. Он плохо поддерживает функционал конкретной СУБД. Работа с датами, например, там не к черту не годится. Отсюда многие агрегатные запросы могут просто не получиться реализовать.
Кы читал куда они двигаются/развиваются?
VD>В общем, вам конечно лучше использовать linq2sql. И не надо о мертвых проектах. Проект который вошел в состав фрэймворка будет поддерживаться по гроб жизни этого фрэймворка. Говорят, что возможно даже его исходники откроют.
Вот что исходники откроют я верю. Как раз из за проблем поддержки. Что бы спихнуть её на комьюнити. Но без открытия исходников компилятора нормально линк развивать не получится. Тот же DML полностью не реализовать, да и я не представляю сколько для этого понадобится ресурсов.
Tom>>Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.
VD>С LLBGen не знаком. Но если у него есть приемущества, то почему бы и нет?
VD>Я правильно понимаю, что твои претензии относятся к конкретным провайдерам, а не самому подходу linq в целом?
Нет. Сам подход, как ВЕКТОР мне нравится. Не нравится что это очередное недоделанное решение. Опять же возвращаясь к DML.
Я не против использовать линк если будет чётко ясно что;
1. Решение обеспечивает эволюционную модель развития приложения. Переписать всё с нуля — такой подход не работает
2. Я смогу перенести все текущие запросы и linq будет полностью хватать для обработки данных в нашей системе
Но если посмотреть реально на ситуацию то такого не произойдёт в ближайшем будущем.
Ибо, сама идея EF+linq 2 entity не правильная. А linq2sql мёртвая.
Вместо неё M$ надо было заняться обьектной базой и запросами к ней.
Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.
Здравствуйте, Tom, Вы писали:
VD>>Ты бы объяснил, для начала, что ты понимаешь под мощью и под сложными запросами? Лучше всего на базе примеров.
Tom>ну вот поростой и типичный вариант...
ОК, это уже что-то. Теперь пара вопросов...
Кстати, название процедуры совершенно ничего не говорящее. "BvSpCall" мало говорит о сути.
Что же мы видим?
А видим мы совершенно ужасный, монструозный в котором полностью отсутствует декомпозиция.
При этом в linq из всего увиденного не удастся повторить только вставку/удаление в реальные таблицы:
INSERT INTO BvCachedCallsInsert
SELECT #batch.[ID], @SurveySID
FROM #batch
LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = #batch.[ID]
AND ci.SurveySID = @SurveySID
WHERE ci.SurveySID IS NULL
...
DELETE BvPreparedCalls WHERE BatchID = @BatchID
Такой код нужно называть не "сложным запросом", а "плохим кодом".
Даже используя возможности MS SQL можно было бы сделать этот код намного более понятным и легким в поддержке. Все что для этого нужно было сделать — это произвести его декомпозици на хранимые функции и разбить процедуру на ряд под-продцедур (что не просто в следствии кривости TSQL).
С использованием linq произвести декомпозицию было намного проще, так как нет ограничений TSQL-я.
Наличие курсоров вообще порадовало. Отличная демонстрация того как кривой язык подталкивает не очень ответственных (или не опытных) к использованию откровенно кривых решений.
Что касается DML, тут прийдется делать собственное решение или дожидаться когда IT или кто-то другой реализует DML для linq. Пока что можно пользоваться датаконтекстом и модификацией объектов.
А, что у вас все хранимки модифицируют данные в таблицах? Если нет, то какой процент этим занимается?
VD>>Можно поставить вопрос по другому. В чем смысл вместо одного языка (например, C#) использовать два (например, C# + TSQL) и тратить кучу времени на обеспечение их взаимодействия. Tom>Обьясню. Каждый язык имеет область применения. Tom>C# никак не предназначен на сегодняшний день для манипуляции данными. Тем боллее, что серверов БД существует великое множество.
Вы просто не умеете его готовить (с). Пока что ты не продемонстрировал ничего что указывало бы на большую мощность, о которой ты заявлял. Более того ты как раз продемонстрировал запрос который будучи переписанный на linq можно сделать значительно более простым и удобным в поддержке.
Tom>И у каждого свой SQL диалект.
Это было бы аргументом если бы мы обсуждали бы гетерогенное решение, а не код на скрипте конкретной СУБД.
Как раз EF обеспечивает гетерогенность, правда, в ущерб функционалу. А код на конкретном диалекте СУБД-скрипта ее точно не обеспечивает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Такой DSL уже есть. Называется TSQL.
TSQL — это не DSL. У тебя совершенно не верная терминология.
TSQL — это GPPL, т.е. язык программирования общего назначения. На нем можно написать все что можно написать на C# (например). Эти языки одинаково мощны по Тьюрингу.
Вот SQL — это действительно ДСЛ. Только внешний. Linq — это как раз встраивание DSL аналогичного SQL в приличный ООЯ вроде C#.
Проблема TSQL в том, что — это кривой скрипт со встроенной поддержкой действительно мощного диалекта SQL.
Tom>Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?
Принципиально ничего. Но он будет встроен в полноценный язык (и удобный) программирования. Ты получаешь возможность писать весь код приложения на одном языке.
VD>>Согласен, что серьезные проблемы, но, на мой взгляд, разумнее устранить их нежели заниматься скрещиванием TSQL, C# и текстовых файлов. Tom>Я попробую всё же, ибо пока другого решения я просто не вижу.
Кто мы такие чтобы мешать тебе? Пробуй...
Но это же ты пришел к нам и задаешь вопросы, правда? Вот мы тебе и отвечаем, что нам компромиссы подобные описанным тобой не нравятся.
Tom>linq по многим причинам не подходит как полноценное и всеобьемлющее решения для работы с данными. Пока он не дорос.
Это ты уже говорил. И тебе уже отвечали на это. Причем прямо в редыдущем сообщении, напеример. Не сотоит повторяться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T4 используется в самой студии и для того же линка.
