Вот именно так и связано. В бета версии анонсировано то, что наконец начинается нормальное использование клиент-серверных технологий. Не прошло и десяти лет с тех пор, как я посмотрел первые версии под MS SQL. И когда это действительно заработает - пока не ясно. Мало того, под это придется, как я понимаю, переделывать клиентскую часть. И, в общем-то, все текущие разработки пойдут лесом.

Я это говорил? Я почитал материалы по ссылке. Пока это анонсы и реклама. Такую же рекламу я видел, когда пробовал (повторюсь) первые версии под сиквел. Только, как выяснилось, версия под MS SQL работает медленнее, чем версия под DBF. А чтобы добиться такой же производительности и хоть какой-нибудь масштабируемости надо было затратить весьма неслабые деньги на оборудование. И все равно больше 100 пользователей система нормально не тянула.

Вы странный человек... Я говорю про недостатки архитектуры, а Вы мне рассказываете какая хорошая будет разработка в новой версии

К своему сдыду, не знаю разницы . Объяснять не надо, сам прочту .
Извините, я не понимаю, о чем Вы. По моим оценкам платформа будет отшлифована примерно в течение 5 лет. Клиентская часть переделана и имеет 3 варианта (по ссылкам инфа есть). Думаю, что не все текущие ...
На малых объемах SQL ВСЕГДА работает медленнее DBF. Меня это не удивляет. Но сделать так, чтобы на больших объемах данных SQL работал медленнее ... это надо постараться, ИМХО.

Прим. Конфигурации, т.е. логические наработки конвертируются под новый формат. До сих пор с этим проблем не было.

Да, даже текущая 8.1, не обладающая всеми прелестями платформы 8.2, уже держит 100 юзеров. Можно, конечно, ткнуть пальцем в SELECT *, но, думаю, юзеров это мало колышет, если нет тормозов. Давайте еще свободное место на диске обсудим для смеху.

Все же придется объяснить, что я имею в виду под select * и fetch all
В 1С под сиквел делалась очень простая операция: на сервере выбирались из таблиц ВСЕ данные, без ограничения по каким-либо условиям, и ВСЕ эти данные тащились на клиента, где и происходила ВСЯ обработка. Причем раньше, я не знаю как сейчас, если посмотреть на структуры базы 1С, то не было даже чужих ключей, т.е. не использовался механизм обеспечения целостности данных, предоставляемый СУБД.
К чему я это, если в новой версии ВСЯ обработка будет убрана с клиента на сервер, то придется переписывать ВСЕ приложения, которые до этого работали на клиентской части, а сейчас будут каким-то образом работать на сервере приложений. Если все будет реализовано, как написано, то рекомендую забыть даже термин "конфигурация 1С". Это не "новый формат". Это принципиально другое.

Мама! Роди меня обратно! Запросы к базе, начиная с версии 1С 8.0 интерпретируются сервером приложений в запросы MS SQL и выполняются на самом MS SQL. Клиент получает исключительно результат выборки.

Прим. Про ключи не скажу, т.к. не до конца на текущий момент понимаю их механизм.

А я про что? Клиент получает результат выборки.Только эта выборка ничем не ограничена. Мало того, fetch all - это выборка всех данных по селекту.
Даже не знаю, как объяснить Вы с SQL работали? Вы визуально видели, как работает выборка по селекту? Первые результаты появляются мгновенно, но сервер не продолжает вытаскивать данные дальше, пока об этом не попросит клиент. И если попытаться перейти на последнюю запись в наборе, получаемом по конкретной выборке, то операция займет уже большое время. Которое будет, как д.б. понятно, увеличиваться при увеличении количества записей.
Так вот 1С работала (работает?) по наихудшему из всех возможных вариантов.
1. Из таблиц, необходимых на клиенте, выбирались ВСЕ поля
2. Из таблиц вытаскивались ВСЕ данные и отправлялись на клиента.
В результате, для полноценной работы сиквела, надо очень нехило увеличивать оперативную память сервера, чтобы как можно больше данных легло в кэш СУБД. А еще мы сильно грузим сетку, поскольку поток даных, с увеличением рабочих мест, растет просто катастрофически. Плюс ко всему большие объемы данных, которые вынужден получить и обработать клиент - ведут к необходимости наращивания ресурсов на клиенте.

avlag, Ааааааааа, вон Вы о чем... Ну эта ... проблемы индейцев. Оно это сильно нужно для реальных задач на 100 юзеров? Может и нужно, но пока и так работают. Маркетинг рулит, мать его .

Ну вот мы и вернулись к стоимости железа
Повторяю, за 20k зеленых, на которых работает 100-200 пользователей 1С, для SAP'а, на 200 пользователей, я могу собрать неплохой отказоустойчивый кластер. Т.е. два сервера с внешней дисковой полкой.
Вот и вся разница между нормальной архитектурой и неоптимальной. Ку?
Кста, когда Вам придется общаться с клиентом, для которого существует понятие "допустимое время простоя", и измеряется оно значениями меньше часа, Вы поймете и прелести масштабируемости SAP'а, и его возможностями работы в кластере и разницей в затратах на реализацию всего этого в SAP и в 1С

Мммммм, я все-таки о рельных потребностях реальных компаний. Среди них есть достаточный кусок, который устроит скорость 1С, а нехилые "бантики" интерфейса усилят желание выбрать именно 1С. Это очень серьезные "бантики" .

Прикиньте, если скорость достаточная, а разработка объекта происходит в 5-10 раз быстрее .

Вот мы и пришли к согласию
Кому нужны бантики - выбирает 1С, кому нужна серьезная работа -...

Прикиньте, а компания взяла, да и начала развиваться

Мне кажется, что у нас разные понятия о серьезной работе .