Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 31   вперед  Ctrl
 Re: MS SQL > Oracle = True?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> И как эти эксперты будут искать этот ответ ?

Консалтером более выгодно рекомендовать наиболее дорогую и сложную в настройке и эксплуатации СУБД, чтобы к ним потом обращались с вопросами, как со всем этим делом работать.
29 дек 04, 14:54    [1218568]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
т.е. оракл ;)
29 дек 04, 15:29    [1218824]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
StalkerS
вот я сейчас быстро просмотрел пару ссылок по oracle application server, и насколько понял, это продукт (как и должно следовать
из названия) предназначен для создания многозвенной структуры, а это, все-таки имеет непосредственное отношение к самой СУБД.
Если он и не входит в саму поставку CУБД, но при создании n-звенной структуры нужен, то нечестно его вычеркивать из списка.

Во-первых, Applications и Application Server - это два разных продукта.

Во-вторых, по этой же логике честным будет добавить к уязвимостям Sql Server уязвимости IIS и .NET. Впрочем, сама логика крайне сомнительна. Давайте тогда уж добавим к ораклу уязвимости WebLogic, Tomcat или бог весть еще чего - они ведь тоже "нужны для создания многозвенок".

Реально Application Server - независимый продукт. Разумеется, Оракл рекомендует использовать его в связке со своей же базой - впрочем, если Вы подцепите к нему MSSQL, все его уязвимости тут же надо будет приплюсовать к уязвимостям MSSQL :)

StalkerS
Я так могу повычеркивать, к примеру, уязвимости в расширенных хранимых процедурах и сказать - я их не использую !

Не понял аналогии. Имхо, она будет обратной - взяли глючное приложение, с помощью расширенных хранимых процедур подключили его к серверу и теперь говорим "сервер легко уязвим". Именно так Вы поступаете, приписывая к глюкам RDBMS глюки AS.

Более конкретный пример: допустим, Ваша цель - добраться до моих данных. Вы знаете глюку в AS. Если я - умный программист оракла - использую средства защиты RDBMS, скажем, row-level security - вряд ли Вы извлечете дивиденты из этой дыры. Если же я напишу приложение, которое коннектится к БД под sys-ом - через ту же дыру сделаете что угодно, хоть у меня отберете доступ к базе.

Вопрос: дыра это RDBMS или не дыра? Имхо - это будет дыра моего приложения, которое не использует средства защиты RDBMS.

StalkerS
Бессмысленно или нет механически считать дыры - вероятно да, но повторяю, это пока лучший способ хотя-бы оценить безопасность систем,

Не думаю, что это лучший способ. По крайней мере, объективно он никуда не годится.

StalkerS
ведь если дыр больше, как можно говорить о большей безопасности ?

Точно так же, как и о меньшей.

Эти величины плохо коррелируют. Соответственно, любой вывод об их соотношениях бессмысленен и - согласно законам логики - имеет некоторые шансы случайно оказаться верным.

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

Если брать сравнение серверов - насколько я понимаю, SQL Injection в MSSQL куда более опасна в силу различия диалектов. То есть, если я не ошибаюсь, в MSSQL я легко могу приписать в конец селекта, например, delete; в Оракле этот трюк не пройдет (требуется анонимный блок).

Вывод: стоимость дыр - может быть очень разной. Соответственно, количество дыр не является хоть сколько-нибудь осмысленной оценкой ущерба от них, а следовательно и общей уязвимости.

StalkerS
Да, моя квалификация не может мне позволить судить о правильности выбора СУБД для конкретного проекта, я знаю только mssql и немного
интербейса и access. Может и в самом деле тут оракл лучше. А может DB2 или Informix ? или Interbase ?

Где вы найдете специалиста, являющегося экспертом в паре десятков СУБД ?

Я не думаю, что для выбора нужно "знать" эти системы. Я думаю, что для выбора нужно обладать квалификацией PM-а. Если Вы не можете хорошо оценить сроки собственной работы - вряд ли Вы сумеете предусмотреть "мерзкие мелочи" в том и другом варианте. И, соответственно, в разы будут прыгать стоимость и сроки уже проекта в целом.

StalkerS
Кто-то типа меня будет орать - MSSQL !, кто-то типа вас или Yo! - ORACLE !

Хм. Знаете, я бы попросил Вас либо подтвердить свое высказывание цитатами, либо извиниться.

StalkerS
А как вы сами определяете, какой сервер выбрать ? Неужели что-то там анализируете ?

Так же, как предлагал Вам. Исходя во-первых из наличия экспертов, а во-вторых, из требований прикладной системы. В моем случае выбор стоит достаточно просто: либо я берусь за задачу, либо говорю "с этой задачей лучше искать специалиста вот по этому". В фирмах с большим спектром инструментация я пока не работал.

StalkerS
Да вы сами только что дали хороший пример :

а теперь посмотрим, что по этому поводу думают эксперты, написавшие труд "Features, strengths and weaknesses comparison between
MS SQL 2005 (Yukon) and Oracle 10g databases":

Не читал этого труда. Сама по себе в процитированном сказана пара странных вещей - например, именно административного overhead нет в принципе; можно сказать, что есть девелоперский overhead. Если это тот самый труд маркетологов, который здесь широко склоняли - я бы сказал, что это выглядит приемом "надо назвать хоть какие-то недостатки - так давайте назовем то, что в глазах эксперта является нашим достоинством". То есть - и вроде как проявили объективность и вроде как "недостаток только для чайников".

StalkerS
Вот-те раз, два эксперта в одной системе, а какие разные мнения !

Кстати, формально говоря не такие уж разные. Здесь сказано: "по историческим причинам этой фичи нет, а есть другая, более мощная и более требовательная". Не вижу, чем это так уж противоречит моему мнению.

StalkerS
Возможно, добравшись до бога в области БД (типа Glory ;) иногда создается такое впечатление), он скажет - выкинь эту макулатуру,
истина недостижима.

Изрядна доля правды в этой фразе :)

StalkerS
И вообще, раз вы не согласны с моим мнением, что оракл и mssql дадут один и тот-же результат, интересно послушать ваши аргументы.
То, что все определяется квалификацией и так понятно, но если есть два эксперта, то где результат будет лучше ?

Зависит от соотношения квалификации экспертов. Тесты типа tpc, насколько я полагаю, следует трактовать примерно так: лучшие эксперты, выставленные той и другой стороной, данные конкретные задачи в данных конкретных условиях и не считая затраченного времени-денег решили примерно с такими соотношениями. Я соглашусь с тем, что эксперты с обеих сторон примерно одинаковой крутости. Что касается экспертов, которых можем выставить я или Вы - соотношение может оказаться любым. Что касается стоимости работы - объективных данных нет, приходится опираться на смутные ощущения.

Ну и для полноты картины - надо помнить о довольно тонких фактах. Скажем, мне рассказывали так: MSSQL, получая запрос, строит план для этого запроса, но если есть много одинаковых планов (запросов, отличающихся значениями констант), он их объединяет и начинает пользоваться одним для всех следующих запросов.

В Оракле ситуация другая. В нормальном режиме Оракл переиспользует план только для запроса, точно совпадающего с ранее поступившим. В то же время можно включить режим cursor_sharing, похожий на MSSQL-ный - при котором все константы заменяются на параметры.

Что мы имеем в результате. С одной стороны, Oracle не тратит время на парсинг каждого поступившего запроса - он просто считает хэш. То есть большая эффективность. С другой стороны, неграмотный программист, не соображающий нахрена нужны bind variables, нормально настроенный Оракл затормозит сильнее, нежели нормально настроенный MSSQL. С третьей стороны, Оракл можно настроить так же - то есть дополнительной константной неэффективностью компенсировать нарастающую переменную - но здесь MSSQL использует адаптивный алгоритм, а Оракл работает довольно грубо. С четвертой стороны, Oracle позволяет программисту тонко и эффективно делать выбор между использованием и неиспользованием гистограмм: либо мы экономим на построении плана, либо мы строим план и получаем ускорение от гистограмм. MSSQL здесь получается более грубым: вряд ли получится сказать ему, что "вот эту константу меняй, а вот эту не трогай и пользуйся гистограммами".

А вот теперь, на основании всей этой информации скажите мне: кто лучше? Только общую оценку, а не "при таких-то условиях будет лучше тот-то".
29 дек 04, 18:08    [1219684]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
softwarer

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

Вывод: стоимость дыр - может быть очень разной. Соответственно, количество дыр не является хоть сколько-нибудь осмысленной оценкой
ущерба от них, а следовательно и общей уязвимости.


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

softwarer

Хм. Знаете, я бы попросил Вас либо подтвердить свое высказывание цитатами, либо извиниться.


ну извините, если это так вас задело, вот-уж не думал. Я-то всего-навсего имел в виду ситуацию, когда на каком-нибудь собрании
хор из 10 голосов дружно рявкнет : "Оракл быстрее и надежнее !", и если я в ответ пролепечу что-то типа "Вы знаете, если
абстрогироваться от общей ситуации и взглянуть с другой стороны, то можно обратить внимание, что ...", угадайте, какой вывод
сделает начальник, который ничего в этом не понимает, но должен сделать выбор ?

softwarer

Я не думаю, что для выбора нужно "знать" эти системы. Я думаю, что для выбора нужно обладать квалификацией PM-а. Если Вы не можете
хорошо оценить сроки собственной работы - вряд ли Вы сумеете предусмотреть "мерзкие мелочи" в том и другом варианте. И, соответственно,
в разы будут прыгать стоимость и сроки уже проекта в целом.


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

softwarer

Так же, как предлагал Вам. Исходя во-первых из наличия экспертов, а во-вторых, из требований прикладной системы. В моем случае выбор
стоит достаточно просто: либо я берусь за задачу, либо говорю "с этой задачей лучше искать специалиста вот по этому". В фирмах с большим
спектром инструментация я пока не работал.


Как это - из требований прикладной системы ? т.е. вы все равно проводите какой-то анализ ? И как вы это делаете ? Или зовете этого
таинственного РМ ? Ну а наличие или отсутствие специалистов по конкретной СУБД никак не говорит об ее работоспособности.

softwarer

Кстати, формально говоря не такие уж разные. Здесь сказано: "по историческим причинам этой фичи нет, а есть другая, более мощная и
более требовательная". Не вижу, чем это так уж противоречит моему мнению.


Это как это вы так прочитали ? На всякий случай, напишу дословный перевод:
"Одной из наиболее полезных особенностей, которую Оракл не имеет по историческим причинам, является identity. Практически любая
база данных имеет возможность генерировать РК автоматически, в то время как Оракл обладает только sequences. Sequences у Оракла
является полезным механизмом, но тем не менее, он влечет за собой дополнительную нагрузку на администратора. Реализация чего-то
подобного identity в MSSQL используя Оракловские sequence требует указания имени sequence в клиентском приложении, или создании
триггера на каждую пару таблица/sequence".

softwarer

А вот теперь, на основании всей этой информации скажите мне: кто лучше? Только общую оценку, а не "при таких-то условиях будет лучше тот-то".


не знаю точно, как обстоит дело с планами обычных запросов, но если скорость выполнения критична, то можно сделать из запроса хранимую
процедуру, а вот ее можно уже перекомпиливать каждый раз при исполнении. И тут уже на усмотрение программиста, если он считает, что
перекомпилировать каждый раз будет лучше, указывает with recompile, и план каждый раз строится по новой. Если нет, то по умолчанию
используется план из кэша.
Вот вам и разный подход, если mssql и в самом деле не перекомпилирует план запроса при разных константах (не знаю, честно говоря), а это
важно для скорости, создавайте ХП, и перекомпилируйте ее каждый раз.

В данном случае, на выходе разницы в результатах не будет.
29 дек 04, 21:48    [1219972]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
StalkerS
Хорошо, тогда в такой метрике вообще никакие факты не будут иметь решающего значения.

Это не так. Что правда - метрика действительно тесно привязана к конкретной задаче.

StalkerS
Выходит, что разговор в принципе бессмысленен, безопасность
нельзя гарантировать,

Хм. Любому, кто обещает гарантировать Вам безопасность, плюйте в лицо. Можно добиться только большей или меньшей трудности доступа.

Хорошо защищенная система (с программной точки зрения) - та, в которой легче и дешевле получить информацию методом утюга и паяльника.

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

Вы все время пытаетесь свести сложную, нелинейную метрику к тривиальным выкладкам.

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

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

StalkerS
softwarer

Хм. Знаете, я бы попросил Вас либо подтвердить свое высказывание цитатами, либо извиниться.

ну извините, если это так вас задело, вот-уж не думал. Я-то всего-навсего имел в виду ситуацию, когда на каком-нибудь собрании
хор из 10 голосов дружно рявкнет : "Оракл быстрее и надежнее !",

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

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

PM - это project manager. Что касается "нормальной ситуации" - не вижу никаких причин считать ее нормальной. Есть понятие "исследовательская работа" - и таки да, там предсказать сроки можно только с очень большим разбросом. Что касается Microsoft - они занимаются проектами того уровня сложности, на котором мало кто работает - поэтому почти любая их работа в какой-то степени исследовательская. У большинства из нас, полагаю, ситуация существенно проще.

Что касается меня - в знакомой ситуации я почти не ошибаюсь. В том числе, как руководитель группы, когда от меня требовали называть сроки порядка дней. В незнакомой или при большом количестве непредсказуемых факторов - говорю, что могу дать оценку только с большим разбросом. И опять-таки, редко ошибаюсь.

StalkerS
Как это - из требований прикладной системы ? т.е. вы все равно проводите какой-то анализ ?

Анализ - пожалуй, слишком громкое слово. Я отказался от пары проектов со следующей формулировкой: "Оракл для вас не нужен, в то же время проект великоват для того, чтобы делать его на плохо знакомом инструменте. Поэтому я бы посоветовал искать специалистов по Interbase или аналогичным базам".

StalkerS
Ну а наличие или отсутствие специалистов по конкретной СУБД никак не говорит об ее работоспособности.

О работоспособности - никак не говорит. Но практически на 100% говорит о возможности сделать серьезный проект более-менее уложившись в сроки/деньги/качество.

StalkerS

Это как это вы так прочитали ? На всякий случай, напишу дословный перевод:

И? По сравнению с этим подстрочником в моем утверждении есть единственное дополнительное слово: "более мощную". То, что sequences мощнее identity, тривиально математически доказать: с их помощью тривиально реализовать identity, но с помощью identity довольно затруднительно реализовать sequences. Не скажу "невозможно" - но механизм получится громоздким и практически бессмысленным.

StalkerS

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

Вы не поняли примера. Я как раз об этом и говорю, что у MSSQL здесь выбор груб - либо перестраиваем план всегда, либо не перестраиваем почти никогда. Оракл позволяет регулировать этот процесс.

Давайте рассмотрим следующую серию запросов:

select * from table where a = 1 and b = 1
select * from table where a = 1 and b = 2
select * from table where a = 1 and b = 3
select * from table where a = 2 and b = 1
select * from table where a = 2 and b = 2
select * from table where a = 2 and b = 3
select * from table where a = 3 and b = 1
select * from table where a = 3 and b = 2
select * from table where a = 3 and b = 3
...
select * from table where a = 1000 and b = 1
select * from table where a = 1000 and b = 2
select * from table where a = 1000 and b = 3

MSSQL здесь дает следующий выбор: либо один план, либо три тысячи. В Oracle же я могу использовать три плана, то есть использовать гистограммы по b и одновременно чихать на разные значения a.

Ну а "если скорость некритична" - согласитесь, бессмысленно вообще сравнивать сервера :)

StalkerS

Вот вам и разный подход, если mssql и в самом деле не перекомпилирует план запроса при разных константах (не знаю, честно говоря), а это
важно для скорости, создавайте ХП, и перекомпилируйте ее каждый раз.

Хм. Я здесь говорю с чужих слов, так что дам ссылку на обсуждение: http://rsdn.ru/Forum/Message.aspx?mid=923155

StalkerS

В данном случае, на выходе разницы в результатах не будет.

Перекомпиляция каждый раз - очень дорогое удовольствие. Поэтому выбор "перекомпилировать всегда" или "не перекомпилировать никогда" - означает, что выбора почти нет.
30 дек 04, 11:28    [1220977]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
MSSQL здесь дает следующий выбор: либо один план, либо три тысячи
Уважаемый, насколько помню, Вы не являетесь специалистом в MS SQL, так зачем в очередной раз делать подобные утверждения ? Алгоритм построения и использования планов в MS SQL достаточно сложен и не описывается приведенной тривиальной логикой. Более того, построением плана можно управлять в определенных рамках в зависимости от ситуации.

P.S. Даже странно, вроде как грамотный специалист, а все время какие-то штампы лезут, как если бы я взялся рассуждать об устройстве Oracle. Что никогда даже не попытаюсь сделать, если не будет, по крайней мере, годичного тесного общения с оным.
30 дек 04, 17:57    [1222881]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ChA
Уважаемый, насколько помню, Вы не являетесь специалистом в MS SQL, так зачем в очередной раз делать подобные утверждения ?

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

Если Вы считаете по-другому - пожалуйста, выясните таки, кто из вас неправ, и расскажите мне. Я достаточно часто спрашиваю - как оно работает - и уже не в первый раз натыкаюсь на то, что вроде бы специалисты по MSSQL говорят противоречащие друг другу вещи и далеко не сразу приходят к согласию. Собственно, то обсуждение, на которое дана ссылка - пример такого; если грубо, они сначала поназывали друг друга ламерами, потом таки решили как оно на самом деле работает, и выяснилось, что изначально каждый был в чем-то неправ.
31 дек 04, 13:05    [1224032]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
softwarer

Вы все время пытаетесь свести сложную, нелинейную метрику к тривиальным выкладкам.


C чего у нас начинался разговор ? В ответ на мнение (не ваше ! ;) что оракл - более защищенная система, чем mssql, я привел список
уязвимостей, и сказал, что т.к. дыр в оракле больше, говорить что он более защищен - глупо.
На моем уровне знания безопасности, и на начальном уровне обсуждения этого вопроса, это вполне логичная мысль.
Можно подняться на виток выше, и рассматривать ситуацию с более высокого уровня. С этого уровня мы и в самом деле сможем увидеть,
что одна дыра может стоить сотни других, что есть хакеры и антихакеры разного профессионального уровня, и что антихакер-профессионал
сможет сделать дырявую системы достаточно устойчивой к атакам большинства хакеров, но атаки хакера-эксперта не выдержит. Для этого
требуется анти-хакер - гуру. И так по нарастающей до бесконечности.
Все это - в чистом виде философия, так как мы не можем подняться на виток выше, потому-что нет необходимых знаний. Поэтому разговаривать
об этом можно до бесконечности и безо всякого ощютимого результата. Собственно философы именно этим и занимаются.

Однако я не имею большого желания заниматься философией, я даже экзамен по ней с трудом в универе сдал. Поэтому, в данном случае я
занимаю позицию вида : "На нижнем уровне обсуждения, аргумент, что дыр больше, является и самом деле аргументом, а не пустой болтовней.
Если вы начинаете говорить с более высокой позиции по этому вопросу, вы должны хотя-бы сами понимать предмет разговора. То есть спор
по этому вопросу на таком уровне могут вести только профессионалы в безопасности. Однако, даже если профессионал проведет тщательный
анализ систем, и накатает отчет, в котором, на основании сравнения уязвимостей, сделает вывод в пользу какой-то системы, этот отчет
может попасть в руки гуру, который одним увесистым аргументом перевесит чашу весов в другую сторону."

----------------------------------------------------------------------------------------
Анекдот:

Отрывок из информационного сообщения:
"По данным системы автоматизированного управления тюрьмами штата Иллинойс, на следующей неделе истекает срок заключения опасного
хакера, осужденного в прошлом месяце на 5 лет лишения свободы за взлом банковской системы."
----------------------------------------------------------------------------------------


softwarer

И? По сравнению с этим подстрочником в моем утверждении есть единственное дополнительное слово: "более мощную".


я не утверждал, что sequences лучше или хуже, я их вообще в глаза никогда не видел. Я привел это сравнение, что-бы показать, что
даже эксперты могут кардинально расходиться во мнениях по одному и тому-же вопросу. Вы утверждаете, что sequences - очень хорошо,
а те эксперты относят sequences к недостаткам (тот отрывок я взял из раздела "Полезные функции mssql, отсутствующие в оракл").
Вот еще одно мнение :

http://www.interface.ru/fset.asp?Url=/forum/display_message.asp?mid=5598

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

softwarer

MSSQL здесь дает следующий выбор: либо один план, либо три тысячи. В Oracle же я могу использовать три плана


Раз-уж так надо именно три плана, то в данном случае я-бы сделал например так:
Прогнал-бы с одним планом следующие запросы:

select * from table where a = 1 and b = 1
...
select * from table where a = 1000 and b = 1

далее перекомпилировал ХП, и загнал вторую порцию:

select * from table where a = 1 and b = 2
...
select * from table where a = 1000 and b = 2

и, наконец, снова перекомпилив:

select * from table where a = 1 and b = 3
...
select * from table where a = 1000 and b = 3


вот вам и только три плана, а не три тысячи. В любом случае, а не готов дискутировать по данному вопросу на серьезном уровне,
т.к. эта тема является для меня продвинутой. Если тут имеются более профессиональные люди, они вам ответят более конкретно и правильно.
1 янв 05, 14:11    [1224740]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
dwl

возможно в этой ветке упоминалось, но я не заметил. Оракл не блокирует операции чтения (если это не SELECT FROM UPDATE).

В этой ветке может и не говорилось, но на форуме много раз. Но только все много хуже. Читающий в MS SQL болкирует пишущего или грязное чтение. В Оракле грязное чтение исключено и пишущий не блокирует читающего никогда. Select for update - означает намерение писать, а не просто читать. Это известно под терминами блокировочник (MS SQL) и версионник (Oracle). Плюс у MS SQL эскалация блокировок у Оракла нет.

StalkerS

Oracle 9i явно уступает, а ведь он вышел
позднее mssql2000, т.е. выпушенный ORACLЕ продукт был хуже уже существующего на рынке ! Эта тенденция означает только одно,
yukon опередит 10g.

А я Вам скажу больше - у Оракла внутри одной версии полно релизов с заметными преимуществами перед предшествующими. Насчет хуже Вы хватили. Даже если бы он на каком-то запросе был медленнее, то этого мало чтобы быть хуже. У Оракла есть секционирование и мат представления, чтобы решать вопросы производительности на больших объемах в принципе, когда никакая оптимизация запросов никакой СУБД уже не поможет на том железе. А у MS SQL только кластериндексированные представления, которые ограничены по сложности запроса - если нужно сканирование всей таблы в запросе, то такое представление не допускается, как мне сказали здесь на форуме.
Кроме того, и алгориты выполнения запросов постоянно совершенствуются внутри одной версии, и есть битмап индексы.
Насчет, тенденции означающей только одно - это все-таки следует отнести к плохо скрываемой заинтересованности. Все-таки для тенденций в инфотехнолгиях нужны серьезные анализы, скорее всего не умещающиеся на одной странице. Кроме того, даже если бы она была эта тенденция, то она бы означала что-то с какой-то вероятностью отличной от 1. Более того, Вы сами пишете что версия позже, а мы видим, что этих версий у Оракла больше, т.е. у него выше частота версий. Какие выводы, по Вашему, отсюда следуют?
Если Вы пишете служебную записку как технический специалист, а не менеджер по рекламе, то лучше очистить ее от таких "выводов", чтобы не перечеркнуть ими доверие ко всему остальному тексту.
Кроме того, в кластерах - горизонтальное масштабрование, преимущество Оракла признают и апологеты MS SQL, и на этом форуме. Многоплатформенность (а это важный признак открытой системы) имеет значение.
Напишите в записке, что в принципе Оракл пока еще может и лучше по некоторым аспектом управления БД, но для Вашего проекта эти преимущества не имеют значения. Тогда это вызовет большее доверие к Вашей беспристрастности. (Для того, чтобы реально писать такие записки нужно быть спецом в обоих продуктах).
Вот Вам дали ссылку выше из которой видно, что MS SQL 2000 имел серьезные недостатки по сравнеию с Ораклом, но пытался их скрывать, и планировал преодолеть в MS SQL 2005. О чем это говорит? А такие служебные записки о примерной равности продуктов я и тогда видел. Зачем их повторять?
1 янв 05, 18:19    [1224873]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

Плюс у MS SQL эскалация блокировок у Оракла нет.


любимая тема у ораклистов. Тут кажется, каждый топик начинается с того, что кто-нибудь об этом упоминает. Для такой эсколации
необходимо некоторое количество условий, в которые входит большое число одновременных транзакций и корявая их реализация.
В любом случае Yukon будет обладать уровнем изоляции snapshot.
Кроме того, не стоит забывать, что версионность более требовательная к процессору и памяти сервера, так что применять этот уровень
нужно только в определенном ряде задач, а не поголовно. А вот кажется, оракл не так просто заставить вести себя как блокировочник.

vadiminfo

У Оракла есть секционирование и мат представления, чтобы решать вопросы производительности на больших объемах в принципе, когда
никакая оптимизация запросов никакой СУБД уже не поможет на том железе. А у MS SQL только кластериндексированные представления,
которые ограничены по сложности запроса


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

vadiminfo

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


Я имел ввиду производительность. Прогуляйтесь на 10 страницу этого топика, там я сделал небольшой анализ тестов tpc.

vadiminfo

Все-таки для тенденций в инфотехнолгиях нужны серьезные анализы, скорее всего не умещающиеся на одной странице


да какие там серьезные анализы, посмотрите те-же тесты tpc, каждая последующая версия любой СУБД быстрее предыдущей.

vadiminfo

а мы видим, что этих версий у Оракла больше, т.е. у него выше частота версий. Какие выводы, по Вашему, отсюда следуют?


а очень простые выводы : политика разная. А так новые версии хоть каждый месяц штамповать можно (но вот нужно-ли ?)

vadiminfo

Кроме того, в кластерах - горизонтальное масштабрование, преимущество Оракла признают и апологеты MS SQL, и на этом форуме.
Многоплатформенность (а это важный признак открытой системы) имеет значение.


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


vadiminfo

Напишите в записке, что в принципе Оракл пока еще может и лучше по некоторым аспектом управления БД


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

vadiminfo

что MS SQL 2000 имел серьезные недостатки по сравнеию с Ораклом, но пытался их скрывать, и планировал преодолеть в MS SQL 2005.
О чем это говорит?


это говорит о том, что вы высказываете свое личное мнение, не подкрепленное ничем, кроме как непонятно какой ссылкой
(подозреваю, что это та самая статья "Features, strengths and weaknesses comparison between MS SQL 2005 (Yukon) and Oracle 10g databases")
1 янв 05, 23:03    [1224936]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
vadiminfo
Select for update - означает намерение писать, а не просто читать. Это известно под терминами блокировочник (MS SQL) и версионник (Oracle). Плюс у MS SQL эскалация блокировок у Оракла нет.

Select for update в MS SQL тоже имеется - для подобного достаточно в запрос добавить хинт UPDLOCK. Этот уровень блокировки запись позволяет читать запись (разрешает накладывать разделяемую, shared,блокировку) но не позволяет накладывать другие такие же блокировки и бокировки изменения. В некоторых случаях полезно использовать для предотвращения взаимоблокировок.
Про эскалацию блокировок: у SQL Server есть возможность управлять этим процессом. Можно оставить по умолчанию, можно указать чтобы эскалация не происходила до тех пор пока блокировки занимают не более 40% доступной SQL Server-у памяти, можно вообще полностью отключить эскалацию блокировок.
2 янв 05, 00:35    [1224962]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS

любимая тема у ораклистов.

Вообще-то это любимая или важная тема в технологиях БД вообще. Моделям транзакций посвящается много литературы.

StalkerS

Для такой эсколации
необходимо некоторое количество условий

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

StalkerS

Кроме того, не стоит забывать, что версионность более требовательная к процессору и памяти сервера, так что применять этот уровень
нужно только в определенном ряде задач, а не поголовно

Что касается памяти - то у Оракла полно средств для точного определения необходимых ее размеров и часто получается на практике, что ее рекомендуется уменьшить. А MS SQL только собирается внедрять средства для динамического сбора статистики. Но уже ясно, что Statpack (отчеты с помощью которых можно следить за здоровьем БД) там не будет.

StalkerS

В любом случае Yukon будет обладать уровнем изоляции snapshot.


Бум ждать.

StalkerS

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

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

StalkerS

Я имел ввиду производительность. Прогуляйтесь на 10 страницу этого топика, там я сделал небольшой анализ тестов tpc.


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

StalkerS

да какие там серьезные анализы, посмотрите те-же тесты tpc, каждая последующая версия любой СУБД быстрее предыдущей.

Как раз тесты многое и не показывают. Например, в реальных сложных на практике запросах могут иметь значение алгоритмы их выполнения, которые не тестируются на этих тестах. Я уже не говорю, о том что писал выше - секционировании, мат представлениях, которые способны кардинально решать задачи для больших объемов данных на практике. В анализ при выборе СУБД много еще чего может входить. Например, если функционально бедное СУБД быстреей выполняет тестовый запрос на одной табле, то не факт, что лучше его выбрать, чем более развитое. Иначе есть шанс спроектировать не удачную систему, хоть и быстрее выполняющую какой-то один запрос.

StalkerS

а очень простые выводы : политика разная. А так новые версии хоть каждый месяц штамповать можно (но вот нужно-ли ?)

При стремлении к простым выводам всегда можно сделать ошибку. Почему, например, не сделать вывод, что они более адекватно реаигируют на новые достижения или потребности? Вот если версии редки, а в СУБД чего-то нет, то этого придется ждать долго, если версии редки. Это не мой вывод, а просто пример, что можно сделать и другие выводы. Значит вывод не однозначен, не строгий. Носит вероятностный характер. А Вы выдаете его за истинный.

StalkerS

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

Про горизонтальное масштабирование - кластера (не про вертикальное - просто купить более мощный сервак). Ну их легко найти. На этом форуме говорили про это. Это избитые вещи.

StalkerS

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

Не так уж и смешно.
Многоплатформенность - переносимость БД (одно из трех важных свойств открытых технологий). Вот, именно, что мне думать то как раз и не надо. Я просто перенесу БД. Думать надо, если этой многоплатформенности нет. У нас в одном проекте используются разные ОС (Вин, Линукс и Юикс - в разных филиалах заказчика и это не всегда наше решение). Сейчас больше пошли в сторону Линуксов - они дешевле. Проще фин сторона. Да и не я решаю на что съехать. Там полно решателей: и у нас и у заказчика. Мое дело удовлетворять требованиям.
Но мне то все равно. Я БД разрабатываю хоть под виндами, хоть под линуксом, а поставить ее можно хоть на юникс. Например, нашу систему купили в Литве, но потребовали, чтобы она была под Open/VMS. Я не знаю что это, хотя система у них уже введена в пром эксплуатацию. А Вы говорите смешно. Был бы на MS SQL не до смеху было бы. Потеря такого заказа.

StalkerS

Когда в microsoft принимали решение только о поддержке windows, там наверно проводили какие-нибудь анализы по этому поводу, и вывод
который был сделан, отражает действительную ситуацию.


Конечно, проводили и проводят политику на захват рынка виндами. Но им неожиданно ответило сообщество, создав Линукс. А Вы в курсе, что в Европе уже сложности по распроранению ВИндов из-за этого? Они там скряги все. И зачем нам быть заложниками их решений. Они рискуют - это их дело. А мы то с Вами здесь причем? Мы просито знаем, что это наша или не наша проблема в зависимости от выбранной СУБД.

StalkerS

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


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

StalkerS

это говорит о том, что вы высказываете свое личное мнение, не подкрепленное ничем, кроме как непонятно какой ссылкой
(подозреваю, что это та самая статья "Features, strengths and weaknesses comparison between MS SQL 2005 (Yukon) and Oracle 10g databases")

Да личное. Подкрепленное и этой ссылкой в том числе. У меня есть образование по инфосистемам, читаю толстые книги, общаюсь на этом форуме, читаю ссылки и вообще слежу за подобными вопросами. Но, конечно, это всего лишь мои мысли, которые я высказываю Вам, своему коллеге. И нахожу наше общение полезным и для своего кругозора.
2 янв 05, 00:58    [1224969]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
В письме, которое вызвало Ваш ответ, я указал, что говорю с чужих слов и дал ссылку на обсуждение, в котором участвовали специалисты по MSSQL. Соответственно, я не вижу ничего ужасного в своих действиях.

Примите искренние извинения, если воспринято, как попытка наезда :)
IMHO, обсуждать, а тем более - осуждать, "кишки" любого сервера - дело достаточно бессмысленное. Согласитесь, что обычно, за исключением OpenSource-проектов, они представляют собой "черный ящик" и можно лишь, с той или иной степенью вероятности, догадываться, о его реализации. Для разработчиков БД, понятие о ней формируются на основе документации и экспериментов. Понятное дело, что оба способа базируются на полноте того и другого, не брезгуя логикой, если таковая присутствует, и эрудицией, начиная с институтского образования и продолжая чтением соответствующей литературы. Вывод из этого нудного вступления простой: наши знания о СУБД как разработчиков БД не могут являться абсолютно точными в принципе, а являются лишь нашим представлением о них. Поэтому хотелось лишь уточнить, что нельзя переносить некоторое знание об одной системе на другую, и нельзя быть уверенным на 100% в правильности понимания даже "свой" СУБД.
Признаю свою горячность, когда вижу разного рода утверждения, не подкрепленные, хотя бы, личным опытом, а являющиеся лишь отражением отражения Особенно, когда таковые озвучиваются вполне грамотными специалистами, к коим причисляю и Вас. Если бы это было не так, я бы не среагировал на Ваше утверждение, как и поступаю в отношении некоторых других, часто просто невменяемых личностей, бывающих на этом форуме.
softwarer
Если Вы считаете по-другому - пожалуйста, выясните таки, кто из вас неправ, и расскажите мне. Я достаточно часто спрашиваю - как оно работает - и уже не в первый раз натыкаюсь на то, что вроде бы специалисты по MSSQL говорят противоречащие друг другу вещи и далеко не сразу приходят к согласию. Собственно, то обсуждение, на которое дана ссылка - пример такого; если грубо, они сначала поназывали друг друга ламерами, потом таки решили как оно на самом деле работает, и выяснилось, что изначально каждый был в чем-то неправ.
Выяснять, кто прав, а кто не прав, исходя из вышесказанного, не вижу смысла, как обычно, каждый "видит" свою часть слона. Рассказывать, по той же причине, также не вижу смысла, ибо знания мои тоже, не более чем, крупицы здравого(надеюсь) смысла, полученные в процессе эмпирического познания. На некоторые конкретные(!) вопросы могу попытаться ответить, но на достоверное понимание "черного ящика" претендовать не смею. Думаю и Вы не сможете позволить себе такую роскошь в отношении Oracle, с которым Вы, как я понимаю, во вполне неформальных отношениях.
Касательно обсуждения, ламеров и иже с ними. Это говорит только о личностных качествах участников дискуссии, не более того. В форумах очень часто предпринимаются попытки поднятия своего "авторитета" путем опускания чужого, что весьма прискробно на мой взгляд, но избежать этого, увы, невозможно. И хорошо, если это только следствие горячности, а не "гнутие пальцев", что присуще определенной категории лиц. В таковом случае, дискуссия, в принципе, носит бесмысленный с познавательной стороны характер и часто вырождается в монолог, который время от времени пытается нарушить очередной посетитель форума.

P.S. C уважением ;)
2 янв 05, 03:30    [1224984]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
c127
Guest
2 StalkerS

>а теперь посмотрим, что по этому поводу думают эксперты, написавшие труд "Features, strengths and weaknesses comparison between
MS SQL 2005 (Yukon) and Oracle 10g databases":


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

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

Еще полезно сравнить функциональность, заявленную в начале работы над проектом, в частности mssql2005, (мы совершим революцию и переворот в СУБД) и функциональность, полученную в результате (революция безусловно свершилась, но почему-то заметна узким только специалистам, да и то не всем, а только заинтересованным в ней материально).

2 softwarer

>То, что sequences мощнее identity, тривиально математически доказать: с их помощью тривиально реализовать identity, но с помощью identity довольно затруднительно реализовать sequences. Не скажу "невозможно" - но механизм получится громоздким и практически бессмысленным.

Если подходить чисто теоретически, то это неверно. Создать и использовать аналог sequence в MSSQL-e не сложнее, чем сам sequence в оракле. Вместо create sequence можно использовать create table xxx (id identity); и когда нужно получить следующее значение sequence просто добавлять туда строку и читать значение "id" с помощью @@identity. В скирптах и сохраненках это работает так же, как и sequence.

Но я согласен, что sequence удобнее и более логичный, чем identity. Например если триггера добавляют строки в несколько (>2) таблиц, имеющих поле identity, то непонятно (не по документации, а логически) что вернет @@identity после такого добавления и как получить, например, значение identitiy во второй таблице.
2 янв 05, 03:39    [1224986]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
c127
Создать и использовать аналог sequence в MSSQL-e не сложнее, чем сам sequence в оракле. Вместо create sequence можно использовать create table xxx (id identity); и когда нужно получить следующее значение sequence просто добавлять туда строку и читать значение "id" с помощью @@identity. В скирптах и сохраненках это работает так же, как и sequence.


Я не специалист по MS SQL, но по моему мнению, такое решение будет НЕ МАСШТАБИРУЕМЫМ (в смысле большого количества конкурирующих транзакций). Тогда как sequence в Oracle в первую очередь решают именно эту задачу. Вы фактически создаете себе "бутылочное горлышко".
2 янв 05, 09:10    [1224999]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

В общем случае достаточно и одного - сервер увидел что требуется заблокировать больше одной записи - заблокировал все таблицу


Теперь я начинаю понимать, откуда такие мнения о mssql у ораклистов. В SQL-Server блокировки могут накладываться на следующие обьекты :

-cтрока
-ключ
-страница
-экстент (содержит 8 страниц)
-таблица
-база данных

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

vadiminfo

Что касается памяти - то у Оракла полно средств для точного определения необходимых ее размеров и часто получается на практике


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

vadiminfo

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


чем хуже-то ? Можете сказать ? Иногда, добавление одного столбца в таблицу может отменить потребность в обьединении нескольких таблиц.
У меня такое было пару месяцев назад, когда добавив один единственный столбец (вычисляемый в триггере), сбросил время запроса к этой
таблице с 20 сек. до 40 мсек.
А всякие там суммы могут присутствовать в индексированном представлении. Запрещены AVG, MAX, MIN, STDEV, STDEVP, VAR и VARP. Из них
только 2 функции (min и max) просто так нереализуемы, остальные можно заменить другими функциями (например AVG заменяется на SUM
и COUNT_BIG).
И вообще, как-будто в оракле материализованные представления идеальны. Я вот слышал, что такое представление там обновляется не при
изменении таблиц, лежащих в его основе, а по таймеру. Если это так, то как вы там боретесь с неактуальными данными - непонятно.

vadiminfo

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


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

vadiminfo

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


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

vadiminfo

При стремлении к простым выводам всегда можно сделать ошибку. Почему, например, не сделать вывод, что они более адекватно реаигируют
на новые достижения или потребности? Вот если версии редки, а в СУБД чего-то нет, то этого придется ждать долго, если версии редки.
Это не мой вывод, а просто пример, что можно сделать и другие выводы. Значит вывод не однозначен, не строгий. Носит вероятностный
характер. А Вы выдаете его за истинный.


Где там у меня написано про истину ? Это как раз вы, заведя речь о частоте выхода, пытались мне что-то доказать, я только не понял что.

vadiminfo

Но мне то все равно. Я БД разрабатываю хоть под виндами, хоть под линуксом, а поставить ее можно хоть на юникс. Например, нашу систему


Когда разрабатывается система, совершенно четко решается вопрос, на какой платформе она будет работать. Если это *nix, то оракл,
если винда - mssql или оракл. Но, рассматривая последний вариант, говорить о плюсе оракла, т.к. вдруг через год мы захотим поработать
в линуксе, а потом в sun ? Это не плюс оракла, а минус того инженера, который админит базу.
Да, microsoft потеряла часть клиентов, которые по определенным причинам работают только в *nix. Зато приобрела всех тех, кто
использует Windows, т.к. многоплатформенность имеет и минусы, такие как разный набор багов под каждой системой. И что вы собираетесь
делать, если вам завтра позвонят из Литвы, и спросят про баг в работе, с которым вы не сталкивались при разработке проекта в *nix ?
Пойдете искать форумы по Open/VMS ? Или будете его сами ставить и исследовать ?

vadiminfo

Но им неожиданно ответило сообщество, создав Линукс


давайте не будем про сообщество единомышленников, самоотверженно борящихся с microsoft во имя мира во всем мире. Они не могут противостоять
мощной корпорации, вкладывающей немыслимые деньги в разработку. Это чистая математика. На microsoft работают огромные научно-исследовательские
институты, и кучка людей работающих за бесплатно их никогда не опередит. То, что многие используют линукс - дань моде, ведь если ты
линуксоид - то ты КРУТ. То, что множество web сайтов используют *nix обьясняется меньшим числом вирусов в инете, а не функциональностью.
Уверяю вас, если бы ситуация была противоположная, и везде использовался линукс, то на него тоже-бы со всех сторон сыпались проклятия
из-за тучи вирусов и багов.
2 янв 05, 11:38    [1225024]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS

оракл мне вежливо скажет - "подвали-ка мне еще
гиг оперативки", мне легче не станет.

Пусть лучше промолчит? Так он и промолчит, но есть средства понять какие события чаще всего ждет система, число промахов в кэшах и т.д. В MS SQL 2005, насколько я понял, тоже это оценили. А что касается ресурсов, то если БД растет, то насколько сильно на это влияет версионность по сравнеию с другими потребителями ресурсов еще надо смотреть. В технологиях БД пошли еще дальше в плане версионностей. Вы можете из экономии ресурсов выбрасывать многие достижения инженерной мысли в области моделей транзакций, но чаще отдают предпочтения функционалу. А так могли бы и в Досе сидеть с эконмичными системами. Клиппер в этом плане точно много лучше.

StalkerS

чем хуже-то ? Можете сказать ? Иногда, добавление одного столбца в таблицу может отменить потребность в обьединении нескольких таблиц.

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


StalkerS

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

Актуальность данных определяется требованиями пользователя. Я говорил о принципиальной возможности получить быстрый результат читающего на больших данных. Конечно, если требования получать данные в течении милисикунд после последего коммита, то этот метод может не подойти. Но разве кластерный индекс за такое время перестроится, если нужны средние в много гигобайтных таблах. Какая вообще актуальность, если запрос выполняется 15 минут? За это время многое в табле изменилось. Просто пользователь не ждет 15 минут - комп не замирает при нажатии кнопки. Мат представления используются и при репликации по схеме "Ведущий - ведомый" в распределенной БД. Они бывают инкрементные, если не нужен запрос к полной табле или полные. С помощью таймера можно управлять актуальностью. Если нужно точность за сутки - зачем напрягать систему чаще?

StalkerS

Да и про фичность, это знаете-ли спорный вопрос. Фичность - заложник времени
выхода продукта.

Хотел бы я посмотреть на то, что у СУБД нет какого-то функционала, а он нужен, то что Вы будете делать, и сколько это времени займет. Ну, Клиппер быстрей в Досе, чем Оракл вместе с MS SQL, хоть вместе взятые, хоть по отдельности.

StalkerS

Где там у меня написано про истину ? Это как раз вы, заведя речь о частоте выхода, пытались мне что-то доказать, я только не понял что.



Ну разве не Вы сделали выводы о тенденции, которая означает только одно - Юникон будет лучше Оракла 10 или простые выводы о разной политике?
Я не пытался доказать, скорее высказал сомнения в Ваших выводах о том, что из того, что у MS SQL более ранняя версия и она уже, якобы лучше (что не яваляется общепризнанным, а тесты в разное время показываю разное), то Юникон будет лучше. Раз у Оракла чаще версии, значит есть шанс, что они могут оказаться более актуальными в силу сложившейся ситуации в инфотехнологиях на данный момент: появляются новые задачи, новые потребности, новые решения. Т.е. Ваши эти выводы пока подходят только для тех, кто в них заинтересован. В техничексих ссылках их не видел, даже производители продуктов много более осторожны в выводах. Они часто ограничиваются только пречислением своих преимуществ, которых достигли.

StalkerS

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

Не только в домашних, но у заказчика можно оценить позволяет ли система решать задачи с производительностью, которая прописана в требованиях пользователя. А что касается tpc, то он может измениться в другую сторону в период, когда Ваша записка еще не потеряет актуальности. Ее посмотрят и посмотрят на тесты и они не совпадут. Что будете делать?

StalkerS

Когда разрабатывается система, совершенно четко решается вопрос, на какой платформе она будет работать. Если это *nix, то оракл,
если винда - mssql или оракл. Но, рассматривая последний вариант, говорить о плюсе оракла, т.к. вдруг через год мы захотим поработать
в линуксе, а потом в sun ?


Четко он решается, когда СУБД не переносима. А так в требованиях к системе можно заранее ОС не прописывать как обязательное ограничение. Более того, после разработки системы пользователи в плане ОС могут изменить требования (личное наблюдение). Заказчик решил передать администрирование системы на свое
АСУ, а те выдвинули требование. Второй вариант - систему захотели купить другие заказчики. Тоже с требованием к ОС. Третий вариант - руководство решило использовать на серваке линукс по фин соображениям или каким-то другим.
И это плюс любой переносимой системы. Зачем это прописали в понятии открытой технологии? А сами такие технологии к тому, к чему нужно стремиться? Разве это не удобно - не зависеть от производителей ОС? Разве не удобно не думать об ОС вообще при разработке. Все-таки это не прикладной аспект данной задачи. Или Вы собираетесь навязывать закачику еще и преимущества конкретной ОС? Не рациональная трата ресурсов и риск потерять заказчика. У них может быть политика против Виндов, например. Их асубщики доказали уже руководству своему все про нее, а Вы будете переубеждать? Восхищаюсь, но не завидую.


StalkerS

И что вы собираетесь
делать, если вам завтра позвонят из Литвы, и спросят про баг в работе, с которым вы не сталкивались при разработке проекта в *nix ?
Пойдете искать форумы по Open/VMS ? Или будете его сами ставить и исследовать ?


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



StalkerS

давайте не будем про сообщество единомышленников, самоотверженно борящихся с microsoft во имя мира во всем мире. Они не могут противостоять
мощной корпорации, вкладывающей немыслимые деньги в разработку. Это чистая математика. На microsoft работают огромные научно-исследовательские
институты, и кучка людей работающих за бесплатно их никогда не опередит. То, что многие используют линукс - дань моде, ведь если ты
линуксоид - то ты КРУТ. То, что множество web сайтов используют *nix обьясняется меньшим числом вирусов в инете, а не функциональностью.
Уверяю вас, если бы ситуация была противоположная, и везде использовался линукс, то на него тоже-бы со всех сторон сыпались проклятия
из-за тучи вирусов и багов.


Шутите? Что же мы будем с якобы чистой математикой отрицать факты, которые уже видны. А кто такие эти противостоящие? Хакеры - энтузиасты? А Вы знаете, что любитель в своей узкой области может превзойти профессионала за счет любви к тому, что делает? Разве Линукс зародился не в университетских кругах. И сколько этих хакеров принимает в нем участие? Разве у него не открытой код? Его не могут анализировать те, кому это интересно в данный момент, и кто не обременен необходимостью что-то выполнить в назначенный срок (в отличии от работников фирмы)? Все, по моему, не так просто. Это явление, не считаться с которым было бы проявлением большой беспечности. Так или иначе он занял уже какую-то нишу, и microsoft вынужден тратить деньги на борьбу. А ведь эти деньги могли пойти на развитие MS SQL. Это тоже какая-никая математика.
А что касается вирусов и багов, то тут то как раз и поле деятельности для всевоможных хакеров - коды то открыты. Им только этого и надо для полного счастья. Так что и тут, скорее всего, пока еще нельзя прийти ни к какам определенным выводам.
2 янв 05, 15:35    [1225077]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
для справки materialized view может обновлятся не только по таймеру но и непосредственно в момент изменения табличек.

>Теперь я начинаю понимать, откуда такие мнения о mssql у ораклистов.

это сказки для самых маленьких, про эскалацию вот тут было такое обсуждение:
https://www.sql.ru/forum/actualthread.aspx?bid=1&tid=71533
может с тех пор кто-то изобрел чудесные способы чтоб как-то повлиять на эскалацию ?
2 янв 05, 16:52    [1225097]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

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


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

vadiminfo

Я не отрицаю необходимость денормализации, но как необходимое зло ради оптимизации всей системы. Но чем меньше это зло, тем лучше


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

vadiminfo

Хотел бы я посмотреть на то, что у СУБД нет какого-то функционала, а он нужен, то что Вы будете делать, и сколько это времени займет.
Ну, Клиппер быстрей в Досе, чем Оракл вместе с MS SQL, хоть вместе взятые, хоть по отдельности.


да, пожалуйста, покажите мне функционал, отсутствующий в msslq но присутствующий в оракл, и какие это будет иметь последствия.
Вот этот топик начинался с того, что автор, утверждал, что для баз, использующих древовидные структуры, нужен только оракл, так как
у него есть встроеный механизм работы с деревьями, а у mssql нет. Меня это сильно заинтересовало, так как как раз я делал базу,
которая только и делает, что работает с деревьями. Я привел свой запрос, делающий то-же самое, что и встроеная фича в оракл.
Результаты выглядели так : у меня на тестовых данных он отрабатывал 120 мсек.(Duron 1.2, 128 RAM), у автора топика встроеная
фича работала 15 мсек. (двухпроцессорный Ксеон, 4 гига оперативки).
Какой-же вывод ? Наверно такой, что профи в одной системе (я кстати себя к профи не причисляю) решит задачу и без фичи, и работать
она будет не хуже. Исключением является серьезный функционал, типа полнотекстового поиска, такое самому решать не надо. И тут действительно
нужно выбирать соответствующущий сервер. Однако никто здесь еще не показал мне такую фичу в оракле.
Зато в mssql к примеру, по многим высказываниям, системы поддержки принятия решений на голову выше оракловских. Хотя это с чужих слов,
так что утверждать небуду.

vadiminfo

Ну разве не Вы сделали выводы о тенденции, которая означает только одно - Юникон будет лучше Оракла 10 или простые выводы о разной политике?


так я и употребил слово "тенденция", оно означает некоторую вероятность по определению. Если вы несогласны, что новые версии лучше
предыдущих, так это ваше право, переубеждать небуду.

vadiminfo

Не только в домашних, но у заказчика можно оценить позволяет ли система решать задачи с производительностью, которая прописана в требованиях пользователя


тесты tpc вообще-то предназначены для сравнения разных систем, а не для выяснения, годиться ли эта система под конкретную задачу.

vadiminfo

Четко он решается, когда СУБД не переносима. А так в требованиях к системе можно заранее ОС не прописывать как обязательное ограничение.
Более того, после разработки системы пользователи в плане ОС могут изменить требования (личное наблюдение). Заказчик решил передать
администрирование системы на свое
АСУ, а те выдвинули требование. Второй вариант - систему захотели купить другие заказчики. Тоже с требованием к ОС. Третий вариант -
руководство решило использовать на серваке линукс по фин соображениям или каким-то другим.


Если есть хоть доля вероятности, что платформа измениться, mssql использовать нельзя. Только вот все-таки не такое-уж это частое
явление. Если вы работаете в такой компании, не обобщайте ситуацию на всех остальных. И даже в случае с продажами, основным
требованием является все-таки СУБД, а не платформа. Такие требования сочиняют специалисты, которые в будущем будут за нее отвечать,
и если они ораклисты - ясень пень напишут оракл, mssql'сты - sql server. А ОС здесь - побочный фактор.
И что значит начальство захочет сменить платформу ? Начальство даже файл с дискеты распечатать не может, а уж такие страшные слова как
кроссплатформенность и вообще повергнут их в панику. Все такие решения принимаются фактически тех. специалистами.
А уж они выберут то, с чем умеют работать, и никакие плюсы от кроссплатформенности здесь ни на что не повлияют.
Кстати, что вы заладили что линукс бесплатный ? Готовый дистрибутив (red hat например) нифига не бесплатный, а качать открытые исходники
и компилировать их - занятие не для слабонервных. Если вы не эксперт в этом, то такое можете наделать, что даже незнаю ;)

vadiminfo

Литвы пока не звонили - мы не такие дураки, чтобы не проверить все на баги


баги тоже не дураки, умеют прятаться ;)

vadiminfo

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


А мне, знаете-ли, тоже ставят сроки, и я даже (представьте себе !) получаю деньги на работе, но вот люблю свою профессию, а не то
не стал-бы сидеть тут и набивать весь этот текст. Зато придя с работы, я вряд-ли буду сидеть еще всю ночь, разрабатывая линукс,
даже если-бы любил его сильнее себя самого.
Любовь, к сожалению, денег не приносит, и когда вы весь день торчите на работе, сильно сомневаюсь, что обгоните windows, работая
по ночам.

а факты, они видны. Винда везде, линукс - либо у фанатиков, либо у людей, имеющих серьезные причины работать с ним (например web
сайты).

Тем более, что близится выход Longhorn, так что разрыв еще сильнее увеличиться ;)
2 янв 05, 18:47    [1225133]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
StalkerS

а факты, они видны. Винда везде, линукс - либо у фанатиков, либо у людей, имеющих серьезные причины работать с ним (например web
сайты).


За всех когда перестанем говорить?


Тем более, что близится выход Longhorn, так что разрыв еще сильнее увеличиться ;)


Юкона дождитесь для начала. На этом форуме им уже года два пугают, а толком никто не видел, не говоря уже о продакшн.


PS "А мой папа твоего папу..." (с) Rush Hour
2 янв 05, 19:28    [1225154]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
c127
Guest
2 Gluk (Kazan)

>Я не специалист по MS SQL, но по моему мнению, такое решение будет НЕ МАСШТАБИРУЕМЫМ (в смысле большого количества конкурирующих транзакций). Тогда как sequence в Oracle в первую очередь решают именно эту задачу. Вы фактически создаете себе "бутылочное горлышко".

Мсаштабируемость этого решения совпадает с масштабируемостью MSSQL сервера. Такая таблица это обычная таблица с полем identity со всеми преимуществами и недостатками в смысле блокировок. Если проблем с полем identity в обычных таблицах нет, то и в моем примере их тоже не будет.

Еще одна проблема, кроме триггеров, это то, что identity имеет максимум тип int, если я не ошибаюсь, и в сулчае больших таблиц будет переполнение. sequence можно определить с типом numeric.
4 янв 05, 01:10    [1225906]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
c127
identity имеет максимум тип int, если я не ошибаюсь
Слава Богу, ошибаетесь :) Конечно, может быть и numeric, tinyint и т.д.
4 янв 05, 01:14    [1225907]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS

Вот к примеру, OLAP базы.

Так в OLAP и не реляционная модель. Там есть два подхода ROLAP и MOLAP. Во втором вообще многомерный формат. В первом используются рел таблы и может использоваться нормализация. Оракл поддерживает оба подхода (ROLAP и MOLAP).

StalkerS

Если я вижу, что добавив столбец

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

StalkerS

Какой-же вывод ? Наверно такой, что профи в одной системе (я кстати себя к профи не причисляю) решит задачу и без фичи, и работать
она будет не хуже.


Обыкновенно в инфотехнологиях делается другой вывод - фитча не поддерживается. Можно и на С использовать ООП, но какой ценой. Потому что он не поддерживает ООП. А С++ поддерживает ООП. Там это проще.

StalkerS

тесты tpc вообще-то предназначены для сравнения разных систем, а не для выяснения, годиться ли эта система под конкретную задачу.

Для оценки некоторой производительности на конкретных для Банков операций. Ну посмотрел эти тесты. По производительности тест Оракла на HP Integrity rx5670 (16 node x 4-way) - 1,184,893.38 (кластер, что мы выше говорили - горизонтальное масштабирование), HP Integrity Superdome (64-way) - MS SQL - 786,646.62 на 30% хуже. Оракл HP Integrity Superdome (64-way) - 1,008,144.49 все равно на 22% лучше.
Причем в кластере 16 компов по 4 проц объеденены в кластер (тоже всего 64 процессора, т.е. сравнение относительно корректно). Известно, что такие маломощные компы объдиненные в кластер дешевле одного эквивалентного им всем.
Лидирует вообще DB2 8.2 на IBM eServer p5 595 (64-way), т.е. самом наворченом майнфрейме той же фирмы что и СУБД. У остальных на такой системе нет тестов.
По Price/Performance там в основном стандарт эдишены на более простых системах. Они интереса почти не представляют (такие в реальных банках наверное и не используются). Не знаю какие такие выводы о преимуществе MS SQL 2000 Вы нашли. Лично для меня это значит, что они все в тройке, и что они вообще что-то делают для усовершенствования оптимизаторов запросов и всего такого. Думаю, эти результаты еще поменяются.
Вот если в десятку не входит - это повод обратить внимание. И то некоторые возможно и не участвуют. Я читал, что ООСУБД на конструкторских задачах (тест ОО1) сделали РСУБД (Ингрес и Сибэйс) в 1989 и 1990 годах в 30 раз. И что же теперь? Какие выводы?

StalkerS

требованием является все-таки СУБД, а не платформа.

Особенно если СУБД не зависит от платфоры. А так получается, что и платформа. Из-за нее могут отказаться и от СУБД. Это не так не реально. Заказ в Литве бы точно не прошел, и вообще за границей уговорить кого-то не просто. В других местах, думаю, удалось бы навязать и платформу, но с большими усилиями. А зачем это надо? Терять время, вызывать отрицательное ко всей системе в целом у тех сис админов заказчика, кто, например, не навидит винды. Я и таких встречал.

StalkerS

Зато в mssql к примеру, по многим высказываниям, системы поддержки принятия решений на голову выше оракловских. Хотя это с чужих слов,
так что утверждать небуду.

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

StalkerS

а факты, они видны. Винда везде, линукс - либо у фанатиков, либо у людей, имеющих серьезные причины работать с ним (например web
сайты).

Тем более, что близится выход Longhorn, так что разрыв еще сильнее увеличиться ;)



Мы ставим его последнее время на серваках. Правда, я не знаю почему. Так решил топ менеджмент или его часть (технический директор). Они не фанатики и web сайты как таковые мы не делаем (так - альтернативный доступ к отчетам). Т.е. не основное.
Насчет Longhorn впервые узнал от Вас. Спасибо за инфу. Буду интересоваться.
4 янв 05, 02:13    [1225924]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
vadiminfo

Но мы с Ваших слов видим, что в MS SQL это чаще и больше надо делать


Вам нет равных в интерпретации моих слов !

vadiminfo

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


Индексированное представление и денормализация базы - это два разных инструмента повышения производительности базы. В одном случае
нужна денормализация, в другом - инд. представление. Да, в mssql на такие представления накладывается ряд условий, типа запрещения
некоторых операторов (count(*), distinct, union). Однако они не могут серьезно ограничивать использование представлений. Например, если
позарез нужно слить два запроса, так я создам два инд. представления, и построю запрос уже к ним, добавив этот union.
Зато, mssql позволяет использовать такие представления даже косвенно, т.е. если оптимизатор запроса видит, что какой-то запрос может
получить выгоду от использования этого представления (а вы об этом даже не подозреваете), так он его использует. А в оракл, насколько
знаю, материализованные представления участвуют в запросе, если только оно явно указано в предложении from.
И как там насчет обновления по таймеру ? Вы это вроде подтвердили, а как быть с этим :

Yo!

для справки materialized view может обновлятся не только по таймеру но и непосредственно в момент изменения табличек.


вы уж там как-нибудь определитесь, а то странно видеть высказывания типа :

softwarer

и уже не в первый раз натыкаюсь на то, что вроде бы специалисты по MSSQL говорят противоречащие друг другу вещи и далеко
не сразу приходят к согласию



vadiminfo

Обыкновенно в инфотехнологиях делается другой вывод - фитча не поддерживается. Можно и на С использовать ООП, но какой ценой.
Потому что он не поддерживает ООП. А С++ поддерживает ООП. Там это проще


Я вам потому и сказал, что серьезный функционал является исключением. А то, что продукт перегружен миллионом мелких фич еще ни о чем не говорит.
Ведь что-бы эффективно пользоваться этим миллионом, надо достаточно хорошо изучить продукт. Т.е. потратить массу времени на его изучение.
Это означает, что если вы изучаете оракл только месяц, то скорее всего и знать не будете о встроенной поддержке древовидных структур.
А когда вы - специалист, то без труда справитесь с деревьями и без встроенных фич.

vadiminfo

Не знаю какие такие выводы о преимуществе MS SQL 2000 Вы нашли


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

vadiminfo

А так получается, что и платформа. Из-за нее могут отказаться и от СУБД


ну дык вы отдаете-то свой проект в безвоздушное пространство что-ли ? Там сидит человек, который будет его админить. Вот он-то и заказывает
музыку, хочет - оракл, хочет - mssql. И именно это является главным фактором.
И вообще, не обобщайте свою ситуацию на других, если вы их готовите на продажу, то мы - для внутреннего пользования, и утверждать, что
необходим оракл, т.к. возможно какому-нибудь придурку через пару лет захочется сменить платформу - смешно.
И одновременно печально. Т.к. если этот придурок окажется влиятельным, так все равно протолкнет линукс и заставит переписать базу под
оракл, не обращая внимания на денежные и временные затраты.
4 янв 05, 23:34    [1226876]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
с127
Guest
2 ChA

c127> identity имеет максимум тип int, если я не ошибаюсь
>Слава Богу, ошибаетесь :) Конечно, может быть и numeric, tinyint и т.д.


tinyint меньше int, так что остается numeric. Спасибо за информацию. А в MSSQL 7.x можно было объявить identity типа numeric? Помню столкнулся с какими-то проблемами с большими числами в identity, но это было до MSSQL2000.
5 янв 05, 01:31    [1226921]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить