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

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

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

А что Вы тогда хотели компенсировать денормализацией, кода реч шла только о мат представлениях и индексированных представлениях MS SQL?


StalkerS

А в оракл, насколько
знаю, материализованные представления участвуют в запросе, если только оно явно указано в предложении from.


У Вас не верные сведения. У Оракла есть механизм переписывания запросов, и он подставит мат представление, если оптимизатор определит пользу от этого.


StalkerS

И как там насчет обновления по таймеру ?

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

StalkerS

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

Ну, если поддержка тех или иных фич ни о чем не говорит, тогда я не знаю. Это идет против всего течения в подходах к разработке в инфо технолгиях. Это сродни механизму кеширования. Сначала ищем фичу, а потом уже сами стряпаем, если не нашли. Фича всегда должна быть лучше ручного подхода с помощью меннее подходящих фич.
Мастерство и состоит в том чтобы найти лучшее решение, т.е. ,например, найти фичу.
Это не моя идея. Как бы основа профессии. А если фича черная кошка, которй нет, тогда другое дело. Недостаток системы, нуждающийся в устранении. Оракл учитывает пожелания. Отсюда и фичи.

StalkerS

Это означает, что если вы

Опять вывод. У Вас склонность простым способам получать выводы. Представляете в если бы в мат анализе так теоремы доказывали. Сколько бы их разных и противоречащих друг другу было.

StalkerS

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

Посмотрел 10 страницу. С точки зрения мат статистики он, наверное, далек от идеала. И факты подобраны не полно. Например, 10g участовоавал в 2003 в тестах, а Вы говорите, что появился он только в этом году. Сравниваете 9 Оракл с 10, и пп. 19 и 20 и не обращаете внимания на пп 18, где тоже 9, но указано - 9.2.0.1, а есть 9.2.0.4 только нет на той системе. Какая это была 9? Самая первая? И на дату в полтора года не обращаете внимания, а за это время и ОС могла усовершенстваться на которой тесты, не говоря о СУБД. Делаете вывод о зависимости от системы, сравнивая 136 и 137, и не обращаете внимания, на пп 141-145, где MS SQL 2000 сам с собой "сравнивается" и показатели говорят, что не только от системы все зависит (он тогда по такой логике сам лучше себя или хуже: по цене улучшился, по производительности ухудшился). Вообще даты не учитываете.
Да и там где рассуждаете о процентах не учитываете абсолютную величину в двух сравнениях. А 7% от 309036.53 впечатляет меньше чем 12% от 1008144.49
Вообще, Вы смело взялись за анализ этих тестов. Неужели Вы всерьез верите в правильность этого анализа? Я вот не видел методик, чтобы делать ошарашивающие выводы по этим тестам.

StalkerS

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

Там сидит много человек. И, например, есть какие-то договоры и системы других производителей. И там может быть прописана ОС и админы под нее. Там сеть и много уже свое есть. И заказывают они прикладную систему. Зато часто админов по БД то и нет еще там. И уже не всегда он заказывает.
Что значит на продажу, но не для внутреннего пользования? Если Вы сами для себя делаете, то зачем вообще глобально сравниваете СУБД на все случаи жизни? У Вас внутри разногласия? Вы то лично уже решили для себя - MS SQL. Но хотите это обосновать? Помоему это лучше делать в устной форме. А служебной записке писать как я Вам говорил. Иначе можно подставиться. Это документ - не вырубишь потом и топром. А Ваши выводы содержат, скорее всего, изъяны. Впрочем, это Ваше решение.
Для внутреннего использования обычно выбирают исключительно исходя из наличия специалистов или личных пристрастий. И это, возможно, оправдано.
Вот Вы говорите то это смешно, то это печально. Придурку или нет, но влиятельному.
Я вот Вам и говорю про удобство переносимости, чтобы не зависить от влиятельных, а заодно ит производителя ОС. Все-таки это системная вещь, и зависеть от нее не лучшее из лучшего. Это известно из курса "Открытые системы", а Вы спорите с этим. Тут, мне кажется, Вы как бы проявляете настойчивость, объяснимую только желанием подогнать результат по "нужные" выводы.
5 янв 05, 03:07    [1226936]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
с127
tinyint меньше int, так что остается numeric
tinyint упомянуто по приколу :), мало ли, кому-то понравится...
с127
А в MSSQL 7.x можно было объявить identity типа numeric?
Сейчас точно не помню, "давненько не брал в руки шашек", но на 99.(9) уверен, что можно было. Скорее всего, проблема была в чем-то другом, впрочем, как я понимаю, это уже давно не имеет значения...
5 янв 05, 03:28    [1226946]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
StalkerS
softwarer

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

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

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

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

StalkerS
Можно подняться на виток выше, и рассматривать ситуацию с более высокого уровня. С этого уровня мы и в самом деле сможем увидеть,

Не имеет смысла опускаться на уровень, с которого мы сможем увидеть только нечто, не имеющее отношения к реальности. Это именно что "ощупывание слона по кусочкам".

StalkerS
Поэтому, в данном случае я
занимаю позицию вида : "На нижнем уровне обсуждения, аргумент, что дыр больше, является и самом деле аргументом,

Ну тогда для начала докажите таки, что их больше :) Хотя, с моей точки зрения, этим Вы не обоснуете ничего, кроме этого.

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

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

Ээ.. Простите, где относят к недостаткам?

Давайте я напишу так (это пример, так что давайте не придираться): полезной в java вещью являются интерфейсы. В C++ их нет (и нафиг не нужны), поскольку есть (более сложный и более мощный) механизм множественного наследования.

Вы сделаете из этого вывод, что отсутствие интерфейсов - недостаток C++? Хм, "ну делайте" - все, что могу сказать.

StalkerS

Вот еще одно мнение :
http://www.interface.ru/fset.asp?Url=/forum/display_message.asp?mid=5598

Ну Вы и нашли куда давать ссылку. На сайте интерфейса я нашел утверждение, над которым долго хохотал: что Oracle (кажется 3) был первой СУБД, поддерживающей транзакции.

StalkerS

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

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

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

StalkerS

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

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

Ну а что касается "так надо" - несложно построить пример, когда для условий b = 1 и b = 2 надо использовать индекс по b, а для условия b = 3 этот же индекс будет дико тормозить, в то время как индекс по a даст куда худшую, нежели при b = 1-2, но вполне приемлимую скорость.
5 янв 05, 11:40    [1227267]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
StalkerS
Кроме того, не стоит забывать, что версионность более требовательная к процессору и памяти сервера,

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

StalkerS
А вот кажется, оракл не так просто заставить вести себя как блокировочник.

Хм. А что Вы имеете в виду по "вести себя как блокировочник"? Если в абсолютно каждый селект добавить for update - это будет то или что-то другое?

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

Дык видите ли, материализованные представления - это и есть удобное средство денормализации. Очень дешевое в использовании.

StalkerS

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

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

StalkerS

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

Вывод, который был сделан, не может не отражать необходимости маркетинга windows-а.

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

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

И не увидите. Выходной результат будет определяться во-первых, специалистами, которые у вас есть, а во-вторых, условиями решаемой задачи. Вы же упорно хотите нечто "в принципе".
5 янв 05, 11:53    [1227287]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

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

Думаю, не так же. Насколько я понимаю архитектуру блокировочника, придется бороться с эскалацией блокировок на этой таблице. Как минимум - удваивается количество блокировок, которые тянет сервер. Кроме того, я не в курсе, как identity поле будет вести себя, если эту таблицу очистить либо делать rollback - sequence гарантирует неповторяемость результата (если он незацикленный), а для identity, по идее, достаточно уникальности в рамках таблицы.

Насколько я понимаю, для полноценного секвенсора придется таки вешать внешнюю процедуру; SQL-средствами его (полноценно) реализовать вряд ли возможно, или, по крайней мере, весьма непросто.

Хотя безусловно, это весьма удачное по цена/качество решение для случая "сымитировать функциональность".
5 янв 05, 12:07    [1227307]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
ChA
осуждать, "кишки" любого сервера - дело достаточно бессмысленное......Вывод из этого нудного вступления простой: наши знания о СУБД как разработчиков БД не могут являться абсолютно точными в принципе, а являются лишь нашим представлением о них.

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

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

Кроме того, если уйти с абсолютной точности на практическую.. Например, можно сделать так:

SQL> create table dumped (i varchar2(4000));

Table created

SQL> insert into dumped select lpad ( rownum, 4000, '0' ) from dba_objects where rownum <= 10;

10 rows inserted

SQL> create index dumped_i on dumped ( i ) ;

Index created

SQL> select object_id from dba_objects where object_name = 'DUMPED_I' ;

OBJECT_ID
---------
    82862

SQL> alter session set events 'immediate trace name treedump level 82862' ;

Session altered

*** SESSION ID:(17.18173) 2005-01-05 12:28:23.350
----- begin tree dump
branch: 0x499b7a 4823930 (0: nrow: 2, level: 3)
   branch: 0x47c509 4703497 (-1: nrow: 3, level: 2)
      branch: 0x499b7f 4823935 (-1: nrow: 3, level: 1)
         leaf: 0x499b7b 4823931 (-1: nrow: 1 rrow: 1)
         leaf: 0x499b7c 4823932 (0: nrow: 1 rrow: 1)
         leaf: 0x499b7d 4823933 (1: nrow: 1 rrow: 1)
      branch: 0x499b83 4823939 (0: nrow: 3, level: 1)
         leaf: 0x499b7e 4823934 (-1: nrow: 1 rrow: 1)
         leaf: 0x499b80 4823936 (0: nrow: 1 rrow: 1)
         leaf: 0x499b81 4823937 (1: nrow: 1 rrow: 1)
      branch: 0x499b87 4823943 (1: nrow: 3, level: 1)
         leaf: 0x499b82 4823938 (-1: nrow: 1 rrow: 1)
         leaf: 0x499b84 4823940 (0: nrow: 1 rrow: 1)
         leaf: 0x499b85 4823941 (1: nrow: 1 rrow: 1)
   branch: 0x47c50a 4703498 (0: nrow: 1, level: 2)
      branch: 0x499b88 4823944 (-1: nrow: 1, level: 1)
         leaf: 0x499b86 4823942 (-1: nrow: 1 rrow: 1)
----- end tree dump

Согласитесь, это отчасти позволяет судить о кишках :)

ChA
Поэтому хотелось лишь уточнить, что нельзя переносить некоторое знание об одной системе на другую, и нельзя быть уверенным на 100% в правильности понимания даже "свой" СУБД.

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

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

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

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

ChA
Это говорит только о личностных качествах участников дискуссии, не более того.

Локально - да. В то же время я успел собрать некую.. статистику личных впечатлений, которую не особо публикую (поскольку это именно впечатления), но которую имею в виду.

Лично мне бы было весьма удобно (для общего развития) знать некоего гуру в MSSQL, такого, что "все что противоречит его словам, следует считать неверным". В Оракле я пару таких знаю, в MSSQL - пока не нашел.

Правда, я не буду делать из этого вывод о большей непознаваемости MSSQL :)
5 янв 05, 12:37    [1227363]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
Gluk (Kazan)
Я не специалист по MS SQL, но по моему мнению, такое решение будет НЕ МАСШТАБИРУЕМЫМ (в смысле большого количества конкурирующих транзакций).

Полагаю, Вы чуть поспешили. Я так понял, имеется в виду, что секвенсору соответствует таблица (а не строчка в таблице, как обычно пытаются делать); соответственно, решение будет по большому счету столь же масштабируемым, как и основная таблица (где используются эти значения); транзакции не будут драться за блокировку этой строчки (поскольку, как я полагаю, вставка не блокирует другую вставку - иное было бы довольно странным).
5 янв 05, 12:41    [1227369]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
c127
2 Gluk (Kazan)

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

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

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


Sorry, ляпнул не подумав Все равно криво и негибко (про ограничение int-а промолчу)
5 янв 05, 13:17    [1227458]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Gluk (Kazan)
Member

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

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

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


Мы тут не так давно отшили ребят из Ижевска, собиравшихся впарить нам свой документооборот. Он был целиком завязан на Windows. MS SQL, ActiveX и все такое. А у нас, вот незадача, на рабочих станциях бывает и Солярка и Фря и уж конечно Линукс (основная масса конечно Windows, но что юниксоидам предложите vmware везде ставить ?). В общем после второго тура уговоров мы их больше не видели Хотя они клялись и божились, что решат проблему в течение суток
5 янв 05, 13:23    [1227471]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Gluk (Kazan)
Member

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

Зато, mssql позволяет использовать такие представления даже косвенно, т.е. если оптимизатор запроса видит, что какой-то запрос может
получить выгоду от использования этого представления (а вы об этом даже не подозреваете), так он его использует. А в оракл, насколько
знаю, материализованные представления участвуют в запросе, если только оно явно указано в предложении from.
И как там насчет обновления по таймеру ? Вы это вроде подтвердили, а как быть с этим :


И первое и второе не соответствует действительности. Oracle УМЕЕТ подставлять материализованные представления вместо таблиц фигурирующих в запросах если ему разрешено переписывать запросы и указано, что материализованное представление актуально на данный момент.
Существует возможность быстрого обновления мат.представлений по commit, не перестраивающая их полностью. Разумеется это нельзя сделать с мат.представлением на основе ПРОИЗВОЛЬНОГО запроса, но ИМХО MSSQL должен иметь В ЭТОМ плане АНАЛОГИЧНЫЕ ограничения.
5 янв 05, 13:28    [1227491]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

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

А что Вы тогда хотели компенсировать денормализацией, кода реч шла только о мат представлениях и индексированных представлениях MS SQL?


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

Да и что вы так уцепились за эту нормализацию ? Приведя базу в третью нормальную форму, вы не получите гарантированного успеха. На кой она
нужна эта третья форма, если база будет работать как будь-то на ней третий doom крутиться ?
Надо четко отделять теорию от практической целесообразности. Вот вы наверно в курсе, что вообще-то нормальных форм существует не 3, а 6 штук.
Только дальше третьей обычно не заходят как раз из-за практической целесообразности. А шестая форма и вообще практически в реальном мире
недостижима. Однако вас почему-то не волнует тот факт, что вы не можете ее нормализовать до идеала.

vadiminfo

Ну Вы тоже не сказали чем же он плох?


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

vadiminfo

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


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

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

vadiminfo

Опять вывод. У Вас склонность простым способам получать выводы.


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

vadiminfo

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


Я верю в то, что показав такие цифры, у некоторых людей отпадет желание доказывать, что оракл быстрее. Все эти тесты доказывают, что провести
полностью достоверный анализ - задача нетривиальная. Если системы показывают разные успехи на разных платформах, то однозначного вывода,
что быстрее, не сделать. Зато такой вывод можно сделать, сравнив например access и оракл. Прогнав их на большинстве повседневных задач, оракл
покажет явно лучшие результаты. А вот в сравнении с mssql - нет. Тут уже вступают такие второстепенные факторы, как время выхода и платформа.
А уж если сравнивать время выхода, так и не заминайте тот факт, что разница во времени выхода 10g и mssql - 4 года.
Вот, почитайте, http://pcweek.ru/?ID=56558 тут изложена некоторая оценка производительности разных субд на 2001 г., как раз с привлечением
тестов tpc. Один в один по теме нашего разговора.

vadiminfo

Я вот Вам и говорю про удобство переносимости, чтобы не зависить от влиятельных, а заодно ит производителя ОС


вы, как говориться, не просекли фишку. Вам не приходило в голову что возможна ситуация, когда проект создан на оракл, а приходит влиятельный идиот
и заставляет переделать его под mssql ?
И даже если выстроете баррикаду из книг "Открытые системы", и Кодда, вам она не поможет. Знаете почему ? Потому-что реальность отличается от
теории. В теории есть много красивых вещей, типа переносимости системы и 6-й нормальной формы.
А на практике это определяется наличием соответствующих специалистов и личными предпочтениями. Вот к примеру оракл обычно стоит на *nix. Я довольно
мало встречал упоминаний о связке windows - oracle. Поэтому если платформа виндовая, а люди хотят оракл, так они упрутся и переделают сеть
под *nix. Теория говорит - можно работать и там, и там. А практика : mssql - windows; oracle - unix. Так что если сеть уже настроена, так и база
будет заказана соответствующая. Потому-то это зависит от сисадмина, понимаете ? Если он юниксоид - будет оракл, даже если-бы оракл был на порядок
хуже, чем mssql. А если сеть на базе windows, так по-любому будет сделан выбор в сторону mssql, даже если сисадмин вообще ничего не понимает в
теории субд.
И ваши познания в теории открытых систем их волновать не будут.

softwarer

Не имеет смысла опускаться на уровень, с которого мы сможем увидеть только нечто, не имеющее отношения к реальности. Это именно что "ощупывание
слона по кусочкам".


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

softwarer

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


не совсем верно. Вот access например. Возьмите гуру в access, и заставьте его сделать базу, человек на 500 операторов, с массой транзакций и др.
Какие шансы будут у этой базы, в сравнении с базой на оракле, тоже созданной гуру ? Вот вам и разница "в принципе".
А взяв такие две базы на mssql и оракл, разницы "в принципе" не будет.
5 янв 05, 15:02    [1227754]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67468
Блог
StalkerS
Скорее, сложно найти причины, почему он годиться для работы. Если обнавляем по таймеру, то получение неактуальных данных почти гарантированно.....

Чтобы не пересказывать Ваш длинный абзац (есть впечатление, что он исходит из ложных представлений), постараюсь коротко обрисовать варианты.

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

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

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

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

Вывод: не думаю, что Вы покажете отчет, который эффективно строится явной денормализацией и не строится с помощью MV.

StalkerS
Так и посторонний человек, не разбирающийся в субд, посмотря на список фич, скажет - о!, фич на 50 шт. больше, оракл явно немерянно крут.Однако стоит копнуть чуть поглубже, так и выясняется, что работать с деревьями можно и без ваших фич, и результат не хуже.

Вы наполовину правы. Правы в том, что тупо считать "по количеству в списке" так же глупо. А неправы - в том, что результат не хуже.

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

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

StalkerS

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

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

StalkerS

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

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

StalkerS
возможна ситуация, когда проект создан на оракл, а приходит влиятельный идиот и заставляет переделать его под mssql ?

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

StalkerS
А на практике это определяется наличием соответствующих специалистов и личными предпочтениями. Вот к примеру оракл обычно стоит на *nix. Я довольно мало встречал упоминаний о связке windows - oracle. Поэтому если платформа виндовая, а люди хотят оракл, так они упрутся и переделают сеть под *nix. Теория говорит - можно работать и там, и там. А практика : mssql - windows; oracle - unix.

Не сказал бы, что это так - это скорее то, что MSSQL-евцы склонны считать идеалом (выбивая себе область обитания :) Я видел достаточное количество серверов Oracle на Win, в том числе и в промышленной эксплуатации. Вопрос в том, что Oracle дает выбор, а админы при прочих равных действительно предпочитают не винды.

StalkerS
Так что если сеть уже настроена, так и база
будет заказана соответствующая.

Хм. А сеть-то тут при чем? Я вот прямо сейчас могу со своей виндовой машины сходить на сервера на Win2000, Solaris и AIX. А если достану из кармана CD с загрузочным Linux-ом - достучусь до этих же серверов. Сеть-то тут при чем?

StalkerS
хуже, чем mssql. А если сеть на базе windows, так по-любому будет сделан выбор в сторону mssql, даже если сисадмин вообще ничего не понимает в теории субд.

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

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

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

Чтобы не заниматься формальными спорами, куда Вы, похоже, хотите уйти, простой пример. Как известно, сейчас принято считать, что 2 км/ч + 2 км/ч вовсе и не равно 4 км/ч. Пока мы остаемся в рамках задачи "сколько времени мне нужно, чтобы дойти домой" - подобное предположение остается вполне корректным допущением, которым мы пользуемся буквально каждый день. Тем не менее, как только Вы попытаетесь обобщить это на какие-то более глобальные события - рискуете сесть мимо стула.

В данном случае: Вы можете сказать, что "хакер", начитавшийся этого сайта, сможет сломать сервер A N1-м способом, а сервер B - N2-мя способами. Специально не называю - поскольку Вы так и не обосновали даже слабое утверждение (что дыр больше). Из этого можно сделать вывод, что сервер A либо B менее защищен от "хакера", работающего тупым перебором широко известных методов при предположении, что любое проникновение хакера одинаково вредно. С этим я соглашусь.

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

StalkerS
softwarer

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


не совсем верно. Вот access например. Возьмите гуру в access, и заставьте его сделать базу, человек на 500 операторов, с массой транзакций и др.
Какие шансы будут у этой базы, в сравнении с базой на оракле, тоже созданной гуру ? Вот вам и разница "в принципе".

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

StalkerS
А взяв такие две базы на mssql и оракл, разницы "в принципе" не будет.

Кто Вам сказал?

Как всегда - зависит от условий. Насколько я понимаю, в MSSQL пока нет ни range partitions, ни bitmap indexes, ни пользовательских агрегатных функций; аналитические функции мне показались тоже весьма ограниченными, хотя это запросто может оказаться следствием недостатка знаний.

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

Также не удивлюсь, если MSSQL-евцы покажут обратный пример. Собственно, та же OLAP Option в оракле еще весьма неотработана, так что здесь я ничуть не удивлюсь преимуществу MS.
5 янв 05, 15:54    [1227903]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
разговор сильно напоминает стандартный спор про mysql - а зачем транзакции, у меня сайт там форум и 5 пользователей, все класно работает. А зачем вложеные запросы, есть временые таблицы и если последовательно туда сбрасывать данные то можно обойтись без них. А зачем сторед процедуры можно и на пхп все что нада для форума налобать ... и т.п. и т.д.

у mssql пока очень мало полезностей для того чтоб перенести логику на сервер, t-sql недотягивает даже до сайбеза, в языке даже ексепшенов нет, sql диалект слабенький, ни аналитических функций ни деревяных, нет понятия схема, нет отслеживания зависимостей пакетов, для DW вообще ничего нет. зато есть офигенный аргумент - а мне не нада у меня форум и 5 юзеров и все зашибись как работает ... очень похоже на аргумент из mysql.
5 янв 05, 20:19    [1228287]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
vadiminfo
Member

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

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


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


StalkerS

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



Вообще то за долго до меня за нее уцепились Кодд и вся теория РМД. Напомню, что РМД иногда называют "Реляционной нормализованной моделью данных Кодда". Вот Вы приводите рассуждение в таком духе, что нормализация вообще не нужна? Я в курсе что нормальных форм даже больше 6. И часто приводят не просто к 3 нормальной форме, а к нормальной форме LTK. Т.е. стремятся навязать схеме , например, все функциональные зависимости. А НФБК имеет проблемы с навязыванием схеме всех функциональных зависимостей. Потому проектировщик и стоит перед выбором после 3НФ: полнота схемы или подавление избытка. Кроме того, проверка свойства НФБК является NP-полной задачей. Но это все не значит, что нормальными формами можно пренебрегать. А уже неормализванная схема по 3 нормальной форме имеет ощутимые анаомалии в общем случае. И теорию я не собираюсь отделять от практической целесообразности, но наоборот всячкески использовать. Если я пойду на денормализацию, то с помощью теории оценю все плохие последствия такого шага. Тем более, что на практике схема в 3НФ с большой вероятностью отвечает и остальным нормальным формам, поскольку для их нарушения нужны зависимости между атрибутами, которые в бизнес приложениях не так часты. Но не соглашусь, что нормальные формы не нужны: обошлись же без 4,5, 6, обойдемся и без 3 и 1. Такие доводы не достаточно убедительны.

StalkerS

Скорее, сложно найти причины, почему он годиться для работы. Если обнавляем по таймеру, то получение неактуальных данных почти гарантированно.


А если запрос выполняется 15 минут - данные все равно актуальны? Ведь эти таблы могли изменить. Веть мат представления полезны, например, там где времнеемкие запросы. Ну а уж причины для пользы, я Вам приводил. Зачем обновлять мат представление чаше чем это нужно? Ведь это напрасная трата ресурсов.

StalkerS

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

Допустим запрос выполняется 15 мин. Инкрементное обновление мат представление 1 сек и запрос к мат представлению 1 сек. 2 сек против 15 мин - не мудро? Зато практически целесообразно, мне кажется.

StalkerS

Вот, почитайте, http://pcweek.ru/?ID=56558 тут изложена некоторая оценка производительности разных субд на 2001 г., как раз с привлечением
тестов tpc.

За статью спасибо. Но там цифр и подобного Вашему анализа не нашел. Зато там вообще написано, что Оракл уступил уже раз и навсегда (кризис жанра). Это на основе тестов 2001 года, а теперь в 2004 даже Ваш анализ уже на этом не настаивает.
Это только подтверждает мое предложение Вам не настаивать на тестах для вывода ошеломляющих заключений.

StalkerS

Это говорит о том, что количество фич больше, и ни о чем другом.

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


StalkerS

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

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



StalkerS

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

Ну, например, если простые методы, мягко говоря, выглядят не очень убедительно. Имеют серьезные изъяны, вплоть до того, что позволяют вывести взаимосключающие утверждения.

StalkerS

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

У каких людей? Которые очень хотели бы, чтобы Оракл был медленнее. Почему Вас не смущает, что по логике Вашего вывода MS SQL 2000 быстрей или медленней самого себя. Там же есть и даты. И система хоть и одна, но устройства I/O могут быть разными в разное время. А основные задержки БД - чтение с диска. Такого анализа не достаточно для отбивания охоты у многих людей, у которых такая охота есть. Чтобы отбить такую охоту нужно, чтобы Оракл был медленее однозначно на всех задачах. А так Вы только преумножаете число таких людей - они об этом не заморачивались, а теперь начнут.


StalkerS

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

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

StalkerS

Я довольно
мало встречал упоминаний о связке windows - oracle. Поэтому если платформа виндовая, а люди хотят оракл, так они упрутся и переделают сеть
под *nix.

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

StalkerS

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

Зачем же мне понимать, когда я примерно вижу что происходит на практике? Еще раз говорю, что админ, а тем более сисадмин почти не играет там роли в плане выбора СУБД. Потому что его вопрос СУБД почти не касается, если я внедряюсь без каких-либо изменений для него. Система моя ему по барабану - она прикладная. Она может какаться админа БД. Но у нас есть практика, что админы с mssql с удовольствие админили нашу систему на Оракле. Тем более что это не напрягает их. Правда, иногда мы вынуждены вообще внедрять без админов БД. Там вообще никаких нет. Но это другая тема. У них если есть просто есть должность проггер - уже хорошо. И он как бы на всем по немногу работет.
Не знаю где Вы нашли таких сисадминов. Мне пока особо не встречались. Чтобы вообще были против любого внедрения встречались.
Например, они хотят свою систему. Причем, тоже на Оракле и под Виндами. Те же кто принимают решение о преобретении, вообще, в первую очередь интересуются только прикладной стороной системы.
А рассуждения про открытые системы, что никакого принципиального влияния на их сети или ОС нет, они принимают как само мобой разумеющееся.
5 янв 05, 21:19    [1228321]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
hell
Member

Откуда:
Сообщений: 3001
Хм, вы видели терабайтную базу на MSSQL? Кстати, раз уж платформы затронули,
видели ли вы серверы хотя бы middle-end на x86? Более-менее серьезное решение
для MSSQL вынуждает организовывать кластер, и трахатся админу с этой кучей гребаных
пентиумов, когда оракловый админ спокойно спит в кресле, посматривая на монстро-
образный Sun или HP-UX в стойке. Вопрос сродни тому, если www.microsoft.com еше
никто не умудрился завалить, значит ли это, что IIS - лучший http-сервер. Нет, это
значит, что у MS достаточно большое количество кластерных узлов.
5 янв 05, 22:05    [1228334]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
dburtsev1
Member

Откуда: NY USA
Сообщений: 351
hell
Хм, вы видели терабайтную базу на MSSQL?

Microsoft® TerraServer
6 янв 05, 00:34    [1228408]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
c127
Guest
2 hell

>Хм, вы видели терабайтную базу на MSSQL? Кстати, раз уж платформы затронули, видели ли вы серверы хотя бы middle-end на x86? Более-менее серьезное решение для MSSQL вынуждает организовывать кластер, и трахатся админу с этой кучей гребаных пентиумов,

Как тут уже справедливо отмечалось, кластер мелкософта это не средство повышения производительности, как у нормальных людей, а средство повышения надежности. Просто называется одним и тем же словом - спасибо отделу маркетинга мескософта, он у них единственное, что хорошо работает. Поэтому если такой кластер пентюхов где-то и функционирует, то только потому, что один пентюх недостаточно надежен для данной задачи.
6 янв 05, 01:49    [1228462]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
Sarin
Товарищи мэтры, а каков максимальный размер базы данных в MS SQL? Я это к тому, что если он меньше хотя-бы террабайта, то Oracle и MS SQL не соперники. Весовая категория разная.


достаточно сказать что самая большая база изображений в солнечной системе на MSQL www.terradata.com

самая база документов на DB2 (конгресс США)

совсем самая большая беркли

а на Оракле что ?
6 янв 05, 02:16    [1228475]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
softwarer

*** SESSION ID:(17.18173) 2005-01-05 12:28:23.350
----- begin tree dump
branch: 0x499b7a 4823930 (0: nrow: 2, level: 3)
   branch: 0x47c509 4703497 (-1: nrow: 3, level: 2)
      branch: 0x499b7f 4823935 (-1: nrow: 3, level: 1)
         leaf: 0x499b7b 4823931 (-1: nrow: 1 rrow: 1)
         leaf: 0x499b7c 4823932 (0: nrow: 1 rrow: 1)
         leaf: 0x499b7d 4823933 (1: nrow: 1 rrow: 1)
      branch: 0x499b83 4823939 (0: nrow: 3, level: 1)
         leaf: 0x499b7e 4823934 (-1: nrow: 1 rrow: 1)
         leaf: 0x499b80 4823936 (0: nrow: 1 rrow: 1)
         leaf: 0x499b81 4823937 (1: nrow: 1 rrow: 1)
      branch: 0x499b87 4823943 (1: nrow: 3, level: 1)
         leaf: 0x499b82 4823938 (-1: nrow: 1 rrow: 1)
         leaf: 0x499b84 4823940 (0: nrow: 1 rrow: 1)
         leaf: 0x499b85 4823941 (1: nrow: 1 rrow: 1)
   branch: 0x47c50a 4703498 (0: nrow: 1, level: 2)
      branch: 0x499b88 4823944 (-1: nrow: 1, level: 1)
         leaf: 0x499b86 4823942 (-1: nrow: 1 rrow: 1)
----- end tree dump

Согласитесь, это отчасти позволяет судить о кишках :)
Ни хрена не понял :)
softwarer

Давайте тогда так - расскажите известные Вам варианты поведения сервера, если на него приходит случайный поток запросов, подобных описанному мной.
Это которые на предыдущей странице ? Прошу прощения, несколько позже, недосуг... Дело в том, что сам клиентской частью уже давно не занимаюсь. Тех, кто занимается, обязал пользоватся параметрами, запросы с константами не в чести, а попросту - нет, соответственно, поднятый Вами вопрос специально не проверялся. Практически 99% случаев сложных запросов реализовано через процедуры, где часто просто зафиксирован план, что не во всех случаях оптимально, что естественно, но в целом оправдано, так как есть определенная статистика по пользовательским данным и не тратится лишнее время на построение плана запросов сервером, на чем иногда можно получить очень даже неплохой бонус.
Теоретически, по документации, много причин, которые вызывают перестройку планов запросов, подобных приведенным Вами, могу дать цитаты, но полагаю Вас более интересует практический аспект на примере приведенных запросов. Посему, проверю - отпишу. Лады ?
softwarer
такого, что "все что противоречит его словам, следует считать неверным". В Оракле я пару таких знаю, в MSSQL - пока не нашел.

Мне тоже не повезло, хотя людей подобных ("все, что...") встречал , после чего приходилось разгребать то, что они считали верным :) Я, простите, не верю, что есть люди, которые знают абсолютно все нюансы конкретной системы, в данном случае - СУБД, тем более, когда поведение и возможности СУБД меняются с каждой версией, а в некоторых случаях и с каким-нибудь fix-ом или service pack. Начинал работать еще с версии 4.21, но даже нюансы версии 6.5 не помню, 7 - с трудом. Работал с Informix 7.31 почти год, ведь настраивал, оптимизировал, прошло 4 года - ни хрена не помню :) Склероз, однако...
6 янв 05, 02:49    [1228488]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

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

А неправы - в том, что результат не хуже
Простой пример: я прямо сейчас могу одним запросом сказать все объекты базы (таблицы, хранимки итп) затронутые функцией X - используемые, вызываемые,
используемые из вызываемых итп. "Прямо сейчас" - это максимум за минуту. У Вас, полагаю, если сервер не дает готового решения - уйдет несколько
больше времени и здорово больше операций. Вот это я и имею в виду как разницу. Да, когда нужно выжимать "больше чем умеет сервер" - разницы нет.
Но в ситуации, когда достаточно использовать фичу - разница есть.


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

softwarer

Эта система будет одинаково стоить в разработке/поддержке/развитии? Вряд ли. А где будет стоить дешевле? А вот тут надо смотреть не на пальцах....


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

softwarer

Хм. А сеть-то тут при чем? Я вот прямо сейчас могу со своей виндовой машины сходить на сервера на Win2000, Solaris и AIX. А если достану из кармана
CD с загрузочным Linux-ом - достучусь до этих же серверов. Сеть-то тут при чем?


про сеть было в том смысле, что есть настроенная сеть с сервером на базе одной из систем (кстати, что такого непонятного в выражении "cеть на базе
windows" ? Стоит сервер с W2003 Server, например, домен организован, он им управляет).
А так-то да, и к *nix'овской сети можно подключить виндовый сервер и работать с mssql. У нас кстати, вообще Novell всем управляет (хреново правда
управляет).


softwarer

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


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

softwarer

Как всегда - зависит от условий. Насколько я понимаю, в MSSQL пока нет ни range partitions, ни bitmap indexes, ни пользовательских агрегатных
функций; аналитические функции мне показались тоже весьма ограниченными, хотя это запросто может оказаться следствием недостатка знаний.


см. выше, про фичность.

softwarer

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


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

vadiminfo

Если я пойду на денормализацию, то с помощью теории оценю все плохие последствия такого шага


я как-раз это и утверждал


vadiminfo

Но не соглашусь, что нормальные формы не нужны: обошлись же без 4,5, 6, обойдемся и без 3 и 1. Такие доводы не достаточно убедительны


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

vadiminfo

Но там цифр и подобного Вашему анализа не нашел. Зато там вообще написано, что Оракл уступил уже раз и навсегда (кризис жанра). Это на основе
тестов 2001 года, а теперь в 2004 даже Ваш анализ уже на этом не настаивает.
Это только подтверждает мое предложение Вам не настаивать на тестах для вывода ошеломляющих заключений.


это как раз доказывает мою позицию. Все зависит от времени выхода продукта. Я тоже показал по тестам tpc, что когда mssql 2000 вышел, он оказался
в лидерах. Это подтверждается множеством статей, найденных мною в инете. Сейчас трудно найти лидера, т.к. 10g работает не хуже, но и нельзя сказать
что лучше. Вот собственно и все мои заключения.

vadiminfo

На Ассемблере фич совсем нет


assembler предназначен для совершенно других задач. Нельзя его сравнивать с дельфи. А вообще про фичи см. выше.

vadiminfo

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


очень даже достаточно, что-бы утверждать, что нельзя однозначно сказать, кто из них быстрее. Именно это и есть моя позиция. Сейчас. А вот через год,
когда наверное уже успеют появиться новые тесты, вполне возможно, будет очевидным факт, что yukon быстрее оracle. А вот через два года, возможно
оракл выбьется в лидеры. И это говорит о том, что время выхода является главным критерием, а не субд.

vadiminfo

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


Если сисадмин не играет роли, тогда эту роль будет играть админ базы, а он выберет то, что нравиться ему. Ведь в конце концов, даже если сетка
*nix'овская, никто не мешает воткнуть в нее NT сервак, и все будет работать без проблем. А если это не нравиться сисадмину, то это уже, извините,
не аргумент. Мало-ли что мне не нравиться.
Ведь в чем у нас разногласие ? Вы говорите, что кроссплатформенность - плюс, значительно влияющий на выбор субд. Я говорю, что это - особенность
оракла, и никакого значительного влияния на выбор субд не оказывающая (во всяком случае на практике).
Я ставлю во главу угла СУБД и ее админов, и говорю что именно это в является главным критерием, а вы почему-то сисадминов и политику предприятия.
Ну а если админов на фирме еще нет, и возможно и не будет, так решение о выборе субд будете принимать как раз вы, и вы им втюхаете что хотите,
и никто вам там не возразит, потому-что это делать просто некому.
6 янв 05, 13:20    [1228953]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

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

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


кстати, есть-ли у кого-нибудь данные, говорящие о скорости работы таких связок ? В mssql оракл можно добавить как связанный сервер, и посылать
к нему запросы. Очевидно, это влечет дополнительные расходы. Но вот какие ? Может кто-нибудь с этим работал ?
6 янв 05, 13:32    [1228970]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
автор
а такого я не говорил. Понятно, что нормализация нужна, никто не спорит. Но после того, как база спроектирована, начинается процесс написания клиентских приложений, и уже вот тут на первое место выходит практическая целесообразность. Ведь базу вы делаете не для Кодда, а для пользователей.
Тормоза при работе им не нужны, и их будет слабо волновать, что эти тормоза обусловлены теорией.

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

Вас послушать , так следующим шагом будет отказ от использования СУБД и переход к плоским файлам?
А потом последуют заявляения типа "Fox-ых программеров" насчет того что программист лучше знает как быстрей прочитать данные из файла и т.д. и тому подобное.

Честное слово скучно.
6 янв 05, 13:35    [1228972]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
>когда наверное уже успеют появиться новые тесты, вполне возможно, будет очевидным факт, что yukon быстрее оracle.

оракл был лидером на протяжении 20-30 лет, МС случайно выскочил на год-два в лидеры tpc-c. МС никогда не добивался заметных результатов ни tpc-h ни предыдущих тестах tpc, достежений в тестах sap вообще нет. в 98ом оракл предлагал милион если МС докажет что они менее чем в 100 раз медленее в тестах tpc-d :) так что дает надежду считать юкон будет быстрей ? а главно за счет чего ? версионного механизма ? ;)
6 янв 05, 13:38    [1228977]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
StalkerS
А вот через год,
когда наверное уже успеют появиться новые тесты, вполне возможно, будет очевидным факт, что yukon быстрее оracle.
Много раз уже сказали- давайте не будем говорить в будущем времени. Моим родителям в будущем обещали коммунизм, мне- развитой социализм, а где мы сейчас?
6 янв 05, 14:19    [1229047]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
S.G.
StalkerS
А вот через год,
когда наверное уже успеют появиться новые тесты, вполне возможно, будет очевидным факт, что yukon быстрее оracle.
Много раз уже сказали- давайте не будем говорить в будущем времени. Моим родителям в будущем обещали коммунизм, мне- развитой социализм, а где мы сейчас?


автор

А я вам приведу другой пример: использование .NET в программировании ХП,
триггеров и польз. ф-ций (эты возможность появиться в Yukon, но я думаю справедливо рассматривать ее уже сейчас).


Стоит начать с себя.
Уже было оглашено о выходе стабильного релиза Ykon?
Нет, не было насколько мне известно,
а до того момента говорить о бета-релизах совершенно не уместо.

Кроме того из опыта ( не только моего ) известно что приступать работать с продуктом можно только после выхода второго релиза ( читай сервис пака), до этого момента производитель программного продукта будь то Oracle или Microsoft не утруждает себя вопросами качества и быстродействия.

Итого что мы имеем у Oracle
cтабильный откатаный релиз 9i ( последняя версия 9.2.0.6)
стабильный релиз от Oracle 10g и уже на сносях 10gR2.

Со стороны Microsoft мы имеем
cтабильный откатаный релиз MS SQL Server 2000
бета-релиз Ykon или MSSQL Server 2005.


Сколько пройдет времени до момента когда выйдет второй сервиспак для MSSQL2005 ?
6 янв 05, 14:50    [1229113]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить