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

Откуда:
Сообщений: 208
tygra
А вообще интересно (раз уж тема все-равно накрылась :)):
Кто:
1. Какую СУБД начал изучать изначально
2. С какой сейчас работает большинство времени
3. И почему 1 и 2

-- Tygra's --

1. IB, Sybase ASA
2. MS SQL
3. IB - в институте курсовые были и диплом. Sybase ASA - очень хорошо знаю (пришлось порабоать) и сейчас был бы не прочь с ней работать. MS SQL - потому что шеф так решил (хотя и его пытался отговоритьи не только я). А работать хочел бы с Oracle, хотя и не знаю его.
6 янв 05, 14:57    [1229131]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

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

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


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

EugeneS

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

Честное слово скучно.


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

Yo!

оракл был лидером на протяжении 20-30 лет


когда mssql еще и в проекте небыло.

Yo!

МС случайно выскочил на год-два в лидеры tpc-c.


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

Yo!

98ом оракл предлагал милион если МС докажет что они менее чем в 100 раз медленее в тестах tpc-d


после чего быстренько поубирал эти обещания со своего сайта, когда mssql обзавелся индексированными представлениями
6 янв 05, 16:27    [1229324]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7078
Извиняюсь за отсутствие... Болел, да и Новый год знаете ли :)
К сожалению тема ушла куда-то в сторону :(
tygra так и не дал ответ... Хотелось бы все-таки получить результаты по тестированию деревьев. А результаты 0 мс, которые на самом деле 0-15 мс мне как-то не очень, округлять надо в большую сторону.
Пока я сделал для себя следующие выводы по поводу графов:
- Oracle их реализует на "встроенном" уровне
- в MS SQL нужно создавать свою процеру/функцию с заточкой под структуру графа, если граф один, то первый вариант процедуры, если граф другой, то второй вариант процедуры и т.д.
- большинство программистов MS SQL считаю Oracle никчемным продуктом, программисты Oracle тоже самое думают об оппонентах. Печально :(
- никто не может протестировать алгоритмы построения графа на равноценных машинах и под Oracle и под MS SQL (или не хочет).
11 янв 05, 10:24    [1234430]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
>- никто не может протестировать алгоритмы построения графа на равноценных машинах и под Oracle и под MS SQL (или не хочет).

так для сиквела нет даже для деревьев процедуры, что тестировать ? игратся с деревьями глубиной аж в 2 уровня неинтересно.
11 янв 05, 11:20    [1234633]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ChA
Согласитесь, это отчасти позволяет судить о кишках :)
Ни хрена не понял :)

Это дамп b-индекса (точнее, его структуры). Согласитесь, информации подобного уровня достаточно, чтобы не гадать совсем уж на пальцах.

ChA
Тех, кто занимается, обязал пользоватся параметрами, запросы с константами не в чести, а попросту - нет,

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

ChA
Посему, проверю - отпишу. Лады ?

Буду признателен.

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

Я, простите, не верю, что есть люди, которые знают абсолютно все нюансы конкретной системы, в данном случае - СУБД,

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

Откуда: 127.0.0.1
Сообщений: 67463
Блог
StalkerS
Если вы помните, в разговоре о безопасности, вы утверждали, что глупо считать дыры. Если это так, то почему вы отвергаете свою-же логику, только примененную к другой теме ? Да, фич в оракле больше, но из этого не следует, что появиться разница на выходе.

А почему Вы говорите, что я отвергаю свою логику?

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

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


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

Хм. Практическую ценность? Я привел этот пример потому, что это одна из типовых задач любого разработчика на любом инструменте - посмотреть зависимости между модулями приложения. К примеру, посмотреть, где может "аукнуться" изменение, или найти все подпрограммы, которые следует просмотреть на предмет выполнения того или иного требования.. Собственно, эта тема - во всех вариантах, включая, например, "как найти все dll, используемые в моей программе" - одна из стандартных.

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

Я уже публиковал в этом топике ссылку - похоже, в Oracle это будет не позже, чем в Yukon. Соответственно, в рамках сравнения фичности это не аргумент. Хотя особого смысла не вижу - не из-за кроссплатформенности, а просто именно смысла. Почему - потому что уже встроена Java, которая в принципе эквивалентна. А раз так - значит, смысл этой фичи в возможности подключать уже реализованные для .NET решения. Что приятно, но не слишком критично.

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

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

StalkerS

Вот и скажите мне, какая фича более ценная ?

Из двух фич, которые есть в Oracle? Зависит от задачи; в абстрактном случае, полагаю, деревья будут использоваться много чаще. .NET станет более актуальной фичой, если здорово обгонит джаву, то есть если станет единственным разумным способом сделать нечто реально нужное.

StalkerS

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

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

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

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

StalkerS
про сеть было в том смысле, что есть настроенная сеть с сервером на базе одной из систем (кстати, что такого непонятного в выражении "cеть на базе windows" ? Стоит сервер с W2003 Server, например, домен организован, он им управляет).

И какое это отношение имеет к выбору СУБД? Если, конечно, выбор делается мало-мальски продуманно, а не по принципу "на том же сидишнике лежит SQL Server"?

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

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

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

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

StalkerS
softwarer

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

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

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

Теперь: сформулируйте, пожалуйста, что Вы хотите здесь показать или услышать.

StalkerS

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

Пожалуйста, читайте не через слово. У меня складывается ощущение, что Вы перешли на спор "из принципа".
11 янв 05, 13:16    [1235203]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Yo!
так для сиквела нет даже для деревьев процедуры, что тестировать ? игратся с деревьями глубиной аж в 2 уровня неинтересно.

Примеры запросов, которые я привел, работают в том числе и в случае дерева произвольной глубины.
11 янв 05, 15:38    [1236068]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
2andsm

не нашел, можно еще раз запостить тот код так чтоб в результате процедуры возвращали также path и level для каждого узла примерно так:

node2 node1/node2
node3 node1/node2/node3
11 янв 05, 15:54    [1236161]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Первоначальная задача была - вернуть всех потомков для выбранного узла. Эта задача решена, причем скорость работы запросов как минимум не уступает аналогу в Oracle. Решение можно найти выше. Я могу решить и ту задачу о которой Вы говорите, но вообще-то я сейчас на работе, и мне некогда этим заниматься.
11 янв 05, 16:09    [1236257]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
andsm
Первоначальная задача была - вернуть всех потомков для выбранного узла. Эта задача решена, причем скорость работы запросов как минимум не уступает аналогу в Oracle. Решение можно найти выше. Я могу решить и ту задачу о которой Вы говорите, но вообще-то я сейчас на работе, и мне некогда этим заниматься.

2Stalker: обратите внимание, именно это я и имел в виду. Решить можно - кто бы спорил - но решать эти задачи вместо того, чтобы заниматься функционалом, требуется далеко не всегда.
11 янв 05, 16:16    [1236288]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
2andsm

OK, я подожду.
11 янв 05, 16:38    [1236413]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
StalkerS
Member

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

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


Я рад, что вы с этим не спорите. Начался весь этот разговор с того, что alex-ls говорил, что разница есть, и очень даже приличная. Именно
в скорости обработки запроса, а не в человеко-часах ее разработки.
Таким образом, разговор сходит к затратам времени на реализацию, но не к самой работе базы. С этой позицией, с чисто теоритической точки
зрения, спорить бесполезно - действительно если есть встроенная фича, то это по определению не может быть хуже, чем когда фичи нет.
И mssql был-бы конечно лучше, если-бы обладал чем-то подобным. С чисто практической точки зрения тут можно спорить (хороший специалист
все-равно решит, и вряд-ли затратит намного больше времени, а неспециалист спросит на форуме, где получит ответ специалиста, таким
образом разница во времени конечно будет, но говорить о явном преимуществе тут не стоит), но я-бы хотел сказать немного другое.
Ведь мы не сравниваем эти фичи с нулем. Мы сравниваем их с другим набором фич. Вот к примеру PIVOT, превращает строки таблицы в столбцы.
(возможно в оракле так тоже можно, но вы, надеюсь, понимаете, что я имею ввиду). Или, например, преславутая самонастраиваемость mssql.
Ведь, SQL Server позиционируется как сервер, требующий минимального администраторского внимания. Например, с mssql2000 убраны настройки,
позволявшие в 6.5 регулировать функции упреждающего чтения. Теперь это полностью автоматизировано, и надеюсь никто спорить не будет, что
это лучше, т.к. вы не в состоянии думать лучше, чем встроенный алгоритм.
Вот и думайте теперь, что лучше, работа с деревьями или PIVOT. Похоже на сравнение, что лучше - длинное или соленое.

softwarer

Хотя особого смысла не вижу - не из-за кроссплатформенности, а просто именно смысла. Почему - потому что уже встроена Java, которая в
принципе эквивалентна
...
Ей мало кто будет пользоваться по другим причинам - которые в этом топике подробно осветил ASCRUS. Java есть уже почти десять лет - и не
сказать, что все так уж бросились ей пользоваться.


java и .NET вещи немного разные. Нельзя так говорить, что раз java непопулярна, так и .net не понадобится. Что-б пользоваться java, вам
его знать надо. А в случае с .net, вы будете использовать один и тот-же язык для разработки клиентского приложения и самой базы. Написали
клиента на C#, и хранимую процедуру на C#. И никаких других языков привлекать больше не надо. Вот если-бы я был разработчиком оракл, то
тоже-бы не пользовался такой возможностью, потому-что не знаю java. И не стал-бы его учить, только для того, что-бы написать пару ХП.
А если я уже знаю один из .net-языков для разработки клиентов, так почему-бы не написать на нем сложную ХП ?
А вот как раз кроссплатформенность в случае с оракл, выезжает на первый план. Не понимаю, почему вы придаете такое малое значение этому
факту, вы-же сами писали, что основная масса баз оракл находиться на юниксах.

softwarer

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


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

softwarer

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


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


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

Ну не моя вина, сам не рад ;)


andsm

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


зачем изобретать велосипед, один из моих самых первых постов в этом топике как раз содержит алгоритм для получения путей вхождения элементов.
Причем тот код возращает все пути для элемента, если этот элемент входит в несколько ветвей дерева. Это рабочий код из нашей базы, он нужен
для нахождения всех путей вхождения например подшипника определенного типа. К примеру, в изделие может входить 50 одинаковых подшипников,
причем в совершенно разные сборки. Так этот запрос вернет 50 строк, содержищих эти пути. (кстати, ваша вcтроенная фича так умеет ?)
11 янв 05, 21:34    [1237059]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Yo!
Guest
автор
то рабочий код из нашей базы, он нужен для нахождения всех путей вхождения например подшипника определенного типа


можно все таки выложить этот чудесный код ? о нем так много говорят а я никак не могу его увидеть... раз уж в мс это так просто можно специально для тупых все таки показать структуру таблички и небольшой тест кейс ?
11 янв 05, 23:03    [1237122]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11380
softwarer
Это дамп b-индекса (точнее, его структуры). Согласитесь, информации подобного уровня достаточно, чтобы не гадать совсем уж на пальцах.
Со второго взгляда уже и так сообразил :) Нехилое развлечение, наблюдать "деревянную" структуру индекса, правда, IMHO, это ничего не говорит об упомянутых "кишках" сервера, в лучшем случае - о "кишках" структуры данных, ну да Бог с ними...
softwarer
Буду признателен.
Договорились, процесс может затянутся на, дай-то Бог, пару недель, увы, горячая пора, начало года, новые "фичи", "радость" клиентов, ну Вы понимаете, да ? :)
Сами понимаете, ситуаций на самом деле много, это только с виду запросы простые. Навскидку, могу сказать, что если оба поля включены в начало кластерного ключа, то автопараметризация включается с первого раза, с кэшированием плана, если только запрос не возвращает более ~30% записей, в таком случае план обычно не задерживается в кэше, полагаю, потому, что воспринимается как нетипичный запрос, проверка шла на довольно приличной рабочей таблице. Но с кластерным ключом в MSSQL неинтересно, это тривиально, знай считывай себе диапазон. С полным отсутствием индексов тоже скучно, никакие гистограммы не дадут оптимизации, ничего кроме полного скана, и появляется ли в кэше план, задерживается ли он там, абсолютно не важно, - только скан. Более интересны ситуации с некластерными индексами, хотя смутно помню, что и там играет роль упомянутые 30%, после которых обычно проще(дешевле) сразу сканировать таблицу, чем лезть в индекс, получать там ссылки(bookmarks), а потом только лезть в таблицу и по ссылкам вытаскивать строки из таблицы. Но что реально творится в кэше планов запросов никогда не проверял, претензий не было, а на нет и суда нет :) Обычно: есть медленный запрос - давай сюда, ууу, здесь переписать так - в 3 раза быстрей - достаточно, нет ? тогда еще так и так - на порядок - достаточно ? - нууу - в сад, чудес не бывает, промежуточных итогов не держим :) Конечно, у оптимизатора иногда "крышу" сносит, правим, в крайнем случае, гвоздями(hint-ами), но, слава Богу, реже, чем могло бы быть.
Кстати, последствия могу отписать по адресу из профиля, если угодно, здесь это вряд ли кому интересно.
Да, чуть не забыл, читал когда-то давно, мол Oracle7 умеет пользоваться индексом, даже если поиск идет не по первому полю составного индекса. Не можете расшифровать ? Как-то слабо это себе представляю :( Как это возможно, с получением выигрыша, один лешак сканировать весь индекс придется, или здесь что-то хитрое ? В общем, для меня это из разряда, что в DB2 может быть 2 кластерных индекса на таблицу, типа - факт, но как ? :)
alex-ls
большинство программистов MS SQL считаю Oracle никчемным продуктом, программисты Oracle тоже самое думают об оппонентах.
Не думаю, что найдется много первых, скорее заочное уважение, но не более того, а вот вторых, боюсь через одного - "Нет СУБД, кроме Oracle, и Эллисон - пророк его", причем оппонентами можно смело считать все остальные СУБД. Это все-таки больше к религии, есть агрессивные, есть терпимые, а есть атеисты, но их обычно немного :(
12 янв 05, 02:20    [1237225]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7078
StalkerS

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

И продолжаю держаться за эту позицию, пока меня не убедят в обратном. Приведенные примеры лично у меня не заработали... Хотя есть и MS SQL сервер: два проца 1.7 Гц и памяти 1 Гб, что конечно меньше, чем на Oracle, но сравнивать можно.
Может все же кто-нибудь даст рабочий код, который я мог бы потестировать?

StalkerS

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

decode, посмотрите в FAQ по Oracle. Фичей в Oracle больше, спорить здесь не о чем.

StalkerS

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

Давайте не будем решать, что для меня лучше, а что нет. Всегда желательно иметь возможность ручной настройки вне зависимости от правильности работы автоматики.
12 янв 05, 08:12    [1237326]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> decode, посмотрите в FAQ по Oracle.

PIVOT - это не decode. Это транспонирование набора данных. Ненужная фича, имхо.
12 янв 05, 08:23    [1237339]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7078
www.fun4me.narod.ru
>> decode, посмотрите в FAQ по Oracle.

PIVOT - это не decode. Это транспонирование набора данных. Ненужная фича, имхо.

Речь не об этом
StalkerS

Вот к примеру PIVOT, превращает строки таблицы в столбцы.

В Oracle для этой операции используется decode. Насчет необходимости PIVOT ничего не могу сказать.

alex-ls

большинство программистов MS SQL считаю Oracle никчемным продуктом, программисты Oracle тоже самое думают об оппонентах.

ChA
Не думаю, что найдется много первых, скорее заочное уважение, но не более того, а вот вторых, боюсь через одного - "Нет СУБД, кроме Oracle, и Эллисон - пророк его", причем оппонентами можно смело считать все остальные СУБД.

Ваша фраза лишь подтверждает мои предположения. Вы считаете, что программисты Oracle ненавидят MS SQL. Про себя же Вы думаете, что уважаете Oracle. В принципе эта ситуация нормальна, ничего такого уж плохого в этом нет. Конкуренция... А истина, как говорится, в споре рождается!

То программистам MS SQL: жду от Вас реально работающего примера для графа! Описание данных я приводил. Все еще надеюсь его потестить...
12 янв 05, 08:56    [1237382]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
andy st
Member

Откуда:
Сообщений: 899
alex-ls

И продолжаю держаться за эту позицию, пока меня не убедят в обратном. Приведенные примеры лично у меня не заработали... Хотя есть и MS SQL сервер: два проца 1.7 Гц и памяти 1 Гб, что конечно меньше, чем на Oracle, но сравнивать можно.
Может все же кто-нибудь даст рабочий код, который я мог бы потестировать?

а не надоело?
рабочий код был уже приведен. были результаты... что еще надо?

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

знакомый не так давно купил стиралку за 1,5K$. один из основных критериев выбора была возможность создания своих программ стирки.
как результат - он покаялся в содеянном и сейчас пользуется программами из стандартного набора ибо все его "оптимизации" сводились к программам из этого набора.
12 янв 05, 09:01    [1237388]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7078
andy st

а не надоело?
рабочий код был уже приведен. были результаты... что еще надо?

Я пробовал запускать этот код у себя. Он сработал не правильно, или просто не сработал. Еще вопросы есть?
andy st

знакомый не так давно купил стиралку за 1,5K$. один из основных критериев выбора была возможность создания своих программ стирки.
как результат - он покаялся в содеянном и сейчас пользуется программами из стандартного набора ибо все его "оптимизации" сводились к программам из этого набора.

Если Вы сравниваете покупку стиральной машины с проектированием БД у себя на предприятии, то грош Вам цена, как специалисту.
12 янв 05, 09:45    [1237480]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> В Oracle для этой операции используется decode. Насчет необходимости PIVOT ничего не могу сказать.

А как он используется для превращения строк таблицы в столбцы? Через джойн исходной таблицы с таблицей, содержащей номера столбцов? А почему union all для этого не используется?
12 янв 05, 10:03    [1237550]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
andy st
знакомый не так давно купил стиралку за 1,5K$. один из основных критериев выбора была возможность создания своих программ стирки.
как результат - он покаялся в содеянном и сейчас пользуется программами из стандартного набора ибо все его "оптимизации" сводились к программам из этого набора.


Этот знакомый, очевидно, по профессии - программист?

Требую отставки Президента РФ
Картинка с другого сайта.
12 янв 05, 10:13    [1237584]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ChA
[quot softwarer]
Да, чуть не забыл, читал когда-то давно, мол Oracle7 умеет пользоваться индексом, даже если поиск идет не по первому полю составного индекса.


Если в запросе используются ТОЛЬКО поля индекса, Oracle может решить полностью сканировать индекс вместо таблицы, что значительно быстрее. Сканироваться индекс будет естественно не по порядку, а в порядке следования блоков в сегменте. В Yukon, насколько я понял введена аналогичная фича, позволяющая ВКЛЮЧАТЬ в индекс столбцы не задействованные в индексе. Зачем правда я так и не понял, что мешает просто включить их в индекс ???
12 янв 05, 10:29    [1237648]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
andy st
Member

Откуда:
Сообщений: 899
Scott Tiger

Этот знакомый, очевидно, по профессии - программист?

бывший, сейчас компами торгует.
вот и ностальгия по былым временам так проявляется.... ;)
12 янв 05, 10:49    [1237756]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 7078
www.fun4me.narod.ru
>> В Oracle для этой операции используется decode. Насчет необходимости PIVOT ничего не могу сказать.

А как он используется для превращения строк таблицы в столбцы? Через джойн исходной таблицы с таблицей, содержащей номера столбцов? А почему union all для этого не используется?

Немного не понял вопроса.
Пример, приведенный в Faq, вроде понятный. Есть продажы какого-то изделия в разное время. Нужно получить расклад продаж каждого изделия по месяцам. Причем здесь union?
12 янв 05, 11:09    [1237850]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL > Oracle = True?  [new]
andy st
Member

Откуда:
Сообщений: 899
alex-ls
andy st

а не надоело?
рабочий код был уже приведен. были результаты... что еще надо?

Я пробовал запускать этот код у себя. Он сработал не правильно, или просто не сработал. Еще вопросы есть?

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

Если Вы сравниваете покупку стиральной машины с проектированием БД у себя на предприятии, то грош Вам цена, как специалисту.

я сравнивал не покупку, а наличие возможностей настройки. фичастость, не спорю, греет душу. но насколько они будут востребованы в каждом конкретном случае - это уже вопрос.
выбрал продукт, обосновал, используешь...
а потом оппоненты (которых предлагали другой проукт) спросят - если ты их не юзаешь фичи,
хотя указал в их преимуществах, то чем руководствовался при выборе, уж не откатом ли?
и у тебя появляется время подумать в поисках новой работы (был свидетелем прецедента - очень поучительно)
12 янв 05, 11:10    [1237856]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить