И интересно кто сам пробовал что свое писать, как впечатления по скорости, и при больших нагрузках?

а почему нет под Firebird 1С?

(1) а почему нет под MySQL 1С?

херня всё это. пусть вернут поддержку dBase!!!

(2) а хз

БД NoSQL предназначены несколько для других целей.

(0) поскольку БД NoSQL не существует в природе, то не удивительно, что 1С её не поддерживает

(2) MySQL, он вроде по умолчанию без поддержки транзакций, если их включить то получится msSQL :)

+(6) это не БД, а _концепция_ БД

и ещё этот... paradox тоже надо

(6) ну не так сформулировал, я в общем случае, просто начал о них читать :)

интересный ты.

они поддержку постгри с DB2 с ораклом до сих пор не могут поднять на уровень mssql, а ты хочешь с них поддержку каких-то мифических БД, предназначенных для решения совсем других задач

Ну я сам кто-нить пробовал в своих проектах использовать?

(12) ты конкретику будешь делать, или так, потрёкать зашёл?

что именно? Lotus Notes? давно уже используют

насколько понимаю, no-sql оптимизировны для быстрой записи, но не чтения, логи чего-то хранить удобно

(12) couchdb использовал, для домашних подделок.

(11) Вау. А где пруфы?

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

Согласен что можно и любую поробовать БД взять, но... услышал новое слово :)
Пока то что нагуглил, то базы NoSQL (Пока смотрю на MongoDB) как раз для таких задач...вроде...

(17) 1С то здесь каким боком с её транзакциями и OLAP структурой ?

сделайте уже 1С под wiki:Cach%C3%A9

если 1С сделает  под Firebird,  MySQL  то это будет РАВНО как и под postgresql  db/2    ТО ЕСТЬ такая же попка

FireBird заточен под изоляцию транзакций с возможностью их параллельного выполнения и существования множества версий одного объекта в системе - для 1С это как раз и не нужно (ну не будут же один документ править в режиме, кто быстрее).
MySql рассчитан на работу с текстовыми данными, и транзакции там появились только в последних версиях и только в одной системе хранения данных. Все оптимизации MySql делаются для возможности многопользовательского доступа на чтение, что обычно нужно в связке с php и Web-серверами.
Конечно, можно пытаться научить 1С работать с чем угодно, но расширение диапазона систем хранения данных требуют унификации механизма хранения данных, а также реализации внутри 1С того функционала, который некоторыми системами не поддерживается, что скажется отрицательно на скорости.

Все это ваше "Хорошо" на новом, до поры, пока размер БД не превышает 100 элементов.
При достижение определенного размера, вы действительно начинаете оценивать возможности той или иной СУБД :)

К примеру, был у нас Старичок, на Визуал Фоксе писал свой клиент.
Так вот по началу оно работало, и быстро.

Секрет был прост.
1. Объем информации не превышал и обычную дискетку.
2. Данные не позволяли анализировать прошлые периоды, т.е. небыло попросту истории. Т.е. Пользователь ввел сегодня одни циферки, а завтра получил другие, т.к. ввел новые.
3. С таким подходом 1С будет попросту летать ;)

(19) а эта штука и правда очень крута. Производительность и скорость на больших базах очень хороши

Интересная база Redis очень быстрая, но не самый сильный поиск по ней, если нужно поиск по ней. И нету агрегатных функций. И самое фиговое для меня, нельзя математические операции сделать прямо в запросе.

А MongoDB реально очень интересная. Очень гибкая и быстрая. Думаю MongoDB будет иметь хорошие развитие