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

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

Tom>А почему он не поддаётся рефакторингу?

Tom>Автоматическому рефакторингу.

Tom>Для этого есть соотвестствующая студия — Database Edition GDR. Ну если она не устраивает — есть как обычно внещние средства.

Что это чудо умеет и где его брать?

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

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

Формулировка была нормальная. Просто у тебя настоящий талант понимать все так как автор даже планировать не могу. Ну, да я кажется уже привык.

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

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

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

Tom>>А почему он не поддаётся рефакторингу?

Tom>>Автоматическому рефакторингу.

Tom>>Для этого есть соотвестствующая студия — Database Edition GDR. Ну если она не устраивает — есть как обычно внещние средства.

VD>Что это чудо умеет и где его брать?

Ответы на все вопросы лежат не далее трех ссылок в гугле по соответвующему запросы.

Не стоит так скептически отностится к Database Edition GDR, он реально крут, но для написания логики в SQL ничего не дает

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

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

Вы просто не умеете готовить динамические запросы. Нужно просто понимать одну простую вещь. MS SQL кэширует планы к запросам очень тупо. Если описывать это упрощенно, то у него есть одна хэш-таблица ключом которой является текст запроса (так как он был передан на сервер), а значением — план.

Так вот генерируя динамически запросы от вас требуется делать так, чтобы они были одинаковыми. Для этого нужно использовать параметризованные запросы. А это, в свою очередь, ставит крест на использовании EXEC для их выполнения и заставляет выполнять запросы через sp_execute.

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

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

G>Ответы на все вопросы лежат не далее трех ссылок в гугле по соответвующему запросы.

G>Не стоит так скептически отностится к Database Edition GDR, он реально крут, но для написания логики в SQL ничего не дает

Первый абзац противоречит второму.

Мы ведь говорим о написании, тестировании и сопровождении кода, не так ли?
А раз так, то комплексное решение будет по любому лучше чем лотание дыр по мелочи.

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

_FR>>Все здравомыслящие люди довольно быстро осознали, что с датасетами связываться не стоит
VD>На мой взгляд датасэты — это хорошая идея опошленная плохой реализацией.

Какая именно идея в них хороша и что в реализации подкачало?

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

_FR>>>Все здравомыслящие люди довольно быстро осознали, что с датасетами связываться не стоит
VD>>На мой взгляд датасэты — это хорошая идея опошленная плохой реализацией.

_FR>Какая именно идея в них хороша и что в реализации подкачало?

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

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

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

VD>Какой компиляции? Вот с linq-ом я набираю запрос и вижу список ошибок.
И там тоже самое — вводите несуществующее поле из таблицы — получаете список ошибок.

VD>А что происходит при изменении TSQL-кода?
Проверка на синтакис, естественно.
Проект точно также можно собрать, только выходным файлом будет не .EXE, .SQL
Если в коде есть ошибки, то проект не соберется.

VD>А что на счет динамического SQL который в TSQL не редко появляется и почти не нужен в случае linq.
Эээ, но динамический Linq запрос тоже можно загнать в строку и исполнять во время выполнения программы.
Естественно, Visual Studio не будет проверять синтаксис в строке.

VD>Что до контроля версий, то лично я предпочитаю SVN. Как это чудо с ним скрестить?
Также как проекты на C#, VB и т.д.

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

А>Проверка на синтакис, естественно.

А если ошибка не в синтаксисе? Скажем где-то ошибка в типах данных?
Сам SQL Server не делает никаких проверок до выполнения процедуры. Не уж-то интеграция их делает лучше сервера?

VD>>А что на счет динамического SQL который в TSQL не редко появляется и почти не нужен в случае linq.
А>Эээ, но динамический Linq запрос тоже можно загнать в строку и исполнять во время выполнения программы.

Это не так просто. И, главное, этого просто не надо делать. Линковские запросы отлично дополняются и изменяются будучи статически типизированными.

А>Естественно, Visual Studio не будет проверять синтаксис в строке.

И где же преимущества? В лике я имею проверки во время компиляции и гибкость которую в TSQL может дать только динамическая генерация кода.

VD>>Что до контроля версий, то лично я предпочитаю SVN. Как это чудо с ним скрестить?
А>Также как проекты на C#, VB и т.д.

Проекты C#, VB и т.д. — это текстовые файлы. А вот хранимки имеют дурацкую особенность храниться в сервере. И их можно править прямо там.

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

_FR>>>>Все здравомыслящие люди довольно быстро осознали, что с датасетами связываться не стоит
VD>>>На мой взгляд датасэты — это хорошая идея опошленная плохой реализацией.

_FR>>Какая именно идея в них хороша и что в реализации подкачало?

VD>Основная — материализация реляционных данных

Что ты понимаешь под "материализация"? Представление в пользовательском коде?

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

Как на счёт других функцианальных возможностей, которые предоставляет датасет? Индексы? View? Биндинг? Сериализация (бинарная и xml)? Они нужны?

VD>Плохо, то что они не типизированные, типизированные обертки слишком кривые (во всю нарушают принципы инкапсуляции).

Ага, что примечательно, с каждой новой версией фреймворка типизированные обёртки понемногу меняются: добавляются новые, недоступные ранее ранее, возможности

А>>Естественно, Visual Studio не будет проверять синтаксис в строке.
VD>И где же преимущества? В лике я имею проверки во время компиляции и гибкость которую в TSQL может дать только динамическая генерация кода.
Влад, у нас есть такие запросы огромные что их будет очень тяжело переписать на linq2sql. И ты не учитываешь что существует легаси код, с большим количеством стор.
Тем более мне обсолютно непонятен linq2sql roadmap.

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

А>>В Visual Studio есть тип проекта для базы данных SQL Server.

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

А что с ним не так?

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

_FR>Что ты понимаешь под "материализация"? Представление в пользовательском коде?

Копирование всех данных и обрубание какой-бы то ни было связи.

_FR>Как на счёт других функцианальных возможностей, которые предоставляет датасет? Индексы? View? Биндинг? Сериализация (бинарная и xml)? Они нужны?

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

_FR>Ага, что примечательно, с каждой новой версией фреймворка типизированные обёртки понемногу меняются: добавляются новые, недоступные ранее ранее, возможности

Я бы на их месте придумал что-то вроде датасетов связанных с линком. Так чтобы внутри хранились типизированные объекты (возможно анонимные типы), но при этом были все перечисленные возможности.

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

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

L>А что с ним не так?

Проще спросить "что так?". Я поставил точку прерывания и попытался отладить хранимку. Получил набор дерганий после чего хранимка выполнилась до конца, то пошагово я ее так пройти и не смог.

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

VD>А если ошибка не в синтаксисе? Скажем где-то ошибка в типах данных?
Ну это пока вторая версия интеграции.
Ловит синтаксис и ошибки в названиях полей, таблиц, процедур.
К третьей версии может и Warning на не тот тип прикрутят.
Хотя надо понимать, что SET @Integer_Variable = '123' спокойно проходит в T-SQL.

VD>Сам SQL Server не делает никаких проверок до выполнения процедуры. Не уж-то интеграция их делает лучше сервера?
Ну а что такого? Наверное на C# или VB.NET её и написали, что дало больше возможностей.

VD>Это не так просто. И, главное, этого просто не надо делать. Линковские запросы отлично дополняются и изменяются будучи статически типизированными.
Да-да, я сам сторонник Linq'а.
Но и в SQL есть возможности для дополнений и изменений без генерации динамического SQL.
Ну конечно эти возможности не такие широкие как в Linq.

VD>И где же преимущества? В лике я имею проверки во время компиляции и гибкость которую в TSQL может дать только динамическая генерация кода.
Эээ, кажется я упоминал, что я сам сторонник Linq'а?
Поэтому не надо меня агитировать за него.
Я к тому, что и T-SQL + Visual Studio весьма не плох.
Как раз потому, что проверка во время компиляции есть и в T-SQL.

VD>Проекты C#, VB и т.д. — это текстовые файлы. А вот хранимки имеют дурацкую особенность храниться в сервере. И их можно править прямо там.
И проект базы данных тоже текстовый файл.
А хранимая процедура это не проект, а файл в проекте.
Также как файл с описанием класса на C#, VB.NET и т.д.
И полученный из них EXE файл, тоже можно поправить разнообразными редакторами IL кода, также как и процедуру на сервере. А можно текст хранимой процедуры зашифровать, тогда поправить его руками недоброжелателей не удасться. Ну и можно просто права на правку недоброжелателям не давать.

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

А>Хотя надо понимать, что SET @Integer_Variable = '123' спокойно проходит в T-SQL.

Это по-твоему хорошо?

VD>>Сам SQL Server не делает никаких проверок до выполнения процедуры. Не уж-то интеграция их делает лучше сервера?
А>Ну а что такого? Наверное на C# или VB.NET её и написали, что дало больше возможностей.

Такого конечно ничего. Ну, хранимка глючная в БД. Мелочи...
Это ведь лучше чем линг?

VD>>Это не так просто. И, главное, этого просто не надо делать. Линковские запросы отлично дополняются и изменяются будучи статически типизированными.
А>Да-да, я сам сторонник Linq'а.
А>Но и в SQL есть возможности для дополнений и изменений без генерации динамического SQL.

Есть. Но очень убогие и в конечном итоге они приведут к плохим планам запросов. Причины я тут уже 10 раз объяснил.

А>Ну конечно эти возможности не такие широкие как в Linq.

Ну, а зачем тогда все в хранимки переписывать?

Смотри что получается.
1. Усложняем себе жизнь.
2. Создаем фронт работ на ровном месте.
3. Снижаем надежность системы.

И ради чего все это? Даже не ради ручных оптимизаций, а ради компилированности планов запросов которые и так отлично компилируются.

А>Я к тому, что и T-SQL + Visual Studio весьма не плох.
А>Как раз потому, что проверка во время компиляции есть и в T-SQL.

Вроде бы ты сам сказал, что не полная проверка. В общем, это хорошо конечно что что-то сделали для поддержки TSQL. Но сам TSQL это еще то дерьмо. И я бы постарался с ним связываться по реже. Только в случае крайней необходимости.

А>И проект базы данных тоже текстовый файл.

Да ну? А данные тоже в тексте хранить будем?

А>А хранимая процедура это не проект, а файл в проекте.
А>Также как файл с описанием класса на C#, VB.NET и т.д.
А>И полученный из них EXE файл, тоже можно поправить разнообразными редакторами IL кода, также как и процедуру на сервере. А можно текст хранимой процедуры зашифровать, тогда поправить его руками недоброжелателей не удасться. Ну и можно просто права на правку недоброжелателям не давать.

Хранимку совершенно естественно править из БД. И это часто делают на практике. А часто ли ты правил сборки?

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

А>>Хотя надо понимать, что SET @Integer_Variable = '123' спокойно проходит в T-SQL.

VD>Это по-твоему хорошо?
По-моему это может усложнить проверку типа во время компиляции.

VD>>>Сам SQL Server не делает никаких проверок до выполнения процедуры. Не уж-то интеграция их делает лучше сервера?
А>>Ну а что такого? Наверное на C# или VB.NET её и написали, что дало больше возможностей.

VD>Такого конечно ничего.
Ну а что такого, относится к удивлению, что интеграция лучше сервера в чем-то.

VD>Это ведь лучше чем линг?
Чем интересно? Проект базы данных и Linq вещи достаточно ортогональные.
Вот у меня в текущем проекте и проект базы данных и Linq.
Все хранится в системе контроля версий, при переименовании колонки, выдаются подсказки, где эта колонка использовалась.
Есть и Unit-тесты на базу данных.
База данных может развертываться и для разработчика, и для тестировщика и для заказчика.
И большая часть этого именно благодаря проекту баз данных. А Linq работает непосредственно в приложении.

VD>Есть. Но очень убогие и в конечном итоге они приведут к плохим планам запросов. Причины я тут уже 10 раз объяснил.
Сомнительно, что все настолько ужасно. Но не будем углубляться.

VD>Ну, а зачем тогда все в хранимки переписывать?
Действительно зачем? Сколько раз мне надо еще написать что я сторонник Linq?
Собственно, у меня в текущем проекте всего около пяти хранимых процедур. На 40 таблиц.

VD>Смотри что получается.
VD>1. Усложняем себе жизнь.
Облегчаем себе жизнь.
VD>2. Создаем фронт работ на ровном месте.
Уменьшаем количество работы.
VD>3. Снижаем надежность системы.
Увеличиваем легкость развертывания и совместной работы нескольких разработчиков.

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

VD>Вроде бы ты сам сказал, что не полная проверка. В общем, это хорошо конечно что что-то сделали для поддержки TSQL. Но сам TSQL это еще то дерьмо. И я бы постарался с ним связываться по реже. Только в случае крайней необходимости.

Ладно, чувствую надо уже начинать защищать T-SQL.

У него огромное преимущество — он проще чем С# или VB.NET.

Тестировщика со знанием SQL найти или быстро обучить не сложно.
А со знанием C# или VB.NET тяжело сделать тестировщиком.

Бизнес-аналитики тоже часто знакомы с SQL по роду своей деятельности.
Я уж молчу про сторону заказчика.

VD>Да ну? А данные тоже в тексте хранить будем?
Что мешает хранить справочные данные именно в текстовом файле. INSERT INTO Table(Name) VALUES('')
Да собственно можно и в XML, и MDB, и XLS.
И заполнять из них таблицы при развертывании.
У текстовых данных преимущество, что можно отслеживать изменения в системе контроля версий.

VD>Хранимку совершенно естественно править из БД. И это часто делают на практике. А часто ли ты правил сборки?
Хранимку естественно править из Visual Studio, также как и класс на C# или VB.
Потом компиляция и развертывание на тестовый сервер приложений для прогона Unit-тестов.

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

А>>>Хотя надо понимать, что SET @Integer_Variable = '123' спокойно проходит в T-SQL.
VD>>Это по-твоему хорошо?
А>По-моему это может усложнить проверку типа во время компиляции.

Проверку это только упростит. А вот надежность кода понизит.

А>Ну а что такого, относится к удивлению, что интеграция лучше сервера в чем-то.

Я еще не видел, чтобы интеграция работала лучше компилятора. У него и времени больше, и проблем меньше.

А>Все хранится в системе контроля версий, при переименовании колонки, выдаются подсказки, где эта колонка использовалась.

Лучше бы чтобы все автоматом менялось.

А>Есть и Unit-тесты на базу данных.

Гы. Любимый аргумент любителей скриптов. "А у нас юнит-тесты есть".
Есть такой анекдот:
— А у нас есть свобода!
— А у нас Леонид Ильич Брежнев!
— А у нас есть колбаса!
— А у нас Леонид Ильич Брежнев!
— А мы у вас его украдем!
— Тогда и у вас колбасы не будет.

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

S>В общем будем вызывать специалиста. Кстати, нет никого желающего? Мы находимся в Миссиссаге, Онтарио, Канада.

Я рядом совсем — в Киченере. Свистите, если уж совсем туго будет — чем сможем — поможем

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

VD>Я бы на их месте придумал что-то вроде датасетов связанных с линком.

На выборку данных эти оба великолепно спариваются.
Из IQueryable получаем IDbCommand, из IDbCommand — IDbDataReader, а последним заполняем DataTable.