Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
 Re: Весомый плюс Юкон над ORACLE  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 Yo!

Вы должны быть очччень хорошим папой
9 дек 04, 16:40    [1171114]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
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.

Скажем так - сумма прописью обычно реализуется на клиентском приложении и сие я могу только назвать извратом (без обид) :)
9 дек 04, 16:47    [1171156]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
gardenman
Member

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

на SQL, это дело можно реализовать так, чтобы работало достаточно производитльно. Плавал я в этих морях, знаю о чем говорю. Хотя это только часть задачи. Есть еще и валюты, и их склонения должны быть в этом случае написаны правильно. Типа одна тысяча пятьсот долларов 50 центов ) еще и справочник валют нужен...)) а справочник - это табличка в базе данных...
9 дек 04, 17:10    [1171275]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
ASCRUS
Это "клей" позволяет Вам быстро и эффективно реализовывать бизнес-логику в БД, где вся бизнес-логика - это цепь операций с множествами. Чем "полнофункциональный" язык будет выгодней в данном плане я лично не понимаю.
Да тем и будет выгоднее, что он полнофункциональный и операции с множествами ни куда не пропадут.

ASCRUS
А я не со стороны могу заявить, что процедуры не могут быть сильно большими, как не могут быть сильно вложенными, с большим кол-вом переменных, циклов или переменных. Если это наблюдается, значит проблемы в проектировании БД.
Давайте не будем про проблемы в проектировании, а? Вы что думаете, кроме Вас здесь все дураки собрались (без обид). Еще какие могут быть большие и со сложной логикой. Пример - построение сложных отчетов.

ASCRUS
Что будем брать за стандарт - SELECT, INSERT, UPDATE, DELETE ? Долой рекурсивные запросы, долой времянки, долой триггера, ХП и т.д., так как у каждой РСУБД это свое ? Может тогда и долой транзакции, чтобы не путаться между блокировочниками, версионниками и особенностями их реализаций для каждой СУБД?
Ну почему долой? Почему?! Ни кто их у Вас не отбирает. Не передергивайте, пожалуйста! Вам просто заменяют "клей" на более универсальный. Хотите, пользуйтесь старым "клеем". Вы бы почитали сначала статьи от самого MS на сайте MSDN по поводу как это будет в Yukon, а потом бы уже кричали, что вам из этого нужно/не нужно. А то я боюсь, вы имеете поверхностное представление.

ASCRUS
Скажем так - сумма прописью обычно реализуется на клиентском приложении и сие я могу только назвать извратом (без обид) :)
Представте себе, существуют системы на SQL серверах, которые могут выполнять многие действия как то, например, подготовку отчетности и вывод ее и без "клиента" и это не такой уж изврат, поверте.

Это лишь частный, может и не лучший, пример интеграции полнофункционального языка в SQL. Гораздо более интересна перспектива более простого создания бизнес логики прямо на сервере.
9 дек 04, 17:18    [1171313]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

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

автор
Гораздо более интересна перспектива более простого создания бизнес логики прямо на сервере.

Как я уже говорил выше, это вроде и сейчас возможно во многих РСУБД на Java, поэтому в встраивании такой возможности в MSSQL в 2005 году (если у MS опять накладок не случится) поводом восторгаться и радоваться не вижу, тем более утверждать насчет весомых аргументов над Ораклом.
9 дек 04, 17:39    [1171399]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Leonid
Member [заблокирован]

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

Да, мне как разработчику выгоднее.
Ну доведут они до ума T-SQL и что? Мне как разработчику все равно придется помнить кроме SQL, его к тому времени раздутую вплоть до ООП Transact-составляющую, а при переходе на ORACLE его раздутую PL-составляющую.

Хороший пример с VB, который сейчас лицензируют все кому не лень, и правильно делают. Те же Corel, AutoDesk встраивают в свои продукты поддержку VB в качестве "клея" - очень удобно для унифицированного скрипто-писания под Win.

ORACLE, кстати, на сколько мне известно, тоже будет поддерживать .NET
Возможно, правда, не так хорошо и тесно, как MSSQL.
9 дек 04, 17:56    [1171460]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Нету стандарта SQL, нету. Нечего придерживаться. Т.е. стандарт-то есть, но ограничиваясь только им ничего не напишешь.
Короче, идея писать на бейсике, пользуясь только "стандартной частью" TSQL абсолютно утопична.
9 дек 04, 18:05    [1171504]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
MasterZiv
Нету стандарта SQL, нету. Нечего придерживаться. Т.е. стандарт-то есть, но ограничиваясь только им ничего не напишешь.

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

MasterZiv
Короче, идея писать на бейсике, пользуясь только "стандартной частью" TSQL абсолютно утопична.

Да никто и не предлагает писать на "стандартной части" TSQL склеивая это бейсиком. Просто большую часть Transact-составляющей можно перенести на плечи .NET, а не развивать параллельно по сути еще один язык.
9 дек 04, 18:17    [1171548]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Хотелось бы увидеть практический пример реализации хотя бы примитивной бизнес-логики: код на TSQL и аналогичный код на C#, где сразу бы в глаза бросались преимущества последнего. А пока рассуждения идут в пользу бедных, если бы да кабы :)
9 дек 04, 18:56    [1171702]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
MSDN - пример что C# хорошая замена TSQL:
Это у нас на C#:
[SqlProcedure]
   public static void Product(out SqlInt32 value)
   {
      SqlCommand cmd = SqlContext.GetCommand();
      cmd.CommandText = "select intcolumn from tbl";
      SqlDataReader r = cmd.ExecuteReader();
      bool first = true;
      using (r) 
      {
         while (r.Read()) //skip to the next row
         {
            if (first)
            {
               value = r.GetSqlInt32(0);
               first = false;
            }
            else
            {
               value *= r.GetSqlInt32(0);
            }
         }
      }
   }

А это на TSQL:
create procedure TSQL_ProductProc (@product int output)
as
begin
   declare @sales int
   declare c insensitive cursor for select intcolumn from tbl
   open c
   fetch next from c into @sales
   
   if @@FETCH_STATUS = 0  
   set @product = @sales  
   
   while @@FETCH_STATUS = 0
   begin
   fetch next from c into @sales
   set @product = @product * @sales
   end
   
   close c
   deallocate c
end
Ну надо же - по кол-ву и читабельности кода почти то же самое. Разве что в версии ХП C# еще CLR нужно не кисло знать в плане правильной работы с MSSQL. А давайте попробуем посмотреть, не смухлевали ли в MSDN и напишем свою версию процедуры:
create procedure TSQL_ProductProc (@product int output)
as
begin
  set @product = 1

  update tbl
  set @product = @product * intcolumn
end
Гм, что то тут не так. Можно сказать, что в TSQL не всегда так выкрутиться можно ? Угу, можно. Зато в ASA WatcomSQL и выкручиваться не надо. Берем первый попавшийся пример из BOL - в данном случае демонстирующий организацию нарастающих сумм в запросах через OLAP функции:
SELECT dept_id, emp_lname, start_date, salary,
SUM(salary) OVER (PARTITION BY dept_id
ORDER BY start_date
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;
а вот и результат:
dept_idemp_lnamestart_datesalarySum_Salary
100'Whitney''1984-08-28'45700.00045700.000
100'Cobb''1985-01-01'62000.000107700.000
100'Shishov''1986-06-07'72995.000180695.000
100'Driscoll''1986-07-01'48023.690228718.690
100'Guevara''1986-10-14'42998.000271716.690
100'Wang''1988-09-29'68400.000340116.690
100'Soo''1990-07-31'39075.000379191.690
100'Diaz''1990-08-19'54900.000434091.690
200'Overbey''1987-02-19'39300.00039300.000
200'Martel''1989-10-16'55700.00095000.000
200'Savarino''1989-11-07'72300.000167300.000
200'Clark''1990-07-21'45000.000212300.000
200'Goggin''1990-08-05'37900.000250200.000

Гм - тут ни курсоров, ни циклов, ни переменных, а ведь поди считаются нарастающие по каждой указанной группе. Вопрос на засыпку - а будет ли код на C# выглядеть так же эффективно, как этот запрос ? А не легче ли это было встроить в TSQL и не навязывать людям .NET ?
9 дек 04, 19:19    [1171756]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
c127
Guest
Триггеры before и другие обсуждались вот тут:

https://www.sql.ru/forum/actualthread.aspx?tid=27979

2 Leonid

>Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?

Действительно, нет смысла. Может все-таки нужно было подключить через DLL? DLL это такой же механизм для интеграции приложений (тоже революционная технология, много шума было когда-то), как сейчас .НЕТ.

После выхода Юкона (если вдруг) тоже можно будет сказать: можно было написать на C#, но, по некоторым соображениям, пришлось перевести ее на T-SQL. "Некоторые соображения", как известно, от языка программирования не зависят.
10 дек 04, 04:47    [1172157]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>>Мне как разработчику все равно придется помнить кроме SQL, его к тому времени раздутую вплоть до ООП Transact-составляющую, а при переходе на ORACLE его раздутую PL-составляющую.

Ну и что? От разработчиков всегда требуется что-то помнить. Такова жизнь...
10 дек 04, 06:49    [1172175]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?.

Вот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?
10 дек 04, 06:57    [1172178]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
www.fun4me.narod.ru
Вот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?

Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc". Исходя из этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного. С моей точки зрения для MS , которая специально в те же UDF ввела множество ограничений для борьбы с велосипедистами в MSSQL 2000, такая смена политики выглядит довольно странно.
10 дек 04, 07:47    [1172218]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
А ведь так можно и Mono в MySQL запихать! Вот зверь получится!!!
10 дек 04, 09:42    [1172391]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
вообще, согласен с мнением, что CLR в SQL Server - это кратчайший путь к созданию кривых в общей массе баз данных.

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

С другой стороны внесение возможностей CLR, Java внутрь сервера БД в определенных случаях может значительно помочь в том случае, когда у архитектора проекта есть голова на плечах.
10 дек 04, 13:21    [1173743]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
ASCRUS
C# выглядеть так же эффективно, как этот запрос ? А не легче ли это было встроить в TSQL и не навязывать людям .NET ?

Ну, во-первых, вам ни кто ни чего не навязывает. Так же как и java в ORACLE. Не изображайте из себя несчастного обманутого потребителя. Будете вы пользоваться этим или нет - это ваше дело.
Во-вторых, MS сама рекомендует без надобности CLR не использовать:
Even before CLR support was introduced in SQL Server, it has always been important to recognize that database applications should use the query language as much as possible. Database applications should take advantage of the set-oriented query processor and only resort to procedural programming for expressing logic that cannot be expressed within the query language.

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

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

ASCRUS
Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc"...
Глупость какая... А еще напишите сюда про толпы мрачных T-SQL программистов, оставшихся без работы, потому что все теперь можно реализовать на C#. ;)

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

Я, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится.
10 дек 04, 14:04    [1174033]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Leonid
Я, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится.

Хм. По мне, идея интеграции AS в БД несколько сомнительна. Идея "многозвенности" - как раз в том, что AS - это приложение, работающее с БД, и единственное, видимое "снаружи".

Другой вопрос - что этим путем можно будет легко создавать "БД, которые на самом деле не только БД" - к примеру, те же view, содержимое которых ограничено правами пользователя и рассчитывается с использованием возможностей appserver-а.
10 дек 04, 14:25    [1174136]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
?
Guest
Leonid
Опять глупость какая-то. Кривость БД не пропорциональна заложенным в сервер возможностям. В таком случае, самые кривые решения должны быть на ORACLE ;)
Именно такое впечатление и складывается.
На MS SQL курсоры медленны - все стараются обходится без них. В ORACLE - лепят где нужно и где не нужно.
10 дек 04, 14:34    [1174177]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
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. А вообще не понимаю, чего так горячиться и обвинять других в глупости ? Неужели Вы думаете, что я настолько туп и недальновиден, что не вижу выгод при использовании ООП языков в БД ? В данном случае мне не интересны преимущества, их и так понимает любой граммотный проектировщик БД, мне гораздо интереснее последствия :)
10 дек 04, 14:47    [1174241]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
??
Guest
?
На MS SQL курсоры медленны - все стараются обходится без них. В ORACLE - лепят где нужно и где не нужно.


От обратного - в MSSQL все лепят времянки где нужно и не нужно ;-) И не понимают, как в Оракле большинство обходится без них.
10 дек 04, 15:28    [1174446]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
ASCRUS
Да без проблем. Только не надо тут это тогда превозносить, как этакое новое чудо от MS.
Я не превозносил, а лишь говорил, что у MS это, возможно, получится удачнее, чем у конкурентов.

ASCRUS
Однозначко кодеры и есть скриптописатели, после "мук творчества" которых частенько волосы встают дыбом, когда глядишь на их код в БД.
Вы видели мой код на T-SQL или код наших сотрудников, чтобы так утверждать?
Значит вы видели плохой код, плохих SQL программистов, применяющих dBase подходы при работе с SQL Server-ами.
Так что попрошу не обобщать. И, потом, ни чего особенно уж сложного в стандартном SQL нет, а необходимость знания реляционной модели при работе с SQL-Server-ами никто не отменит.
А вот как ни крути, а на скрипт все же больше похожа Transact или PL - составляющие, чем полнофункциональный язык ;)

ASCRUS
Да нет - толпы еще более мрачных, чем ранее DBA, которым ранее приходилось встречаться только с кривыми реализациями на TSQL, а теперь они в придачу получат C# и VB.NET (были цветочки, станут ягодки).
Ну зачем так мрачно? Да и потом, по большому счету, не DBA это дело лезть в реализацию конкретной БД, а уж тем более ее править. Вот как раз наши "доморощенные DBA-Кулибины" очень любят это делать, иногда даже толком не зная, зачем и почему сделано так-то и так-то.
Понятно, что Российские реалии - это особый случай, но кривая реализация - это просто "кривая реализация" без относительно того, кем и не чем она сделана.

ASCRUS
Угадали - именно так и есть, самые кривые и вгоняющие в обморок решения я видел именно на Оракле, что и говорит о его многофункциональности и последствиях излишне любящих творчество.
Сам видел кривые решения на Oracle, ну и что? От перехода в более узкие рамки MSSQL или другой БД они что распремятся что ли?
Вы и сами знаете, что кривость не в ORACLE, а в головах разработчиков. Ну посади ты их на другую БД они и там все криво наваяют. Зато на ORACLE - это круто! ;) Боюсь, это тема для другой ветки ;)

ASCRUS
Вот про такие мысли я и говорил. Вы случайно не заметили разницу между назначением хранимой процедуры на C# для MSSQL и парадигмой 3-его звена ?

А я и не собирался запихивать AS в хранимую процедуру.

ASCRUS
А вообще не понимаю, чего так горячиться и обвинять других в глупости ?
Давайте не будем горячится, кто против, тем более нам с вами делить особенно не чего ;)
10 дек 04, 15:33    [1174469]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> И, потом, ни чего особенно уж сложного в стандартном SQL нет, а необходимость знания реляционной модели при работе с SQL-Server-ами никто не отменит.

А в С++ разве что-то особенно сложное есть?
10 дек 04, 15:37    [1174486]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
www.fun4me.narod.ru
А в С++ разве что-то особенно сложное есть?
Вы сами знаете ответ. Точно так же нужны знания и практика ;)
10 дек 04, 15:57    [1174587]     Ответить | Цитировать Сообщить модератору
 Re: Весомый плюс Юкон над ORACLE  [new]
Yo!
Guest
есть неоспоримый факт что существует достаточно большая часть программеров которые совершенно не вникает в работу субд. мало того это от него специально скрывают различные фреймворки и корпоративные буилдеры. эти люди пишут серийные системы обслуживающие крупнейшие канторы, т.е. их системы в разы комплекснее чем системы большинства из вас. да есть проблема производительности у таких изделий, но при определеных размерах проэкта это решается грубой силой (железом).
короче мысль в том что те кто и так логику вынес на апп-сервер, получит бонус в виде переноса оной на ближе к уровеню субд и получив еще пару процентов к скорости, а те кто бьется за каждый запрос, так и будут использовать T-SQL (PL/SQL).
просто как видно по ораклу он потехоньку забивает на pl/sql (7 лет косметические изменения) и теперь очень медлено его развивает, в то время как 10gR2 жаба продвинута до версии 1.4
10 дек 04, 16:12    [1174648]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить