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

VD>>Ё моё! Ты думаешь, что тут все родились с SQL Profiler-ом в анусе и знанием SQL в мозге?
VD>>Прочти пару-тройку статей по выявлению проблем производительности в SQL Server. Потрахайся сам пару-тройку дней и все поймешь. С отладчиком ведь справляешься? Ну, так это не сильно сложнее.

S>Конечно не родились. Но у меня своей работы до одного места.

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

Потрать, в конце концов, свое личное время. Останься пару раз после работы... Найди узкое место и реши проблему.

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

VD>>Первое — не факт. Есть огромный шанс, что производительность системы тоже уменьшится.
G>От тупого переноса всего в ХП вряд ли. Запросы теже самые, параметры тоже.

Запросы будут другие. Linq позволяет строить запросы по частям. Скажем создал базовую часть, а потом добавил к ней фильтрацию. В другом случае добавил другую фильтрацию. При этом будут порождены разные запросы каждый из которых получит оптимальный план и будет закэширован.

Перенести этот подход в хранимки просто так не выйдет. Придется или клепать динамический, параметризованный SQL, что даст примерно ту же производительность, но при этом резко усложнит реализацию. Если же начать использовать разные выверты вроде добавление параметров через OR (с расчетом на то, что не заданные выражения не будут учтены), то план запросов в некоторых случаях может стать очень плохим. Единственное что можно будет сделать — это явно выключить кэширование. А это сразу же приведет к постоянной перекомпиляции запросов. Результат — снижение производительности.

VD>>Компиляция планов не единственный показатель влияющий на производительность сервера БД.
VD>>Учитывая, что планы в linq кэшируются по определению намного важнее смотреть на то насколько оптимальными будут эти планы. Лнин будет генерировать разные запросы для разных сочетаний условий. Это приведет к созданию более точных планов. А вот добиться того же с помощью хранимок не так просто.
G>Насчет Linq2SQL не уверен, а за EF замечал что он незначащие части запроса выкидывать умеет (хотя оптимизатор сиквеля также их выкинет).
G>AFAIK оптимизировать запросы на клиенте — гиблое дело, слишком мало информации и уж очень декларативен SQL.

Я говорил совершенно о другом. Читай внимательнее.
Почти тоже самое я повторил выше.


VD>>Вы будете смеяться, но один из советов по оптимизации сложных хранимых процедур — это сброс кэша запросов при их выполнении. А другой — использование динамической генерации SQL-я. Эти подходы порождают оптимальные планы запросов. Если БД имеет огромный размер, лучший план запроса может оказаться лучшим выбором нежели экономия на компиляции планов выполнения.
G>Это если условия фильтрации могут зависить от параметров.

Если приложение не примитивно, то так оно и будет.

G>Но при тупом переносе запросов в ХП такого не возникнет.

А как ты себе видишь тупой перенос логики динамически собираемого linq-запроса?
Всю логику которую за нас выполняет linq прийдется повторить в хранимках. А это не тривильная задача. Более того — это задача требующая высокой квалификации того кто будет писать хранимки. В итоге как раз может оказаться так, что люди восползуются самыми простыми средствами воде "not x is null or x > 1", что в итоге приведет к дикому падению производительности в следствии выбора плохих планов.

G>У меня по поводу Linq to SQL \ EF обладают офигенным преимуществом. Они в коде программы позволяют строить проекции и накладывать дополнительные фильтры, что может увеличить производительность в разы.

О том и речь.

G>ХП этому мешают.

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

G>В принципе можно делать ХП для каждой выборки, но так мало кто поступает, обычно делают 4 crud процедуры и на этом успокаиваются.

Мне кажется совершенно не реально делать хранимки на все сочетания запросов. Сочетания запросов вызовут комбинаторный взрыв, что сделает невозможным написание кода хранимок вручную. Конечно можно создать некую мета-программу которая сгенерирует код таких хранимок, но это само по себе сложная работа. Да и вся БД будет забита кучей хранимок многие из которых будут вызваться раз в сто лет, а некоторые вообще не будут вызваться.
Тут опять же есть решеие — генерировать хранимки по требованию (в ленивом режиме). Но это еще больше усложнит задачи. А толку — 0.

Так что я бы на месте этой конторы поступил бы так:
1. Выяви бы причину тормозов и устранил бы ее. Это точно не linq.
2. Если проблема в некоторых тяжелых запросах, то их (и только их) я бы вынес в хранимки или оптимизировал бы каким-то другим образом (например, с помощью создания материализованных представлений).
3. Встроил бы в программу подсистему мониторинга производительности которая автоматически выявляла бы узкие места и информировала бы о них админов и разработчиков.

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

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

L>Если запросы отличаются только параметрами, то генерируемый sql будет одним и тем же.

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

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

Более того. Иногда имеет смысл отказаться от кэширования планов (когда разные значения имеют разную релевантность).

В общем, это отнюдь не простой вопрос.

Линк же во многом решает эти проблемы так как генерирует специализированный, но при этом параметризованный SQL. Так что переход на хранимки может вызвать проблемы с производительностью (при упрощенной реализации) и привести к усложнению реализации.

Остается вопрос. Зачем это делать?

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

VD>А замена проверяемого во время компиляции, поддающегося рефакторингу и хранимого в системе контроля версий кода на код хранимый в БД, проверяемый только во время интерпретации и плохо поддающийся рефаторингу — это не усложнение?

А почему он не поддаётся рефакторингу? Для этого есть соотвестствующая студия — Database Edition GDR. Ну если она не устраивает — есть как обычно внещние средства.

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

VD>А как ты себе видишь тупой перенос логики динамически собираемого linq-запроса?
VD>Всю логику которую за нас выполняет linq прийдется повторить в хранимках. А это не тривильная задача. Более того — это задача требующая высокой квалификации того кто будет писать хранимки. В итоге как раз может оказаться так, что люди восползуются самыми простыми средствами воде "not x is null or x > 1", что в итоге приведет к дикому падению производительности в следствии выбора плохих планов.
Я один раз участвоввал в процессе переноса динамически генерируемого SQL в программе.
Саначала тупо делали по 4 продецуры. Когда выяснилось что генерация SQL-кода на сервере и исполнение через execsql работает медленее, то разделили хранимки на несколько, код каждой был статическим, а из программы вызывали нужную в зависимости от сочетания условий.
Потом я эти проектом больше не занимался, но все говорят что быстрее работать стало. Замеров видимо никто не проводил.

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

L>>Если запросы отличаются только параметрами, то генерируемый sql будет одним и тем же.

VD>Читай внимательно выделенное. То что план будет одним и тем же для запроса выбирающего миллион записей и оду — это очень плохо.

Формулировка была не очень удачная. Тут скорее следовало говорить не о "линк .. будет генерировать разные запросы", а что "с помощью линка проще сгенерировать разные запросы". Иначе у чающего может возникнуть впечатление, что линк что-то сам в состоянии сделать.

По порядку.
1) disconnected как бы подразумевает, что мы могём нормально работать с датасорс без соединения к серверу. В случае ef нам приходится писать кэш/modelView ручками. Почитайте беседу с Бен-Ами (товарищ осуществляет поддержку по EF и общается с обществом, эдакий полуофициальный голос ado.net team. Про роль внутри команды не в курсе): (http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/172ae667-d20a-4dbf-9e98-39b90387b4f4/).

Он там говорит, что контекст у них рассматривается как unit of work. Отсюда все грабли. В частности то, что они не собираются делать сериализуемый контекст/change tracking. А проблемы все из-за не совсем разумного решения отделить хранение изменений объекта от него самого. Религия poco, что поделаешь В результате, у нас либо идеологически чистые объекты, которые легко передаются через, скажем, wcf, либо грабли с чанж-трекингом который надо реализовывать целиком и полностью самостоятельно.

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

2) не-не, вы правы что получить схему можно только по первому резалтсету. По большому секрету, есть и ещё более страшные ограничения — если ХП обращается, например к временным таблицам — схему получить низзя. Впрочим страдать от этого имхо глупо. Детально этой байдой не занимался, рассказать как оно работает не смогу.

Здравствуйте, _FRED_!

_FR>И где здесь "из крайности в крайность"? Датасеты не имеют никакого отношения к ORM и ни датасеты ни ORM никак не связаны с "disconnected approach".

Вот если бы они развивали параллельно датасеты и орм и шли бы на сближение/плавную замену — всё было бы в порядке. Дык нет, EF у товарищей — новая унифицированная платформа, и на ней будет жить как минимум oslo, azure, ssds (если оно наконец доживёт до релиза) и acropolis (если его вытащат из инкубатора — слухи ходют ).

Они вон пять лет ленятся добавить поддержку nullable values в дизайнер датасетов — http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataset/thread/2e1c4146-994a-4ebb-b090-fd271aebb880/ (это самый свежий топик). Чтобы добиться от них признания бага в датасете мне пришлось охотицца за саппортом 7 месяцев (на принцип пошёл ). Так что не стоит надеяться на то, что датасеты и дальше будут жить и развиваться.

Датасеты как раз имеют отношение к disconnected approach, точнее к тому, что понималось под partially disconnected applications когда писался первый ado.net. Они собсно и предназначались в первую очередь изображать из себя локальный кэш (и неплохо таки с этим справляются), а сериализация/передача между tiers — это так, рюшечки.

ef, соответственно, задумывался слегка для других вещей, и проблемы, решающиеся элементарно для датасетов (хранение согласованного снимка данных, валидация, биндинг, отсоединённый режим, одновременная работа с любыми провайдерами) там решаются тяжелее или не решаются вообще. Ссылка на обсуждение — в моём ответе Ллойду. В одном из последних постов по ссылке — ссылка на баг у DataView (ListChanged генерится только для первого из созданных к одной таблице DataView).

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

_FR>>И где здесь "из крайности в крайность"? Датасеты не имеют никакого отношения к ORM и ни датасеты ни ORM никак не связаны с "disconnected approach".

S>Вот если бы они развивали параллельно датасеты и орм и шли бы на сближение/плавную замену — всё было бы в порядке. Дык нет, EF у товарищей — новая унифицированная платформа, и на ней будет жить как минимум oslo, azure, ssds (если оно наконец доживёт до релиза) и acropolis (если его вытащат из инкубатора — слухи ходют ).

Все здравомыслящие люди довольно быстро осознали, что с датасетами связываться не стоит Аргументом этому факту является то, что запоследние лет пять на тему того, как здорово пользоваться датасетами не видно ни одной статьи от признаного в своём деле специалиста. Даже наоборот, при желании можно отыскать стотью о торм, почему датасетами пользоваться не нужно…

S>Они вон пять лет ленятся добавить поддержку nullable values в дизайнер датасетов — http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataset/thread/2e1c4146-994a-4ebb-b090-fd271aebb880/ (это самый свежий топик). Чтобы добиться от них признания бага в датасете мне пришлось охотицца за саппортом 7 месяцев (на принцип пошёл ). Так что не стоит надеяться на то, что датасеты и дальше будут жить и развиваться.

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

S>Датасеты как раз имеют отношение к disconnected approach, …
S>ef, соответственно, задумывался слегка для других вещей, …

Я совсем не знаком с EF, но неужели что-то мешает использовать её в отсоединёной моделе? Я не спорю о том, что для чего предназначалось, но не наблюдаю непоследовательности.

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

[....]
VD>А замена проверяемого во время компиляции, поддающегося рефакторингу и хранимого в системе контроля версий кода на код хранимый в БД, проверяемый только во время интерпретации и плохо поддающийся рефаторингу — это не усложнение?


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

во-вторых, нельзя рассматривать процедуру как обычный sql-запрос, процедуры не обязательно выполняют роль для простых ABCD операций только над data-объектами, это и получение репортов, и аудит изменений, да множество на самом деле сценариев вплоть до обслуживания той же базы, с очень сложной логикой, с курсорами, с динамическими скриптами, с получением динамических рекордсетов, когда действительно структура возвращаемого результата зависит от входящих данных, и тут уже ну практически не возможно описать логику средствами linq... нет, можно, но просто усилия будут несопоставимы, то что делается естественным образом средствами t-slq (или средствами любого другого диалекта sql, не обязательно sql server) сейчас по крайней мере очень тяжело вписывается в linq, возможно в будущем ситуация изменится

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

G>Я один раз участвоввал в процессе переноса динамически генерируемого SQL в программе.
G>Саначала тупо делали по 4 продецуры. Когда выяснилось что генерация SQL-кода на сервере и исполнение через execsql работает медленее, то разделили хранимки на несколько, код каждой был статическим, а из программы вызывали нужную в зависимости от сочетания условий.
G>Потом я эти проектом больше не занимался, но все говорят что быстрее работать стало. Замеров видимо никто не проводил.

Когда 4 это нормально, но при увеличении инвариантов запроса мы получаем комбинаторный взрыв либо возврат к execsql.

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

S>По порядку.
S>1) disconnected как бы подразумевает, что мы могём нормально работать с датасорс без соединения к серверу. В случае ef нам приходится писать кэш/modelView ручками. Почитайте беседу с Бен-Ами (товарищ осуществляет поддержку по EF и общается с обществом, эдакий полуофициальный голос ado.net team. Про роль внутри команды не в курсе): (http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/172ae667-d20a-4dbf-9e98-39b90387b4f4/).
На самом деле ничего ручками писать не надо. Все уже написано до нас.

S>Он там говорит, что контекст у них рассматривается как unit of work. Отсюда все грабли. В частности то, что они не собираются делать сериализуемый контекст/change tracking. А проблемы все из-за не совсем разумного решения отделить хранение изменений объекта от него самого. Религия poco, что поделаешь В результате, у нас либо идеологически чистые объекты, которые легко передаются через, скажем, wcf, либо грабли с чанж-трекингом который надо реализовывать целиком и полностью самостоятельно.
Какой-то неправльный вывод. Проблемы как раз из-за недостаточного отделения change-tracking от контекста.

S>Вот и выходит, что без самописного велосипеда ef тяжко применять для передачи сущностей между аппсервером /клиентом (хотя это может и в плюс), так и на тяжёлом клиенте.

ADO.NET Data Services, Entity Bag и Sync Services решают если не все, то подавляющее большентсво проблем.

Дня вам!

_FR>Все здравомыслящие люди довольно быстро осознали, что с датасетами связываться не стоит Аргументом этому факту является то, что запоследние лет пять на тему того, как здорово пользоваться датасетами не видно ни одной статьи от признаного в своём деле специалиста. Даже наоборот, при желании можно отыскать стотью о торм, почему датасетами пользоваться не нужно…

_FR>... Поленились в своё время написать нормальный слой работы с данными, бизнес-логики и представления — мучайтесь с датасетами.

Скажем так, у нас наверно специфика такая, но тем не менее — датасеты вполне себе успешно используются и работают.

Основное применение — локальный кэш/модель данных для десктоп клиента.

Что делает:
1) кэш/согласованный набор данных. Структура обычно нетривиальная, с кучей зависимостей, поэтому проще и выгодней залить набор сразу, чем постоянно дёргать сервер и разруливать грабли с несогласованной информацией
2) локальная валидация изменений. Вам ведь не надо рассказывать чем это хорошо?
3) стандартные интерфейсы для биндинга. Возможность биндинга с разными фильтрами к одним и тем же элементам. Тоже must have.
4) индексы и быстрый поиск. локальная фильтрация/сортировка.
5) out-of-context change-trackiing.
6) Однотипная работа с добавленными/изменёнными/далёнными данными.
7) Изоляция от провайдера/возможность одновременно использовать произвольных провайдеров.

всё это нам реально надо (ну разве что 7 не совсем критично).

Повторюсь — это клиент. Сервера в чистом виде в большинстве случаев нет — доступ идёт к СУБД через прослойку из хранимых процедур/представлений (тоже специфика.

При таком раскладе как-то неудобно говорить, что датасеты отстой или что-то ещё рулит для дескоп-клиента.
Переписывать смысла нет — во-первых мы потеряем кучу времени, во-вторых функционал будет процентов на 90 повторять функционал датасетов. То что нам надо + некоторые мелкие косяки (типа неподдержки nullable) вполне кошерно решаются кастомным шаблоном T4.

Если вы знаете что-то дотнетовское, что удовлетворяет требованиям 1-6 — с радостью посмотрю и ознакомлюсь. EF сюда не подходит.

_FR>Я совсем не знаком с EF, но неужели что-то мешает использовать её в отсоединёной моделе? Я не спорю о том, что для чего предназначалось, но не наблюдаю непоследовательности.

Вам придётся во-первых сделать eager load для всех возможных путей обращения к элементам + убедиться, что контекст разрезолвил дубликаты, полученные по разным связям. Если вы используете ХП, вам приходится добавлять все сущности в контекст ручками (там ещё пара тонокстей — сейчас не вспомню) и заполнять EntitySet/EntityReference у связаннных сущностей. Дальше есть нюансы с удержанием сущности в контексте/его очистке после апдейта и перед заливкой новых данных.
Даже если вы победите эти ограничения — в чистом виде entities не биндятся — см в ссылке на мсдн-ский форум. Дальше вы не можете сделать проверки на изменение элементов в контексте. Плюс хитрые подвыверты на получение original-значений изменённых данных... Это только то, с чем я пытался бороться. Про сложный биндинг с динамической фильтрацией /many-to-many/сложные зависимости молчу.

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

S>Если вы знаете что-то дотнетовское, что удовлетворяет требованиям 1-6 — с радостью посмотрю и ознакомлюсь. EF сюда не подходит.
Очень подходит локальная БД SqlCE + Sync Services + тот же EF для работы с данным из кода.

Здравствуйте, gandjustas.

G>На самом деле ничего ручками писать не надо. Все уже написано до нас.

С этого момента поподробнее. По ссылке что я привёл:

...I do not like binding UIs directly to entities as that often results in code pollution over time. My preference is typically to create a view model for my entities and bind the UI to them instead — that allows me to provide validation and error checking, more robust change notification, can make binding through object graphs much easier, and allows me to format/lazy load/expose properties that may perform some UI-specific transformation...

Либо товарищ чего-то не знает, либо я не смог добиться от него нужного ответа. По его мнению без самописного view model проверок/оповещений об изменениях не будет.

G>Какой-то неправльный вывод. Проблемы как раз из-за недостаточного отделения change-tracking от контекста.

Сорри если невнятно написал. В EF чанж-трекинг живёт в контексте, entity — практически POCO и изменений внутри себя не хранит. В результате в плюсах — лёгкая сериализация entities как они есть, в минусах — отсутствие стандартного механизма сериализации изменений. Так что да, проблемы как раз из-за недостаточного отделения change-tracking от контекста.

G>ADO.NET Data Services, Entity Bag и Sync Services решают если не все, то подавляющее большентсво проблем.

Сейчас мы вроде беседуем о EF как DAL для десктоп-клиента, нет? Заводить middleware и переводить всё на rest только из-за особенностей клиентского фреймворка неразумно получится. Sync Services во-первых не работают напрямую с EF — у нас получается ef + sql compact + sync services. Во-вторых они накладывают определённые ограничения на схемы данных и требуют прямого доступа к таблицам — не для всех клиентов такое подходит.

В общем как-то отдаёт костылями, не согласны?

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

S>Здравствуйте, gandjustas.

G>>На самом деле ничего ручками писать не надо. Все уже написано до нас.

S>С этого момента поподробнее. По ссылке что я привёл:
S>

S>...I do not like binding UIs directly to entities as that often results in code pollution over time. My preference is typically to create a view model for my entities and bind the UI to them instead — that allows me to provide validation and error checking, more robust change notification, can make binding through object graphs much easier, and allows me to format/lazy load/expose properties that may perform some UI-specific transformation...

S>Либо товарищ чего-то не знает, либо я не смог добиться от него нужного ответа. По его мнению без самописного view model проверок/оповещений об изменениях не будет.
Смотрю сгенерированные EF классы — оповещения будут.
Для работы с графами объектов в UI я бы тоже рекомендовал viewmodel создавать.

G>>ADO.NET Data Services, Entity Bag и Sync Services решают если не все, то подавляющее большентсво проблем.

S>Сейчас мы вроде беседуем о EF как DAL для десктоп-клиента, нет? Заводить middleware и переводить всё на rest только из-за особенностей клиентского фреймворка неразумно получится. Sync Services во-первых не работают напрямую с EF — у нас получается ef + sql compact + sync services. Во-вторых они накладывают определённые ограничения на схемы данных и требуют прямого доступа к таблицам — не для всех клиентов такое подходит.
Ну если рассматривать только десктоп-клиент с непосредственным доступом в базу, то вооще зачем нужен disconnected режим?
Если многозвенное приложение, то рецепт я привел выше.

S>В общем как-то отдаёт костылями, не согласны?
Многие решения по работе с данными отдают костылями.

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

_FR>Все здравомыслящие люди довольно быстро осознали, что с датасетами связываться не стоит

На мой взгляд датасэты — это хорошая идея опошленная плохой реализацией.

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

_FR>> То что нам надо + некоторые мелкие косяки (типа неподдержки nullable) вполне кошерно решаются кастомным шаблоном T4.

Не могли бы Вы привести ссылку на то как это можно реализовать.

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

DШ>Здравствуйте, VladD2, Вы писали:

DШ>[....]
VD>>А замена проверяемого во время компиляции, поддающегося рефакторингу и хранимого в системе контроля версий кода на код хранимый в БД, проверяемый только во время интерпретации и плохо поддающийся рефаторингу — это не усложнение?

DШ>проверка на этапе компиляции огромный плюс тут спорить не о чем...но никто же не мешает проверять типы, структуру, отвалилдировать схему xml входимых получаемых данных со стороны процедуры.

Офтопик: Мне кажется более точно будет говорить не "отвалилдировать", а "вывалидировать". Это более точно отражает суть процесса .

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

В любом случае это будет только небольшой дополнительный контроль. Сами хранимки ведь от этого не станут надежнее. Их будет так же трудно писать как и раньше.

В общем, с точки зрения удобства разработки и качества кода подход с linq на мой взгляд предпочтительнее.

DШ>во-вторых, нельзя рассматривать процедуру как обычный sql-запрос, процедуры не обязательно выполняют роль для простых ABCD операций только над data-объектами, это и получение репортов, и аудит изменений, да множество на самом деле сценариев вплоть до обслуживания той же базы, с очень сложной логикой...

Вот именно и негоже писать такой сложный код на совершенно уродском языке вроде T-SQL или PL-SQL.
Но опять же это попытка подменить тему обсуждения. Речь шла о переносе linq-запросов в хранимки с целью устранения компиляции. Не надо забывать об этом.

DШ>с курсорами, с динамическими скриптами,

Вот, вот. С курсорами. Более дебельной реализации я и придумать не могу. Императивная обработка на уродском скриптовом языке, да еще и с ручным контролем ресурсов. Хуже только С++. Но С++ хоть скорость дает. А T-SQL кроме багов что дает?

DШ>с получением динамических рекордсетов,

Ага. Только почему бы не получать их с помощь тех самых linq-запросов? Ведь динамические запросы в T-SQL — это очень не удобно и убого.

DШ>когда действительно структура возвращаемого результата зависит от входящих данных,

Ага, ага. Но если речь о динамических запросах, то причем тут экономия на компиляции планов? Или хочется дикого замедления работы БД в будущем спровоцированного выбором плохого плана?

DШ>и тут уже ну практически не возможно описать логику средствами linq...

Ты уверен, что подумал прежде чем это сказал?
Заявление мягко говоря ламерское.

DШ> нет, можно, но просто усилия будут несопоставимы,

А, ну, то есть ты и сам понимаешь, что фигню спорол?
Тогда поясни, что же за страшные усиля вдруг появляются?
Не уж то наличие полноценных коллекций, компилируемого языка, отладчика, IDE, проверки во время компиляции — это не преимущества, а недостатки?

DШ>то что делается естественным образом средствами t-slq (или средствами любого другого диалекта sql, не обязательно sql server) сейчас по крайней мере очень тяжело вписывается в linq, возможно в будущем ситуация изменится

T-SQL — это уродский язык рожденный по недомыслию. Все что в нем есть хорошего — это SQL. Остальное — это совершенно дебильные дизайнерские решения 70-ых годов плохо замешанные в недоязык. В языке даже нет списков или массивов! Что еще можно о нем сказать? Ну, разве что в нем нужно явно уничтожать те самые курсоры.

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

А>Сам я сторонник Linq, но тут вы отстали от жизни.
А>В Visual Studio есть тип проекта для базы данных SQL Server.

Я этим убожеством пользоваться так и не смог. Слишком много неудобств.

А>Поддерживается контроль версий, проверка во время компиляции и в какой-то мере рефакторинг.

Какой компиляции? Вот с linq-ом я набираю запрос и вижу список ошибок.
А что происходит при изменении TSQL-кода?
А что на счет динамического SQL который в TSQL не редко появляется и почти не нужен в случае linq.

Что до контроля версий, то лично я предпочитаю SVN. Как это чудо с ним скрестить?