Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / MS SQL & Oracle 10 g / 25 сообщений из 70, страница 1 из 3
  1  все
07.06.2006, 10:58
    #33776856
Iura
Iura
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Привет всем

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

В базе данных хранится текст. Мне нужно сделать разбивку текста по предложениям (для примера используем простейшие признаки окончания предложения - . ! ?) Поскольку в будущем разбивка на предложения будет гораздо сложнее и учитывать множество факторов (например пользователи сами смогут создавать правила на regular expressions), я отказался от написания процедуры на T-SQL и решил саму процедуру на C# или C++, а полученую откомпелированную функцию подключать к SQL 2005 как exteranal stroed procedure.

Я полагаю, что такое взаимодействие TSQL и C# или C++ будет сильно напрягать
SQL 2005.

Насколько эффективно решение той же задачки на Oracle 10g ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 11:23
    #33776971
Пьяный Лох
Пьяный Лох
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Про CLR Integration в 2005-ом Вы таки ни разу не слышали?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 11:25
    #33776979
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
у оракла regular expression можно использовать в SQL, т.е. с ораклом ничего кроме обычного SQL тебе не понадобится.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 11:30
    #33777008
Iura
Iura
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Yo.!!у оракла regular expression можно использовать в SQL, т.е. с ораклом ничего кроме обычного SQL тебе не понадобится.

Вот я тоже об этом думаю. Плюс у него есть поддержка ООП. А иногда это удобно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 11:59
    #33777121
andsm
andsm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Iura
Я полагаю, что такое взаимодействие TSQL и C# или C++ будет сильно напрягать
SQL 2005.

Полезно читать документацию, хотя бы иногда. Если сделаю с использованием C# процедуры, то должно работать быстрее чем аналогичный код в Oracle.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:03
    #33777135
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
andsm
Полезно читать документацию, хотя бы иногда. Если сделаю с использованием C# процедуры, то должно работать быстрее чем аналогичный код в Oracle.
ага C# быстрее нативного SQL :) че курим ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:05
    #33777143
andsm
andsm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Yo.!! andsm
Полезно читать документацию, хотя бы иногда. Если сделаю с использованием C# процедуры, то должно работать быстрее чем аналогичный код в Oracle.
ага C# быстрее нативного SQL :) че курим ?
Тесты производительности, которые я делал для сравнения производительности C# и TSQL.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:10
    #33777164
locky
locky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Yo.!! wrote:
> Полезно читать документацию, хотя бы иногда. Если сделаю с
> использованием C# процедуры, то должно работать быстрее чем аналогичный
> код в Oracle.
>
> ага C# быстрее нативного SQL :) че курим ?
ну... если сравнивать вроде как бы нативный бинарник, скомпиленный под
нужную ось, с вроде как байт-кодом, исполняемым каким-то аппаратом
исполнения (sql engine), то нативный бинарник должон быть быстрее. вроде
как. не знаю как насчет проц в оракле, которые вроде как можно
скомпилить в те-же самые нативные бинарники....

зы как показывает практика - компилированая прога как правило быстрее,
чем интерпретируемая (коряво сказал, но общий смысел вроде ясен).


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:18
    #33777189
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
locky
ну... если сравнивать вроде как бы нативный бинарник, скомпиленный под
нужную ось, с вроде как байт-кодом, исполняемым каким-то аппаратом
исполнения (sql engine), то нативный бинарник должон быть быстрее. вроде
как. не знаю как насчет проц в оракле, которые вроде как можно
скомпилить в те-же самые нативные бинарники....

зы как показывает практика - компилированая прога как правило быстрее,
чем интерпретируемая (коряво сказал, но общий смысел вроде ясен).

да не в этом дело. SQL запускается в другом контексте нежели CLI машина, т.е. неважно что там, но эти переключения никак не допустят исполнится быстрее чем только SQL.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:22
    #33777221
AAron
AAron
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Yo.!! locky
ну... если сравнивать вроде как бы нативный бинарник, скомпиленный под
нужную ось, с вроде как байт-кодом, исполняемым каким-то аппаратом
исполнения (sql engine), то нативный бинарник должон быть быстрее. вроде
как. не знаю как насчет проц в оракле, которые вроде как можно
скомпилить в те-же самые нативные бинарники....

зы как показывает практика - компилированая прога как правило быстрее,
чем интерпретируемая (коряво сказал, но общий смысел вроде ясен).

да не в этом дело. SQL запускается в другом контексте нежели CLI машина, т.е. неважно что там, но эти переключения никак не допустят исполнится быстрее чем только SQL.
спорное утверждение.
Вы же не можете сказать, сколько "стоит" такое переключение, а также насколько сильный эффект оно окажет на работу всей программы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:24
    #33777227
locky
locky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Yo.!! wrote:
> да не в этом дело. SQL запускается в другом контексте нежели CLI машина,
> т.е. неважно что там, но эти переключения никак не допустят исполнится
> быстрее чем только SQL.
вопрос (встречный) - чо курим?
Ви хотите сказать, что нечто вроде
Код: plaintext
1.
  for I =  1  to  10000  do ;
выполнится быстрее на SQL, чем на c#?
ой врядли.... попробуйте теорию практикой... урод эксперимент убьёт!
красавицу теорию....
а ведь задача разбивки на предложения - это чистые циклы и сравнения.


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:28
    #33777250
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
2locky
я конечно понимаю твое жгучее желание поспорить, но давай сначала выясни что такое SQL ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 12:59
    #33777400
nkulikov
nkulikov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
На самом деле в чем-то Yo!! прав.
SQL запрос более вероятно выполнится быстрее чем код на C#. Только на эту проблему нужно смотреть несколько иначе IMHO.

Давай те смотреть на на for i=1 to 100000 do; а на более серьезные вещи типа select'oв

Задача поиска слона в африке
Есси мы пишем ее на С# это будет
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
if слон not exist in Kong go to limpopo
      return слон
if слон not exist in Kong go to limpopo
      return слон
if слон not exist in Kong go to limpopo
      return слон
--на SQL это будет выглядеть как 
SELECT слон from африка

Нужно разделять код на SQL и в Хранимой процедуре. Более того часто богатые возможности в хранимых процедурах приводят к тому, что люди начинают писать программы по работу с БД в процедурном стиле, что напрочь убивает производительность. Например (понятно что надумано, но такое часто бывает)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
  DECLARE c1 CURSOR FOR 
    SELECT firstnme, midinit, lastname 
    FROM employee
    ORDER BY midinit DESC;
  DECLARE CONTINUE HANDLER FOR NOT FOUND
    SET counter = - 1 ;

  -- initialize OUT parameter
  SET counter =  0 ;
  OPEN c1;
  fetch_loop:
  LOOP
    FETCH c1 INTO 
      v_firstnme, v_midinit, v_lastname;
    -- Use a local variable for the iterator variable
    -- because SQL procedures only allow you to assign 
    -- values to an OUT parameter
   if v_midinit = ' ' then
    SET v_counter = v_counter +  1 ;
      LEAVE fetch_loop;
    return v_counter;
    END IF;
  END LOOP fetch_loop;
  CLOSE c1;
Это будет гораздо медленнее чем
Код: plaintext
1.
select count(*) from EMPLOYEE where midinit= ' '

Причем если запрос с count(*) можно оптимизоваровать, строить разные индексы партиционировать таблицы по midinit, то во втором случае, максимум чего можно достигнуть это написать на C, чтобы сократить затраты на .NET или на интерпретатор.

Понятно что если случаи когда более удобно пользоватся тем или иным подходом, но всегда нужно оценивать принимаемое решение. По мне проще и будет писать многокилобайтные запросы чем городить SP. Опять же будет зависить от конкретной ситуаци.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:01
    #33777407
тлгдшлщм
тлгдшлщм
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Поправочка
Нет слона в конго идем в лимпопо, нет в лимопопо идем у уганднду, return слон
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:07
    #33777436
alexey_tm
alexey_tm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Я не могу понять, в чем спор.
Если необходимо все это делать в БД, её средствами, выбирая из ее таблиц, что бы там не говорили, SQL будет работать быстрее, просто по тому, что в любом случае, будет выполняться SQL запрос: данные нужно выбрать затем обработать и положить "на место".
Если говорить о Oracle, то вообще-то любой SQL будет превращен в исполняемый код, а не интерпретирован, хотя на самом деле все сложнее. Если данные запрос будет повторятся постоянно и он правильно написан, то компиляция его будет произведена только один раз.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:16
    #33777489
хламист
хламист
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
to nkulikov

бред!
что мешает выполнить SELECT слон from африка из контекста CLR процедуры?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:31
    #33777564
andsm
andsm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Yo.!!да не в этом дело. SQL запускается в другом контексте нежели CLI машина, т.е. неважно что там, но эти переключения никак не допустят исполнится быстрее чем только SQL.
В SQL Server нет такой разницы между TSQL и SQL как между PL/SQL и SQL в Oracle.

Я делал тесты чтобы проверить происходит ли переключение контекстов и сколько это переключение стоит. Результат - переключения контекстов отсутствует. Вызов ничего не делающей функции на C#, в цикле, 1000000 раз, происходит быстрее, примерно на 30%, чем вызов аналогичной функции на TSQL. Это означает что CLR integration сделана очень хорошо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:31
    #33777566
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Even without CLR support, it is important to recognize that database applications should use the declarative query language as much as possible . This portion of the language is able to leverage the power of the query processor, which is best able to optimize and perform bulk operations. Database applications should only resort to procedural programming to express logic that cannot be expressed within the query language.

All of this remains true with CLR support in SQL Server: the CLR should not be used to write procedural code that can be expressed using the declarative features of the T-SQL language. Developers should be aware that there are a number of significant enhancements to the T-SQL query language in SQL Server 2005 that augment the expressive power of the T-SQL query language, and should ensure that they are taking full advantage of them before writing procedural code, whether in the CLR or not. Some of these added features include:

(C) MSDN

ЗЫ. я смотрю МС тоже с трудом отличает декларативный SQL от процедурного расширения T-SQL :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:40
    #33777614
тлгдшлщм
тлгдшлщм
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
2хламист:
хламист
бред!
что мешает выполнить SELECT слон from африка из контекста CLR процедуры?

и это будет более производительно чем вызов запроса напрямую???

Ты хотябы понял идею того что я пытался объяснить. Перед тем как говорить бред не бред.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:40
    #33777615
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
andsm
В SQL Server нет такой разницы между TSQL и SQL как между PL/SQL и SQL в Oracle.

а вот МС с вами не согласен :) (см цитату с MSDN выше)

andsm
Я делал тесты чтобы проверить происходит ли переключение контекстов и сколько это переключение стоит. Результат - переключения контекстов отсутствует. Вызов ничего не делающей функции на C#, в цикле, 1000000 раз, происходит быстрее, примерно на 30%, чем вызов аналогичной функции на TSQL. Это означает что CLR integration сделана очень хорошо.

непонял что тут мерялось, то что CLR откомпилировалось, а T-SQL еще не дорос до native compilation .. дык это итак было известно. Вот погоняйте рандомные данные (T-SQL vs CLR), а потом сравните с функцией чистого SQL.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:42
    #33777627
locky
locky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
nkulikov wrote:
> Автор: nkulikov
> На самом деле в чем-то Yo!! прав.
> SQL запрос более вероятно выполнится быстрее чем код на C#. Только на
> эту проблему нужно смотреть несколько иначе IMHO.
>
> Давай те смотреть на на for i=1 to 100000 do; а на более серьезные вещи
> типа select'oв
>
> Задача поиска слона в африке
> Есси мы пишем ее на С# это будет
Может Yo! и прав, и может, правы и Вы, решая задачу поиска сферического
коня в вакууме... однако исходный вопрос был "разбиение текста на
предложения: T-SQL vs C#"
может быть! есть декларативный язык который это умеет... но T-SQL явно
не из из числа. поэтому моя имха такая: выделение предложений из текста
при помощи внешней процы написанной на c# будет быстрее, чем при помощи
процы на T-SQL, поскольку накладные расходы на "переключения контекста"
для вызова C# с лихвой покроют относительную неторопливость исполнения
T-SQL процедуры.

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:50
    #33777680
locky
locky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
кроме того, проведя (как сейчас вспомнил) некоторые изыскания....
выяснил: имелся некий набор UDF для манипуляций с датой и строками
(обрезать время, собрать дату, получить первый-последний день месяца,
преобразовать '1а' в '00000001а' для использования в сортировках и
т.д.). Аналоги, реализованные на C# работали быстрее, чем T-SQL UDF.
Происходило это (предположительно) за счет меньших накладных расходов
при вызове C# UDF по сравнению с T-SQL UDF. Вот такая странность,
внятного (для меня) объяснения не видел (особо и не искал).

кроме того, выделение предложений - есть некая манипуляция с уже
полученными данными, БЕЗ обращения к базе данных. И по определению -
будет быстрее в виде бинарной реализации.

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 13:56
    #33777704
nkulikov
nkulikov
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
Ты прав locky. Но инициатору я бы рекомендовал не С#, а с/c++ так как в этом случае будет меньше вопросов с переносом кода с одной БД на другую
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 14:29
    #33777834
Yo.!!
Yo.!!
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
2locky
чтоб что-то доказать лучше напишите простенькую функцию upper() на t-sql и clr и сравните на мульонной табличке, а потом сравните с нативным SQL.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.06.2006, 14:31
    #33777843
locky
locky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS SQL & Oracle 10 g
nkulikov wrote:
> Ты прав locky. Но инициатору я бы рекомендовал не С#, а с/c++ так как в
> этом случае будет меньше вопросов с переносом кода с одной БД на другую
не... если на MS SQL - то уж лучше C#(это если юкон), потому как
геммороя с ESP в 2000 - порядком :-(. Правда, был в свое время набор
компонентов для дельфина, который таки гемморой значительно сокращал...
да и не шибко рекомендует вроде MS писать ESP на чем-нить кроме C#...
и с люпбжком к базе в шарпе - получше, значительно... да и
документирован он лучше, чем йентот ODS (приходилось подымать доки
вплоть до 6.5, чтобы чего-то понять).
--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / MS SQL & Oracle 10 g / 25 сообщений из 70, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]