* обьем IO на транзакцию
* response time
* кол-во одновременно работающих пользователей

не совсем хороший показатель. В OLTP может быть легко равен 1.

ChA killed* обьем IO на транзакциюВ OLAP(DSS) транзакции смысла не имеют, только при "заливке" новых данных...
killed* response timeВсем бы хотелось получить результат побыстрее...
killed* кол-во одновременно работающих пользователей
Потребителей информации в общем случае больше чем поставщиков...

P.S. Нет OLTP без модификации, нет OLAP(DSS) без чтения. Все остальное - плавный переход от одного к другому.

1. Транзакция - это необязательно dml (insert/update/delete). Select ничем не хуже. По крайней мере в Оракле.
2. Хотелось бы конечно да. Только время отклика задается на этапе проектирования системы. Хотя конечно тоже критерий нечеткий
3. Необязательно больше. 10 аналитиков могут перелопачивать данные продаж 20 магазинов. Я несколько про другое говорил. Пара тысяч пользователей для OLTP - ничего выдающегося, вот для DSS это будет круто.

ChA killedТранзакция - это необязательно dml (insert/update/delete). Select ничем не хуже. По крайней мере в Оракле. Причем здесь Оракл ? Транзакции нужны для того, чтобы база данных находилась в согласованном состоянии. SELECT-ы не могут нарушить это состояние. Тогда какой смысл в транзакциях ?
killedТолько время отклика задается на этапе проектирования системы.Возможно в некоторых проектах так и бывает, но обычно, на практике, редко кто может предсказать время отклика еще на стадии проектирования. Слишком много неизвестных, начиная с "железа", от сервера до сети, и заканчивая, собственно, структурой БД и оптимизацией запросов.
killedНеобязательно больше.Было сказано немного иначе, суть сводилась к тому, что количество писателей в общем случае меньше, чем количество читателей. Все зависит от характера предметной области. Доведя до абсурда, кому нужна только запись информации без ее прочтения и интерпретации ? Аналитики построят свои "кубы" и прочая, и результат их деятельности может стать доступным через, например, WEB-интефейс, стать доступным руководству и акционерам в виде результатов выполнения запросов к отдельным срезам OLAP-хранилища. Это к тому, что аналитики - это не конечные и не единственные потребители агрегированной информации...

У меня нет опыта работы с другими СУБД, поэтому я могу что-то реально посоветовать опираясь только на свои ограниченные знания. Не более.
Транзакция может быть рид-онли, для сохранения согласованности на момент ее запуска, если это важно.

Время отклика определяется бизнесом. Это первичный критерий со стороны бизнеса. Особенно для OLTP. Проектирование, железки - бизнесу наплевать на все эти второстепенные в его понимании вещи. Есть цель. Она либо достигнута, либо нет. Пример. Если процесс резервирования авиабилета у оператора занимает 20 минут, то кому нужна такая система?

Про писателей/читателей мысль понял.

Александр___ killed* обьем IO на транзакцию
* response time
* кол-во одновременно работающих пользователей
значения показателей на вскидку можно ?

Четких нет по понятным причинам, всегда найдутся исключения, но в целом:

* пара десятков килобайт vs сотни килобайт, мегабайты
* пара секунд vs минуты
* сотни и тысячи vs десятки

Про транзакцию упустил, что речь о DSS.
Про время отклика не согласен категорически. Это один из показателей качества сдаваемой системы. Если речь идет о серьезных проектах, в них никто не торгуется насчет железа. Берутся рекомендации вендора, консалтинговой конторы, ведущей проект. Зачем разделять ответственность за риски? Все требования и условия, включая цену проекта оговариваются до начала внедрения. Так вот, если время отклика критично для работоспособности бизнеса, то никто не будет "мириться", вместо дивидендов можно убытки схлопотать. Эти требования диктуются бизнесом не от балды. Это тежи деньги. В этом смысле время отклика по важности может ничем не отличаться, скажем, от времени простоя системы, или времени обработки звонка в биллинговой системе или любого другого параметра, которое определяет качество системы.