подслушал...
Слушай, а можно поподробнее. Как себя ведет ASA на таком обьеме в плане быстродействия и пр и какое железо. Долго присматриваюсь к ней.
А о "продуктивности" - это все от заказчика зависит (ИМХО).
По моему для любой БД такой обьем записей означает только одно - сервер себя будет вести хорошо и послушно только при условии грамотно проектирования схемы БД и бизнес-логики. То есть от грамотности разработчика и его опыта реализации работы с такими массивами данных. Тут различий между серверами наверное и нет - есть только присутствие или отсутствие определенных фич, позволяющих более с меньшими затратами решить ту или иную задачу. В данном случае ASA не обладает достаточным кол-вом фич для обработки и хранения таких обьемов информации и для повышения производительности придется ручками разруливать многие ситуации. К примеру в ASA можно достаточно легко спроектировать деление информации по архивным таблицам, соединив доступ к ним через представления или хранимки, однако в том же Oracle или DB2 это можно сделать гораздо легче и с меньшими затратами, используя их партиционирование таблиц. Опять же - для БД большого обьема создание или восстановление бакупа у ASA будет более долгим и неудобным по сравнению с Оракловыми возможностями создавать бакупы разных частей БД ... ну и т.д. С другой стороны если требуется высокая скорость работы для OLTP и приемлимое время для OLAP, то это по любому будет выгоднее сделать на ASA, чем на том же Oracle. Примеров можно приводить массу - например, быстро работающий в плотной нагрузке Озон в Windows на MSSQL+компилируемый ASP.NET и не менее быстро работающий в плотной нагрузке и не уступающий функционалу Озона сайт наших клиентов на ASA+интрепретируемый PHP на смешном по конфигурации Linux сервере, не тянущим даже на звание домашней современной машины. Так что главное руки, а имя сервера на потом по целесообразности.