авторВот это как-то настораживает. Откуда ASA знает, сколько в девайсе шпидлелей, да еще и на стольких платформах ? Времена, когда СУБД затачивали под конкретную аппаратуру давно прошли, так что это как-то сомнительно выглядит. И вообще, при чем здесь сколько в девайсе физических дисков ? Он свои структуры должен уметь в парралель сканировать. Сортировать в парралель. На N процах. При чем здесь кол-во дисков ?
Из BOL я понял, что ASA может распознавать не только на скольких физических устройствах ее несколько файлов БД храниться, но и даже если файл БД лежит на одном логическом диске, который на самом деле является RAID. В итоге СУБД может определить, что например индексы и таблицы на самом деле лежат на разных девайсах и производить параллейное, а не последовательное их чтение. Может быть я конечно понял не правильно, но у них так и написано. Хотя с другой стороны, если СУБД поддерживает специальную команду теста аппаратуры для определения ее скоростных характеристик с целью их учета при построении плана запросов, то почему бы и этим ей не заниматься.

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

Ну а какая СУБД лучше у одного производителя толку спорить нет - у каждого из них есть своя ниша. Причем мне видиться 2 направления:
1. OLTP (ASA) + DSS (IQ) - прекрасная связка для проектов, где по отделам и удаленным филиалам крутяться решения с расчетами и сложной бизнес-логикой, а на IQ стоит центральная аналитическая БД, в которую через определенные промежутки заливаются данные, поступающие с ASA.
2. OLTP/OLAP (ASE) + ApplicationServer (EAServer) - очень хорошая связка для проектов, где в реалтайме накапливаются и анализируются данные, причем требуется устойчивая масштабируемая распределенная система, способная выдержать большие нагрузки как вставки записей, так и выборок.

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

Ну мы все это уже обсуждали, хочу только для 9-ки прокомментировать:
автор- ровнее распределяет нагрузку (для ASA уже 50 юзеров это серьезная нагрузка)
50 юзеров уже не проблема

автор- проще бороться с блокировками (по крайне мере ASA 6-8 может заблокировать таблицу на selectе и потом ее не отпустить)
все операции записи теперь только через ROW LOCK, SHARED LOCK поправлена и работает нормально.

автор- выше производительность (если таблицы более 500 000 записей и требуются операции SUM-GROUP bY)
Добавлены кластерный индекс и специальные алгоритмы обработки аггрегатных и OLAP выборок. Проблем при групповых операциях с миллионами записей в обьединяемых таблицах нет. Так же добавлена опция переключения работы оптимизатора с Mixed на OLAP, позволяющая указывать оптимизатору стратегию при выборе алгоритмов в плане запросов.

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

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

авторТак что в Sybase CIS вас не обманули. У них есть статистика. У нас она тоже есть, и согласно статистики количество обращений по поводу проблем на ASA на больших объемах и нагрузках возрастает очень резко, в отличии от MS.
Кстати прекрасная мысль насчет статистики. На CIS надежды мало, а вот организовать собственный сбор статистики по различным направлениям было бы неплохо для нас самих же.

Отлично, специалисты ASE пришли к формулировке договора :) Ну и со своей стороны ASA подтверждаю, что говорить о базах в сотни гигов и тысяч пользователей конечно же не стоит, действительно можно написать БД, которая будет тянуть и такие обьемы, но квалификация специалиста должна быть очень и очень сильной. Насколько я понимаю, решения Enterprise - это когда вне зависимости от квалификации программиста система все равно продолжает работать (тут наверное все таки впереди всех Оракл).

P.S. Как там в Ночном дозоре:
И заключили договор специалисты ASE, что не будут трогать решения SMB.
И заключили договор специалисты ASA, что не будут трогать решения Enterprise.
Но придет апгрейт новой версии и измениться расстановка сил в пользу ASE или ASA. И с учетом того, что Sybase больше любит ASE, скорее всего это будет она, так как дороже продавать раскрученный Enterprise, чем плодить новый. Но пока есть iAnywhere, у специалистов ASA не угасает надежда на победу WatcomSQL над TSQL.

Гм, вот что значит по 10 минут в день читать книги, благо память на цитирование хорошая :)