Денис!
Приезжайте к нам в Террасофт, возьмем базу на пару миллионов контактов, запустим на нашем боевом рабочем сервере и посмотрим на производительность. :)

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

Архитектура системы такова, что производительность зависит только от используемой СУБД и железа. Мы максимально сокращаем выборки, оптимизируем запросы "на лету" и прибегаем к еще целой массе разных ухищрений. (Предчувствуя поток "умностей" от "продвинутых" разработчиков, сразу говорю, что в форуме спорить на эту тему не буду - это не то место, где можно поспорить без соплей и грязи. Все о чем я говорю мы можем показать и показать КАК и ГДЕ это РЕАЛЬНО работает).

По максимальным показателям - есть внедрение в Мексике 2000 пользователей, и в Украине - 600 пользователей.

iscrafm Сторонний наблюдательЯ понял! То, что является нормой показано, как достижение.
тяжело назвать такое поведение нормой. При каждом чихе пользователя гонять пакеты между сервером и клиентом, вместо обработки локального кеша - скорее отклонение от нормы.

Не удержался .... :)

Т.е. нужно сначала сформировать локальный кеш из миллиона записей, а потом проделывать все операции с ним. локально :)

iscrafm flexjob iscrafm Сторонний наблюдательЯ понял! То, что является нормой показано, как достижение.
тяжело назвать такое поведение нормой. При каждом чихе пользователя гонять пакеты между сервером и клиентом, вместо обработки локального кеша - скорее отклонение от нормы.

Не удержался .... :)

Т.е. нужно сначала сформировать локальный кеш из миллиона записей, а потом проделывать все операции с ним. локально :)
нуу.. нужно бороться с недержанием. Как по Вашему количество полей в наборе данных или условия сортировки влияют на количество записей в нем?
Вытянули на клиента набор из 1000 (пусть) записей (на всякий случай - число записей определяется условиями WHERE). Пользователь хочет отсортировать в нужном ему порядке.Что делаете? правильно... тянете еще раз эти 1000 записей. Пользователь хочет отсортировать по другой колонке - еще раз 1000 записей. Пользователю мешает одна колонка, он хочет ее убрать.. еще раз 1000 записей...
В общем - держитесь.

Нет, к сожалению, опять удержаться не могу :)
Вы это серьёзно написали? :)

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

А ничего что выборка при этом должна на 100% не совпадать, т.к. если вы видели первую тысячу из миллиона с начала, теперь вы ее увидите с конца. Если вы хотите делать это в памяти то в кеш нужно тянуть весь миллион?

Или вы хотите сортировать только внутри первой тысячи? Обычно хотят сортировку по всем записям в таблице, а не по ее части:)

Я уже не говорю о том, что тянуть 1000 записей, отобразив при этом 50-100 это лишний трафик, время ожидания, нагрузка на базу и т.д.

А если Ваше условие where определит выборку в 50 000 000 записей? Пользователь вообще не дождется формирования такого чудесного кеша.

Я, конечно, не супер гуру в БД, а всего лишь HR - но тут и мне ясно, что так как описали Вы, делать, мягко говоря, неправильно :)