LeonidВозвращаясь к теме, я вот не пойму, что вы держитесь за T-SQL как надстройку? Чем лучше этот "клей" между SQL операторами, чем полнофункциональный язык, не пойму?

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

LeonidЯ не со стороны рассуждаю. Мне очень часто приходится писать на T-SQL большие процедуры и я, поверте, знаю что говорю.
А я не со стороны могу заявить, что процедуры не могут быть сильно большими, как не могут быть сильно вложенными, с большим кол-вом переменных, циклов или переменных. Если это наблюдается, значит проблемы в проектировании БД.

авторНет стандарта на T-SQL так же как нет стандарта на PL/SQL и другие диалекты. Зато есть худо-бедно стандарт на сам SQL и его-то и нужно придерживаться производителям SQL серверов.
Что будем брать за стандарт - SELECT, INSERT, UPDATE, DELETE ? Долой рекурсивные запросы, долой времянки, долой триггера, ХП и т.д., так как у каждой РСУБД это свое ? Может тогда и долой транзакции, чтобы не путаться между блокировочниками, версионниками и особенностями их реализаций для каждой СУБД ?

LeonidСкажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?.
В случае с Yukon и .NET-языка, мне достаточно написать эту ф-цию один раз и работать она будет быстрее, что существенно, если я захочу запихать ее в SELECT.
Скажем так - сумма прописью обычно реализуется на клиентском приложении и сие я могу только назвать извратом (без обид) :)

Я никогда и не утверждал, что это не нужно. Мы вроде как начали с того, что для начала было бы неплохо довести до ума то, что есть в MSSQL, а потом уже заниматься его расширением и интеграцией с другими продуктами ? И передергиваю не я, так как мой комментарий шел к Вашему высказыванию по поводу "Ну его TSQL, на C# писать выгоднее". Плохо, когда производитель ПО мечеться из стороны в сторону, периодически устраивая у себя революции, именно по этой причине я не люблю работать с продукцией MS и Borland, хотя "любить" и "работать" конечно же разные понятия.

авторГораздо более интересна перспектива более простого создания бизнес логики прямо на сервере.
Как я уже говорил выше, это вроде и сейчас возможно во многих РСУБД на Java, поэтому в встраивании такой возможности в MSSQL в 2005 году (если у MS опять накладок не случится) поводом восторгаться и радоваться не вижу, тем более утверждать насчет весомых аргументов над Ораклом.

Хотелось бы увидеть практический пример реализации хотя бы примитивной бизнес-логики: код на TSQL и аналогичный код на C#, где сразу бы в глаза бросались преимущества последнего. А пока рассуждения идут в пользу бедных, если бы да кабы :)

MSDN - пример что C# хорошая замена TSQL:
Это у нас на C#:

А это на TSQL:
Ну надо же - по кол-ву и читабельности кода почти то же самое. Разве что в версии ХП C# еще CLR нужно не кисло знать в плане правильной работы с MSSQL. А давайте попробуем посмотреть, не смухлевали ли в MSDN и напишем свою версию процедуры:
Гм, что то тут не так. Можно сказать, что в TSQL не всегда так выкрутиться можно ? Угу, можно. Зато в ASA WatcomSQL и выкручиваться не надо. Берем первый попавшийся пример из BOL - в данном случае демонстирующий организацию нарастающих сумм в запросах через OLAP функции:
а вот и результат:
dept_idemp_lnamestart_datesalarySum_Salary100'Whitney''1984-08-28'45700.00045700.000100'Cobb''1985-01-01'62000.000107700.000100'Shishov''1986-06-07'72995.000180695.000100'Driscoll''1986-07-01'48023.690228718.690100'Guevara''1986-10-14'42998.000271716.690100'Wang''1988-09-29'68400.000340116.690100'Soo''1990-07-31'39075.000379191.690100'Diaz''1990-08-19'54900.000434091.690200'Overbey''1987-02-19'39300.00039300.000200'Martel''1989-10-16'55700.00095000.000200'Savarino''1989-11-07'72300.000167300.000200'Clark''1990-07-21'45000.000212300.000200'Goggin''1990-08-05'37900.000250200.000
Гм - тут ни курсоров, ни циклов, ни переменных, а ведь поди считаются нарастающие по каждой указанной группе. Вопрос на засыпку - а будет ли код на C# выглядеть так же эффективно, как этот запрос ? А не легче ли это было встроить в TSQL и не навязывать людям .NET ?

www.fun4me.narod.ruВот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?
Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc". Исходя из этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного. С моей точки зрения для MS , которая специально в те же UDF ввела множество ограничений для борьбы с велосипедистами в MSSQL 2000, такая смена политики выглядит довольно странно.

LeonidНу, во-первых, вам ни кто ни чего не навязывает. Так же как и java в ORACLE. Не изображайте из себя несчастного обманутого потребителя. Будете вы пользоваться этим или нет - это ваше дело.
Да без проблем. Только не надо тут это тогда превозносить, как этакое новое чудо от MS.

LeonidКстати, к слову, пример для ASA WatcomSQL куда менее читабелен, чем трюк на MSSQL и даже его менее эффективный аналог на C#.
К слову сказать если внимательно прочитать в том приведенном примере, то окажется, что это не аналог "трюка на MSSQL", а пример, демонстрирующий более сложные приемы использования запросов, которые на текущий момент просто в MSSQL недоступны. Так что прежде чем меня обвинять в повсевместной глупости потрудитесь внимательно читать то, что Вам пишут.

Leonid www.fun4me.narod.ruВот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?Знаете, надо еще разобраться, кто есть скриптописатель? Программист на С/C++/C#/Delphi или T-SQL/PL-SQL ;)
Однозначко кодеры и есть скриптописатели, после "мук творчества" которых частенько волосы встают дыбом, когда глядишь на их код в БД.

LeonidГлупость какая... А еще напишите сюда про толпы мрачных T-SQL программистов, оставшихся без работы, потому что все теперь можно реализовать на C#. ;)
Да нет - толпы еще более мрачных, чем ранее DBA, которым ранее приходилось встречаться только с кривыми реализациями на TSQL, а теперь они в придачу получат C# и VB.NET (были цветочки, станут ягодки).

LeonidКривость БД не пропорциональна заложенным в сервер возможностям. В таком случае, самые кривые решения должны быть на ORACLE ;)
Угадали - именно так и есть, самые кривые и вгоняющие в обморок решения я видел именно на Оракле, что и говорит о его многофункциональности и последствиях излишне любящих творчество.

LeonidЯ, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится.
Вот про такие мысли я и говорил. Вы случайно не заметили разницу между назначением хранимой процедуры на C# для MSSQL и парадигмой 3-его звена ?

P.S. А вообще не понимаю, чего так горячиться и обвинять других в глупости ? Неужели Вы думаете, что я настолько туп и недальновиден, что не вижу выгод при использовании ООП языков в БД ? В данном случае мне не интересны преимущества, их и так понимает любой граммотный проектировщик БД, мне гораздо интереснее последствия :)