Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10   вперед  Ctrl      все
 Re: MS SQL Server FOREVER!?!?!  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
2с127
Нет, Вы положительно пришли сюда поругаться. Обратитесь пожалуйста еще раз к моему предыдущему посту, где я перечислял вещи, которые есть в PL/SQL и которых нет в Transact-SQL. Вы с чем-то из этого несогласны? Покажите место, где бы рассуждалось об индексах применительно к языку. Кстати, что Вы имеете в виду под вторым типом индексов, отличных от B-Tree, которые будто бы поддерживаются в MS SQL Server? Докажите, что я "не разбираюсь в предмете или сознательно передергиваю" и назовите его. При всем уважении в Вашем посте слишком много эмоций и слишком мало умных мыслей. Вы пишете "защитники MSSQL стыдливо признали, что да, T-SQL слегка уступает". Я не стыжусь признать, что Т-SQL уступает PL/SQL, о чем писал раньше. Поэтому слово "стыдливо" соблаговолите стыдливо засунуть себе туда, откуда Вы его исторгли. Я ведь тоже мог бы дать волю эмоциям и написать, что c127 носится со своим разнообразием индексов в Oracle, как дурень с писаной торбой. Но я этого не делаю, потому что по большому счету дополнительные типы индексов ничего принципиально нового не дают. Если Вы серьезно изучали предмет, Вы должны понимать, что все операции над битмэпами и хэш-структурами можно с равным успехом воспроизвести на деревьях. Но Вы серьезно предмет не изучали, потому что речь идет о реляционном engine, а Вы пытаетесь отбиться объектными таблицами. Вы нахватались маркетинговых слоганов, и Вас, как дикаря блестяшки, прельщают большие цифры: таблиц в запросе, максимальный уровень вложенности, длина оператора и т.д. Вам тут уже несколько человек пыталось объяснить, что если в запросе 256 таблиц, значит, пора задуматься о том, правильно ли у Вас спроектирована база. Но разве Вы можете допустить проблему у себя в ДНК! Да по барабану, что размер константы в SQL Server = 16777207. Единственные цифры, которые имеет смысл сравнивать, причем не номинально по документации, а на реальных серьезных тестах - это поддерживаемые объемы данных, количество одновременных пользователей и производительность. По объемам и тот, и другой работают с терабайтными базами. По производительности на одномашинных конфигурациях: SQL Server - 433107, Oracle - 427760 транзакций в мин. (TPC). По concurrent users: SQL Server - 26000, Oracle - 23000 (SAP). Поэтому, нравится Вам или нет, я еще раз процитирую: "некорректно утверждать, что SQL Server 2000 лучше Oracle 9i или наоборот. Оба продукта могут использоваться для построения стабильной и эффективной системы, и стабильность и эффективность ваших приложений и баз данных зависят, скорее, от опыта разработчиков и администраторов, чем от производителя". Если Вы, с127, не способны понять этого тривиального факта, значит, Вы попросту тупой. Что, по-видимому, и служит истинной причиной Вашей антипатии к SQL Server.
4 апр 03, 15:01    [165085]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Единственные цифры, которые имеет смысл сравнивать, причем не номинально по документации, а на реальных серьезных тестах - это поддерживаемые объемы данных, количество одновременных пользователей и производительность.По производительности на одномашинных конфигурациях: SQL Server - 433107, Oracle - 427760 транзакций в мин. (TPC). По concurrent users: SQL Server - 26000, Oracle - 23000 (SAP).
Это изначально деструктивно.
По приведенным результатам тестов, скажем mySQL, я думаю обойдет и MSSQL и ORACLE
4 апр 03, 16:04    [165221]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Crip
Member

Откуда:
Сообщений: 2490
2Дед Маздай
COOL!

2Dimar
Предложение "По объемам и тот, и другой работают с терабайтными базами.", я так понимаю, пропущено намеренно?
4 апр 03, 16:46    [165305]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
По размеру дистрибутива как самому маленькому точно обойдет.
4 апр 03, 16:55    [165321]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
По размеру дистрибутива как самому маленькому точно обойдет.
4 апр 03, 16:56    [165322]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
to tygra
Нет я просто ошибся вырезая текст
http://www.mysql.com/doc/ru/Table_size.html
MySQL версии 3.22 имеет предел по размеру таблиц 4 Гб. В MySQL версии 3.23, где используется новый тип таблиц, максимальный размер таблицы доведен до 8 миллионов терабайтов (2 ^ 63 bytes).


Уже вродебы есть 4ая версия
4 апр 03, 17:14    [165358]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Дык не важно, сколько он там может размер создать - важно, что помрет он с таким размером :)
4 апр 03, 17:23    [165370]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Ну не совсем, если просто вставлять туда записи, или делать запрос по 1 таблице по индексу, делать он это сможет куда быстрее ORACLE и MS.
(см. тесты о которых говорилось выше)
и уж тем более он дешевле MSSQL :)
4 апр 03, 17:42    [165400]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
2DimaR
Читайте внимательно. Я говорю: "причем не номинально по документации, а на реальных серьезных тестах". Вот примеры компаний, где SQL Server работает на терабайтных объемах: AT&T, Barnes & Noble, LEXIS-NEXIS, SPAR Handels AG, Keylime Software. Я не сомневаюсь, что для Oracle такие примеры тоже существуют. Но вот для MySQL, честно говоря, верится с трудом. Вы бы не могли привести пример внедрения MySQL на данных 0.1 Тб и выше?
4 апр 03, 17:54    [165426]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
ppp
Member

Откуда:
Сообщений: 278
http://www.theregister.co.uk/content/53/30095.html
4 апр 03, 18:25    [165467]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32167
2DimaR
Вы пишите:
"Единственные цифры, которые имеет смысл сравнивать, причем не номинально по документации, а на реальных серьезных тестах - это поддерживаемые объемы данных, количество одновременных пользователей и производительность.По производительности на одномашинных конфигурациях: SQL Server - 433107, Oracle - 427760 транзакций в мин. (TPC). По concurrent users: SQL Server - 26000, Oracle - 23000 (SAP).
Это изначально деструктивно.
По приведенным результатам тестов, скажем mySQL, я думаю обойдет и MSSQL и ORACLE"

Почему деструктивно???
Тест на производительность в SAP очень даже конструктивен и прекрасно иллюстрирует то, что оба сервера подходят для решения задач клиента.
Предприятие, покупая систему SAP, может убедится, что на обоих платформах достигается одинаковая произподительность и масштабируемость в реальном приложении. Это-же не синтетический тест, а реальный. И при выборе будут учитываться другие факторы - например, ИТ-инфраструктура компании. А mySQL никого не обойдет - на ней SAP не работает (слава богу).
И для разработчиков это показатель - если для реальной и большой системы SAP оба сервера подходят, то почему они не подойдут для его будущей системы? (c127 - исключение - его-то система поболее будет, и посложнее, и пользователей в перспективе не жалкие 23 тыщи)
4 апр 03, 18:51    [165494]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
ppp
Member

Откуда:
Сообщений: 278
soglasen s DimaR v tom plane chto testi oni vedj tak i ostajutsa testami.
Sobrali sistemu , podkrutili vse gajki - porabotala ona paru chasov - i vse.
A skolko realnih ilstallachi SAP na MS SQL ??? Prakticheski netu takih, odin tolko Oracle i DB2. K chemu bi eto , esli MS SQL takoj zamechatelnij, nadeznij i deshevij produkt ? Ok , mazno skazatj chto ne tak davno 7.0/2000 vishel , poetomu malo installachij, no vedj i novie sistemi ne stavjat na MS. Navernoe estj prichini.
4 апр 03, 19:32    [165525]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
to alexeyvg
Я не видел SAP,
Но из того что слышал, эта система перешла из локальных СУБД и ей пофигу какую базу использовать, MSSQL ORACLE пусть даже mySQL или еще чего, она не использует возможностей СУБД, именно тех которые отличают одну СУБД от другой, соответственно не используя преимущества конкретных СУБД, так, что это не самый хороший пример.
4 апр 03, 20:23    [165543]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
чингиз
Member [заблокирован]

Откуда: unknown
Сообщений: 1848
ДМ>Если Вы серьезно изучали предмет, Вы должны понимать, что все ДМ>операции над
ДМ>битмэпами и хэш-структурами можно с равным успехом воспроизвести на
ДМ>деревьях.

2ДМ
1
если бы Вы серьезно изучали предмет, Вы должны понимать, что ВСЕ
операции НАД ВСЕМИ ОБЬЕКТАМИ можно с равным успехом воспроизвести
на машине Тьюринга.

а машину Тьюринга можно запрограммировать на ЛЮБОМ языке программирования.

вопрос только в количестве окружающего траха.

2
c127 Вам написал, что индексы НЕ ЕСТЬ свойство языка.
и автор статьи, который говорит что индексы есть свойство языка есть полуграмотный функционер.

3
и это Вас, как дикаря блестяшки, прельщает оголтелая торговая пропаганда
M$

4
МД>Что, по-видимому, и служит истинной причиной Вашей антипатии к SQL Server.
--
Для умного МД исторический экскурс
отметим что за все свою 20 историю MS постоянно воняет о своих достижениях.

в начале 90 M$ берет у АйБиЭм спецификации и деньги на разработку OS/2
и за эти деньги, по чужим спецификациям разрабатывает WIN95.
(на русском языке это называется кидалово)
IBM наверно вовремя спохватилась и отобрала спецификации.
или может требовалась совместимость с кривой ВИН3.11,
но зачаточное разделение ресурсов, не линейное адресное пространсво задачи и очередь сообщений, затрудняющих программирование сделали свое дело. вин95 еле работала.

тогда для разработки NT (только вдумайтесь как звучит - новая технология
M$ наконец то догадалась вернуться к линейному адресному пространству и
человечскому разделению ресурсов,
то есть сделать то, что все другие уже делали давно), как очевидно неспособная справится с такой великой задачей, M$ наняла группу проектировщиков из DEC-и - (тех которые создали rsx11-m и vax11,
на ваксах кстати за 10 лет до 95 года работало до 100 пользователей).

а транзакт SQL ? это вообще разработка Sybase. и M$ SQL содран с Sybase ASE. причем в статьях всегда MSSQL хвалился, и всегда сообщалось что
он лучше чем другие. MS почти человечские (такие которые у Оракла и сайбеза и Ватком были ВСЕГДА) триггера кое как смогла в SQL2000 вставить.

и тоже НОВЫЕ ВОЗМОЖНОСТИ от микрософт.

гы

как можно эту фирму професииональных свистков и ее рекламу
серьезно воспринимать вообще?
5 апр 03, 04:47    [165658]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
c127
Guest
2 Дед Маздай

>Обратитесь пожалуйста еще раз к моему предыдущему посту, где я перечислял вещи, которые есть в PL/SQL и которых нет в Transact-SQL. Вы с чем-то из этого несогласны? Покажите место, где бы рассуждалось об индексах применительно к языку.

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

>Я не стыжусь признать, что Т-SQL уступает PL/SQL, о чем писал раньше.

Это наверное замечательное чувство, но я не понимаю при чем тут Вы? Превосходство PL/SQL довольно очевидно, но оно тут совершенно не важно. Это всего лишь язык, по большому счету он такой же, как T-SQL, С, Паскаль, VB. Я бы вообще не включал сравнение языков в сравнение серверов.

Проблема в другом. Поскольку в превосходстве PL/SQL мало кто сомневается, и это пришлось бы признать все равно, то автор статьи по-видимому решил использовать ситуацию в свою пользу и вынес в свойства языка то, что на самом деле является свойством SQL сервера. Это почему-то оказались свойства, проигрышные для MSSQL-я. T-SQL от этого уже не пострадал, а вот собственно MSSQL сервер выиграл. Что, возможно, Вам сделать совершенно ноправданное заявление: "Таким образом, в оригинале мощнее не Oracle как сервер баз данных, а его язык программирования в серверной части", которое меня так развеселило. Я не верю, что автор статьи напутал случайно, слишком элементарные вещи перепутаны. Хорошо, давайте считать, что автор статьи ввел Вас ввели в заблуждение.

>Кстати, что Вы имеете в виду под вторым типом индексов, отличных от B-Tree, которые будто бы поддерживаются в MS SQL Server? Докажите, что я "не разбираюсь в предмете или сознательно передергиваю" и назовите его.

Расставляем точки над и. Моя точная цитата: "что автор статьи, а вместе с ним возможно и Дед Маздай, не разбирается в предмете или сознательно передергивет" - не несет оскорбительного смысла по отношению Вам. Вот если бы я не употребил слово "возможно" то заявление было бы вызовом. А так возможно Вы и разбираетесь. По предыдущим дискуссиям у меня сложилось именно такое мнение и эти две статьи, которые Вы приводите как весомый аргумент, меня сильно разочаровали.
Второй тип индексов в MSSQL-е это кластерный первичный ключ. Он тоже индекс (облегчает поиск), хоть и сильно ограниченный в смысле что на произвольное поле его не напустишь, менять после создания таблицы нельзя и пр. Впрочем не претендую, пусть будет один B-TREE индекс, можно считать, что я ошибся. В утверждении о некомпетентности автора статьи эта посылка роли не играет.

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

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

>Но Вы серьезно предмет не изучали, потому что речь идет о реляционном engine, а Вы пытаетесь отбиться объектными таблицами.

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

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

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

>Вам тут уже несколько человек пыталось объяснить, что если в запросе 256 таблиц, значит, пора задуматься о том, правильно ли у Вас спроектирована база. Но разве Вы можете допустить проблему у себя в ДНК!

Это просто неправда. Вы невнимательны. По-видимому проблемы в ДНК.

>Да по барабану, что размер константы в SQL Server = 16777207

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

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

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

>По производительности на одномашинных конфигурациях: SQL Server - 433107, Oracle - 427760 транзакций в мин. (TPC). По concurrent users: SQL Server - 26000, Oracle - 23000 (SAP).

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

>Если Вы, с127, не способны понять этого тривиального факта, значит, Вы попросту тупой.

Мне тоже приятно поговорить с воспитанным человеком. Но все-же про блокировки у Вас как-то получше получалось.
5 апр 03, 05:56    [165660]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
c127
Guest
2 Алексей К
>И всё-таки было бы интересно сравнить эти системы не на примере миллиона инсертов (какой-то нереальный пример, если надо вставить миллион записей, тогда какой-нибудь БУЛК ИНСЕРТ надо использовать, но никак не SQL, это же какой сетевой траффик будет!!!, да и сервер зачем так насиловать?) а на более жизненном примере.

А зачем люди решают задачи на построение с помощью циркуля и линейки на вступительном экзамене?

Ведь цель - не вставить N записей, а посмотреть скорость, динамику, может еще что вылезет, например сетевой трафик тоже может быть частью теста. С одной стороны - тест очень простой, для нового SQL сервера можно за пару часов написать (включая изучение SQL диалекта и средств). С другой стороны - есть инсерт, основные поля, можно еще пару индексов и функций добавить. Это тест на инсерт. Если использовать БУЛК ИНСЕРТ, то это будет тест на БУЛК ИНСЕРТ, тоже иногда нужно делать. Еще нужно ИМХО делать тест на селект. А построение совсем уж реальных примеров требует времени, сопостовимого с написанием приложения.
5 апр 03, 06:26    [165662]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
c127
Guest
2 alexeyvg

>(c127 - исключение - его-то система поболее будет, и посложнее, и пользователей в перспективе не жалкие 23 тыщи)

Это точно, мы ожидали 6млн пользователей. Хоршо, что все раньше навернулось. Всего до 20000 добрались.
5 апр 03, 06:46    [165665]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AISOFT
Guest
c127
Желаю успеха в работе с Oracle, ну а менее продвинутые, в эпистолярном жанре, пока с SQL SERVER поработают. Не возражаете?
5 апр 03, 21:07    [165819]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
c127
Guest
2 AISOFT

>Не возражаете?

Возражаю категорически. Все построились и дружными рядами перешли на фокспро. Я о ней читал много хорошего в соседннем топике, к тому же НАТО уже практически перешло, только в танках третий парадокс оставили, но и то дня на 2-3, не дольше.
6 апр 03, 02:54    [165856]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 DimaR
Всё-таки в Вашем и моём тесте есть разница и существенная. И дело не в том что я написал сам, а Вы взяли из книжки. В тесте с календарём перебирается 12*50*31 = 18 600 записей. При любом построении плана запроса на любой машине этот запрос выполнится многновенно. В задаче Эйнштейна вариантов записей получается 5 в 30-й степени, это примерно 10 в 21-й. Тупым перебором этот запрос не выполнить и здесь надо правильно построить план запроса. Я сомневался что MS SQL сможет сделать приемлиемый план, однако он сделал. Мне вот интересно сможет ли это сделать Оракл.

2чингиз
в начале 90 M$ берет у АйБиЭм спецификации и деньги на разработку OS/2
и за эти деньги, по чужим спецификациям разрабатывает WIN95.
(на русском языке это называется кидалово)

Могу продолжить:
"Евреи продали Россию"
"Во всём виноват Чубайс"
Продолжайте и дальше читать желтую прессу и ваши исторические экскурсы будут еще более интересны.

2 с127
Чё-то как-то неубедительно. И больно воды много. Ну например:
Проблема в другом. Поскольку в превосходстве PL/SQL мало кто сомневается, и это пришлось бы признать все равно, то автор статьи по-видимому решил использовать ситуацию в свою пользу и вынес в свойства языка то, что на самом деле является свойством SQL сервера. Это почему-то оказались свойства, проигрышные для MSSQL-я. T-SQL от этого уже не пострадал, а вот собственно MSSQL сервер выиграл. Что, возможно, Вам сделать совершенно ноправданное заявление: "Таким образом, в оригинале мощнее не Oracle как сервер баз данных, а его язык программирования в серверной части", которое меня так развеселило. Я не верю, что автор статьи напутал случайно, слишком элементарные вещи перепутаны. Хорошо, давайте считать, что автор статьи ввел Вас ввели в заблуждение.
Я вот из этого абзаца не вынес никакой информации, одни эмоции.
А кластерный индекс кстати всё равно имеет В-дерево.


Вот еще вспомнилось чего-то
Хватит спорить о вариантах зернопогрузчика. Долой диспуты вокруг технических вопросов.

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

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

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

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

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

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

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

Михаил Жванецкий, Стиль спора
7 апр 03, 10:24    [166137]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
Я целиком согласен с SergSuper и считаю, что продолжение дискуссии свелось к тому же, к чему обычно и к сожалению в данном форуме все сводится. Любые разумные доводы мой уважаемый оппонент с127 воспринимает как попытку обратить его в веру SQL Server, а потому прислушивается только к своему сладкоголосому пению. Поэтому я не буду говорить о его неточностях относительно кластерного индекса, а также о поддержке других структур индексов, помимо двоичного дерева, в SQL Server. Использование хэшей видели все, кто хоть раз сталкивался с неотсортированными инпутами в джойне, а битмэпы широко используются там, где они действительно необходимы - при обработке аналитических запросов. Почему это нельзя прописать явно в CREATE INDEX - другой вопрос. Он относится, скорее, к идеологии, чем к технологии. Не секрет, что с каждой версией в SQL Server остается все меньше возможностей ручной подкрутки различных параметров настройки. По-видимому, сие есть общая для Microsoft тенденция - возьмем хотя бы управление памятью, сборку мусора и другие низкоуровневые вещи, которые автоматизирует .NET Framework. Хорошо это или плохо? Не скрою, я как старый DBA иногда испытываю дискомфорт от этой автоматической коробки передач, внутри которой SQL Server норовит все подстроить и сбалансировать сам. С другой стороны, Oracle в своих последних релизах тоже стал двигаться в этом направлении. Наверное, это правильно, потому что разработчик должен фокусироваться на бизнес-логике приложения, а не на разного рода системных вещах. Иначе бы все до сих пор сидели на Ассемблере. А приведенные статьи невзирая на критику с127 я все-таки нахожу полезными, потому что в них действительно содержатся здравые попытки сопоставления, а не голословные маркетинговые выкрики с той или другой стороны. Причина неприязни к ним с127, в общем-то, очевидна: он не может и в мыслях допустить, что кто-то способен составить конкуренцию его любимому Oracle - отсюда его агрессивность, которую он тщетно пытается замаскировать под якобы объективные суждения. С этой точки зрения мне более интересны вопросы устройства той или иной функциональности в разных СУБД: механизма блокирования, многопоточности, ..., нежели заведомо бесплодные попытки мериться крутизной.
7 апр 03, 13:04    [166437]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649

Nu skazem u tebja processing platezej po kreditnim kartochkam, realnie dengi
klentov v baze v realnom vremeni, doverish takuju sistemu w2k/sql2000 ???


Я работал в компании, которая именно такие продукты и на такой платформе разрабатывает - клиенты (банки в основном) не жалуются. Речь идет о банках в Ирландии, на Ближнем Востоке, Австралии и в Восточной Европе.
7 апр 03, 19:01    [167061]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
ppp
Member

Откуда:
Сообщений: 278
I chto , eti razrabotki realno v bankah rabotajut ? Ili tak i ostalish razrabotkami kotorie pitajutsa prodatj ?
7 апр 03, 19:21    [167079]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649
I chto , eti razrabotki realno v bankah rabotajut ?


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

Я собственно закончил контракт и ушел только потому,что больно уж мне в Ирландии жить не нравилось - деревня.
7 апр 03, 21:08    [167153]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
ppp
Member

Откуда:
Сообщений: 278
Jasno, ne kak ne ozidal takih uspehov u MS.
Irlandci , oni voobshe MS ljubjat , na moej preznej rabote oni dolzni bili napistj koe chto , MS SQL , IIS , VC - krivoty slepili stashnuju . Ni hrena eshe ne rabotalo , a eti perci uze na svoem sajte Case Study vivesili - mol vot u nashego klienta vse slavno rabotaet ))
7 апр 03, 21:46    [167171]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить