2 Well-wisher\r
\r
>P.S. Все теперь точно завязываю \r
\r
Я предлагаю продолжить, может выплывет что-нибудь полезное. \r
\r
>Кстати дайте ссылочку на microsоft.com, где безапеляционно заявляется, что их оптимизатор лучший в мире.\r
\r
Я говрил о мелкософтовцах а не о microsоft.com. Вот ссылка на местный общепризнанный авторитет в области MSSQL-я - Дед Маздай - он похоже просто цитирует мелкософтовские методички, возможно захочет поделится первоисточником.\r
Дед Маздай> Но! При всем при этом я утверждаю, что процессор запросов SQL Server на порядок превосходит Oracle. Да простят мою категоричность приверженцы Oracle, DB2, Sybase, Interbase и других очень неплохих СУБД, но реляционный движок SQL Server, созданный практически с нуля для версии 7.0 и доведенный в 2000, на сегодня является лучшим в отрасли и по скорости работы, и по интеллектуальности оптимизатора. Эти факты признаны даже в академических кругах "СУБДостроения", а его авторы отмечены премиями Тьюринга, Бэббиджа и другими престижными наградами в области computer science.\r
(163789: /topic/26854&pg=-1).\r
\r
>Есть хорошие результаты в TPC-H для до терабайта. Что вас не устраивает ?\r
\r
Меня как раз и не устраивают голословные заявления что MSSQL (уже сейчас, без всякого юкона) годится для баз абсолютно любой величины и сложности. При этом говорится, о лучшем в мире оптимизаторе, когда тесты этого оптмизатора говорят об обратном. Еще меня не устраивает, что TPC-C, в котором у меклософта неплохая позиция, упоминаются везде, а TPC-H вроде не существует совсем, причем по странному совпадению именно там мелкософт в пролете.\r
\r
>Можно. OLAP позволяет получать ответы на сложные запросы подобные запросам теста TPC-H гораздо эфективнее и проще.\r
\r
Это утверждение эквивалентно заявлению, что строя OLAP систему мы можем создать в принципе более эффективный оптимизатор, чем возможно реализовать в SQL-сервере. Это странно. Например потому, что SQL-сервер при оптмимзации запроса имеет в своем разпоряжении всю служебную инфорамацию о таблицах, индексах и пр. в то время как при доступе из среднего уровня (OLAP) к тому же SQL серверу мы имеем доступ только к тем его ресурсам, которые создатели SQL сервера нам предоставляют.\r
\r
>А то что эти ограничения все поменялись вам неважно ? \r
\r
Когда я перекомпилирую программу я тоже иногда меняю константы и дефайны, они для того и придуманы, чтоб их было легко менять. Но это не те изменения, которые позволяют говорить о пререписовании программы с нуля.\r
\r
>А также то что с этими ограничения практически нереально столкнуться в нормально спроектированной базе ? \r
\r
Так дело ж не в этом. Эти ограничения убрать ничего не стоит, если бы они были принципиальными то они были бы у всех SQL серверов. С другой стороны, они по-видимому все-таки достают пользователей, поскольку их постоянно отодвигают. Но почему-то не убирают. Отсюда вывод: никто ничего не переписывает.\r
\r
>А что в Оракл вообще нет ограничений типа Nested trigger levels или Nested subqueries ?\r
\r
Вроде нет, у ДБ2 нет, у сайбез ASA точно нет и никогда не было, даже когда он был ваткомом и помещался на одной дискете. \r
\r
>Объясняю. МС доказал, что Винды могут эфективно работать на 64 прцессорном серваке. Не думаю, что NT 4.0 смог бы так же эфективно планировать процессы на таком сервере. Я пока не видел ни одного теста с Линуксом на более, чем 8-процессорной машине. Подозреваю, что у Линукса проблемы с масштабируемостью. Посмотрим что изменит ядро 2.6. Нетварь 6.0 к примеру работает на многопроцессорной машине по принципу asymmetric multiprocessing в отличии о нормальных операционок (SMP). Эфективно работать на 64 процессорах она не сможет в принципе. Значит она не масштабируема.\r
\r
Спасибо, с масштабируемостью я понял. \r
\r
На 64 процессорах и дос будет работать эффективно. А как проводились эксперименты и что такое эффективность, как она измерялась? Кстати линукс умеет работать в кластере, причем на жалких AMD (по-моему 96 машин) вставляет какой-то серьезный мейнфрейм. Тоже очень подозрительный результат, наверное можно ко многому придраться, но винда в кластере не умеет работать в принципе (мелкософт опять подменил понятия: виндовс кластер не имеет отношения к тому, о чем мы говорим и к повышению производительности). \r
\r
Что касается "по принципу asymmetric multiprocessing в отличии о нормальных операционок (SMP)", то по-моему это относится к конфигурации компьютера, а не к операционке, хотя я могу ошибаться. \r
\r
>Я пока не видел ни одного теста с Линуксом на более, чем 8-процессорной машине.\r
Наверное просто не обратил внимания. На тест линуха на 16 процессорной машине можно посмотреть в том же TPC-H, который мелкософтовцы так не любят (http://www.tpc.org/tpch/results/tpch_perf_results.asp), в самой первой строчке, самый лучший результат на самой большой БД. Так что проблем с масштабируемостью у линуха скорее всего тоже никаких, по крайней мере не больше чем у винды.