Нужен совет: Oracle или MS SQL

[fed]

Ну я бы сказал что при таком объеме пользователей MS SQL не выдержит.
Имеется следующая техническая подробность:
Хотя Xeon уже года 4 как умеет адресовать до 64 Гбайт памяти, но до недавнего времени (до введения поддержки технологии EM64T), доступ приложения к всему что находится за пределами первых трех гигабайтов делался, мягко говоря, очень непрямолинейным путем. (Там что-то типа сегментных регистров как в 8086 использовалось).
Соответственно - хотя Windows 2000/2003 Datacenter Edition и поддерживал работу с большим объемом памяти, SQL Server всю память за пределами первых трех гигов использовал только под дисковый буфер. Таблицы блокировок, планы запросов, и вообще всяческие остальные внутренние данные должны были помещаться в первые три гига.
При числе пользователей до 250-300 - есть шансы что эти данные в первые три гига помещаться будут. А вот если пользователей больше - то кранты, сколько памяти не ставь - все равно производительность сильно расти не будет.
В принципе - в этом году должны выйти Windows 2003 64Bit Edition и SQL Server 2005 64Bit Edition, которые позволят обойти это ограничение (правда не факт что Аксапту сразу сертифицируют для работы на SQL Server 2005).

Если сервер нужно покупать уже сразу и сейчас - можно купить машину на Itanium и поставить туда специфичную версию Windows 2000/SQL Server 2000 (которые изначально 64битные и позволяют адресовать всю память). Правда обойдется такая машина в сумму сопоставимую с ценой RISC-сервер от Sun или HP.

Так что если у вас дейстительно много денег и вы можете позволить себе дорогую технику и специалистов - я бы советовал покупать RISC-сервер и Oracle.
Если денег поменьше - можно попытаться купить хороший многопроцессорный сервер на последнем поколении процессоров Xeon (которые с поддержкой EM64T), с большим объемом памяти и поставить туда Linux и Oracle(у меня кстати был клиент у которого аксапта работала с Oracle под Fedora Linux).

А если вообще от вашей конкретной ситуации отвлечься, то на мой взгляд при сколько- нибудь больших объемах данных Oracle выигрывает. Причем выйгрыш выражается не в том что при одинаковом железе он работает быстрее чем MS SQL, а в том что когда MS SQL тормозит - его ускорить удается только апгрейдом железа (который быстро упирается в ограничения по памяти), а когда тормозит Oracle, то его в большинстве случаев удается ускорить настройкой сервера, четким прописыванием плана запроса (через outline) или скажем достроением специфичных оракловских средств ускорения запроса (ну скажем bitmap indexes или materialized view).

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

Ну и под конец хотелось бы упомянуть что в аксапте есть несколько мест (скажем - та же зарплата или некоторые куски в книгах покупок/продаж) которые явно не тестировались и не оптимизировались под Oracle. И либо вашим программистам для таких мест придется довольно неочевидным образом править исходные тексты аксапты (она далеко не все оракловские хинты поддерживает и часто приходится бороть проблему тормознутости запроса методом перебора), либо просить админа настроить outline для данных тормознутых запросов (что тоже не всегда хорошо потому что при изменении запроса outline придется переделывать).
Но при ваших масштабах - как мне кажется - другого пути просто нету в принципе.

Кстати - в террабайт после года работы я как-то слабо поверил
То есть - живому пользователю в день больше килобайт 30-40 данных не внести. Пользователей у вас тысяча, дней в году 365, после разноски исходного документа данные будут занимать максимум раза в 4 больше чем было в исходном документе (и то вряд ли). Накладные расходы на хранение данных (ну индексы там всякие и тп) занимают примерно 50% от исходных данных. Итого:
40000 *1000 * 4 *1.5 *365 = 80Гигабайт примерно.
Так что до террабайта придется наверное дет 5-7 расти - даже с учетом роста фирмы.

P.S. После того как я это написал - возникла довольно обширная переписка по поводу того что для 32битных платформ для Oracle характерны те же проблемы с памятью. Полностью с этим согласен. Просто когда я писал это сообщение - я не сформулировал четко ту мысль, что на мой взгляд MS SQL 64Bit - это пока-что достаточно экзотичная вешь, а Oracle 64Bit - штука все таки уже достаточно распространенная.