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

Желательно с сайта 1с.ру или итс

Выдержит. Пользователи могут не выдержать

ну ломай ты им раз в неделю базу, трать по 1-2 часа на восстановление. скажи, что когда перейдете на клиент-сервер ломаться перестанет

10?! Да оно после трех уже еле живет, особенно на УФ

Всё зависит не от количества пользователей, а от их интенсивности работы. Если 10 пользователей заносят в базу пяток документов в день, а остальное время смотрят отчеты - т файловой базы вполне хватит.

(4) даже 10 пользователей по пяток документов в день вполне могут назабивать документов на блокировки. Все помнят как ходят трамваи в Москве? Доиграли в домино и поехали всей бандой :D

И в очередной раз позволю себе утверждать, что файловая база в разделенном доступе - зло. Только веб-сервер!

(6) А вот чтобы минимизировать блокировки - не надо работать в файл-серверном режиме, гоняя сотни мегабайт по сети. Веб-сервер позволяет проводить документы за пару секунд.

(7) Не верно ты рассуждаешь. При использовании веб-сервера блокировок не будет только по тому, что с базой будет непосредственно работать только веб-сервер. И он работает с базой в один поток, выстраивая все запросы в очередь.

(6) а почему веб?

(7) а чем RDP плох?

(8) В очередь? Т.е. практически при большом объеме запросов все станет колом?

(11) "кол" буде меньше, чем по сети, но больше, чем по RDP

(8) Смотря как настроить веб-сервер

(11) Думаю, что самым узким местом тут всё равно будут жесткие диски, поэтому...

(0) https://1cers.ru - там многажды указано это

(13) Есть пруф?

(13) Вот мой пруф:

"Прямо в адресное пространство веб-сервера загружается компонент для работы с файловой базой данных и сами данные информационной базы. При этом нагрузка на веб-сервер значительно возрастает, а пользователи одной информационной базы не имеют возможности работать параллельно. Все их запросы к базе данных выстраиваются в одну очередь."

http://v8.1c.ru/overview/Term_000000034.htm

https://infostart.ru/public/239498/

(10) Его покупать надо и он весьма недешев. Собственно сервер и тс-калы к нему. А веб-сервер халява.

(17) Это теоретическая страшилка. На практике работа через модуль веб-сервера по скорости практически как локально на консоли сервера. Да, очередь возможна, но крайне маловероятна - при 2-секундных серверных вызовах.

(20) Да мне то зачем объяснять, я свою точку зрения ещё в (14) высказал :)

(18) Познавательно, спасибо.

(16) Если у каждого пользователя будет своя публикация, то конфликтов не будет

мне здесь понравилось
http://www.gilev.ru/mssqlvsfile/
но хотелось бы конешн более официальную ссылку..

(24) [но хотелось бы конешн более официальную ссылку..]
её не существует

(24) хочешь, чтобы 1С официальную справку выдала, что файловая- омно? )

В свое время, пару лет, в терминале на УТ файловой работало порядка 30 пользователей.

(26) не омно, а рекомендации

(27) Если это старая добрая УТ 10 - почему бы и нет.
А вот УТ 11 и БП 3.0 - это уже ой.

(28) сайт белова пошурши. кажись, видел там типа рекомендаций.

http://its.1c.ru/db/metod8dev#content:1998:hdoc

>>>На начальной стадии можно работать в файловом варианте, а затем с увеличением количества пользователей и объема базы данных можно легко перейти на клиент-серверный вариант.


>>>В версии 8 также переработан и файловый вариант работы с информационной базой, рассчитанный на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети.

(31)+ а еще там диаграмка очень занимательная....

http://v8.1c.ru/overview/Term_000000034.htm

Из ссылки:

Файловый вариант работы рассчитан на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети.
...Однако, разумеется, использование клиент-серверного варианта обеспечивает большую надежность, так как в нем обеспечивается полная независимость записи данных на сервере от сбоев клиентских компьютеров и локальной сети.

Ничего более подробного и толкового от самой 1С на тему ветки я не встречал.

(0) Проблема в том что если 1с даст информацию, то те люди у которых оно работает в файловом варианте и у них больше 10 пользователей очень удивятся. Как сказали ранее все зависит от  интенсивности работы. Так что лучше не искать то чего нет.
у меня работает порядка 10 пользователей в упп в фаловом варианте 3 года не жалуются.

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

косвенным подтверждением является http://www.1c.ru/news/info.jsp?id=17577

фактически 1с признало, что последние конфигурации в файловом режиме даже менее 5 пользователей работают неудовлетворительно

данный продукт был выпущен после моей публикации :)))http://catalog.mista.ru/public/190375/

конечно не одной моей, там была прямая линия вопрос/ответ (это показывает на сколько вопрос актуальный)  
http://catalog.mista.ru/public/194059/

>>>>Вопросы к производительности прикладных решений в файловом варианте работы нам известны, мы ведем работу по устранению выявленных узких мест

(36) Всё это конечно прекрасно, но на практике мини-сервер нужен для поддержки старых конфигураций на обычном приложении. Управляемое прекрасно работает на веб-сервере.

(37) включи RLS и ты все поймешь....

(38) RLS как правило не требуется для бухгалтерии с 5 пользователями. Ибо они все в какой-то мере взаимозаменяемы, и должны иметь доступ ко всей базе.

(39) я где-то говорил про бухгалтерию? возьми документооборот...

(40) Опять же - нафига документооборот для 5 пользователей?

(41) в компании 10 000 человек, в документообороте 2 человека фигачат входящие и 2 исходящее, еще человек 5 периодически туда входят "посмотреть"

(42) Ну так мини-сервера для этого может не хватить. Захотел человек "посмотреть", не пришло ли ему что-то важное по работе - а фиг, сервер говорит "не пущу, лимит".

(38) Типовые RLS из БСП это и на клиент-сервере жесть. В десятки раз можно получить падение производительности.

(44) + Универсальность и простота использования это круто конечно. Но не такой же ценой!

(36) Очень хорошая и интересная работа (ссылка). Спасибо.
Лично я хотел бы добавить, что уничтожение 7.7 было ошибкой. Все пользователи, которым сейчас предписана файловая система, чудесно могли бы работать на 7.7. Кто умнее,тот и продолжает работать.
И ещё: у меня сложилось впечатление, что 1с сворачивает франчайзинг. Эти и объясняется отсутствие всякого стиля в программах конфигураций и установка на неизвлекаемость ошибок.
Кроме того, работа на уровне sql вместо 1с - это дорога в никуда: системная зависимость, зависимость от конкретного исполнителя и прочее.

(46) Ну вы как маленький. Зачем продолжать развивать старую платформу, если можно выпустить на рынок новую и еще раз взять за неё деньги?)

Работа на уровне sql хоть как то спасает положение со скоростью,так как выбор всех данных из sql,передача их в память сервера 1с и обработка там,приводит к существенным замедлениям.
Также нужно понимать,что в этом случае,транзакция будет блокировать все считанные данные,а не только те,которые нужны для дальнейшей обработки.
Опять же,применение индексов возможно только в запросе sql,а при считывании всего и вся мы переходим к полному сканированию.
Конечно,если бы сервер 1с мог бы сам отслеживать данные блокировки и использовать один запрос для нескольких сеансов клиентов,отслеживая последовательность изменений,но это требует серьёзных изменений в идеологии,и 1с пока идёт в противоположном направлении,когда сервер 1с является лишь прокладкой между формами клиента и сервером sql,причём даже не помнит,что спрашивал клиент в прошлый ращ

(47) Да, но перед людьми стыдно. они работали в какой-нибудь ТиС, ни в жизни не обновлялись(кроме формы счф), и всё у них было хорошо. Потом появилась 8.0, всё упало и только сейчас чуть поднялось. Но грянуло управляемое приложение и т.д.

(48) индексы вовсю применяются в 1с, нужно только их правильно расставить. Кроме того, разаработчиков 1с никто не заставляет замедлять запросы по сравнению с голым sql.
Как не делают этого в php.

Вот интересно: почему они не сделали доступ к mysql?

(48) после "Также нужно понимать,что в этом случае,транзакция будет блокировать все считанные данные,а не только те,которые нужны для дальнейшей обработки" не читал

(51) потому что на самом деле она тормозит на чуть более сложных чем 1-2 джоина запросах

(0) На УФ она еле ползает даже при одном пользователе

(53) можешь сам сравнить мускуль со скулем на произвольных :)

http://nevlabs.ru/products/sql-server-vs-mysql-test/

да разница есть, но она не такая большая и кроме того она не всегда в пользу скуля....

(55) добавь пар миллионов записей в таблицы мускуля и сделай джоин с джоином с двумя еще такими же таблицами

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

(56) даже мелкософт http://www.microsoft.com/sqlserver/2008/ru/ru/compare-mysql.aspx

в сравнении не приводит конкретных цифр, а тупо пиарится общим словоблудием...

"Мощный, высокопроизводительный оптимизатор запросов, работающий на основе учета стоимости операций позволяет повысить эффективность выполнения сложных запросов. MySQL обладает только оптимизатором начального уровня, который не оптимизирован для высочайшей производительности и, таким образом, обладает ограниченной масштабируемостью."

Учитывая, что 1с не использует всей мощи скуля и имеет много маленьких запросов (на динамических списках и рельсе) думаю вполне реально провести тесты сравнения запросов генерируемых реальной базой 1с...


сделай, будет хорошая статья :)

(0) Зачем?

(53) Ну, видимо, не больше, чем файловая? К тому же,не обязательно всё делать в запросах. Просто, использовать, как внешнюю память?

(59) они используют 30 активных пользователей в файловой базе и удивляются, что все тормозит

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

MySql,например,имеет тип базы данных,хранимый в памяти,а также оптимизированные род текстовые данные структуры хранения
На больших запросах он,конечно ляжет,но если без них обойтись,то может даже сделать меокомягкого на скорости выборки.

вы хоть не сравнивайте попсовый mysql для сайтиков и промышленные БД к которым только постгрес более менее приближается

(64) но не у всех миллионы записей. Есть небольшие фирмы, которым mysql будет вполне по размеру. До 100 документов в день. Возможно, их даже большинство.

(0)"Дайте плз ссылки на то, где указано, что файловая - ненадежная и не выдерживает более 10 одновременных пользователей." нет таких ссылок. Ибо это неправда.

1)
У файловой базы нет лимита на соединения, поэтому хоть сотню выдержит.
НО! Файловая база блокирует не конкретную запись, а целиком таблицу. В итоге пока один юзер работает с таблицей, все остальные нервно курят.
Пока пользователей мало, это незаметно. Когда пользователей много можно часами сидеть и ждать пока таблица освободиться.

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

3)
У файловой базы есть ограничение в 4Гб на размер таблицы в БД.

4)
Работает с файловой базой данных файловая система, которая оптимизирована для работы с файлами вообще, а не с файлами баз данных в частности. Поэтому при больших объемах файла работа не очень эффективна.

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

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

(64) вообще мускуль уделает мелкософт на базе в терабайт по определенным запросам.... не надо хаять мускуль, это очень крутая субд...

(66) я добавлю, что в файловой нет ХП со всеми вытекающими от сюда, нет защиты и т.д.

(67) гоняются не таблицы а блоки, при этом блокируются не таблицы а только заголовки таблиц... по этому таблица целиком гоняется только при фулскане без индексов...

(69)Что означает аббревиатура  "ХП" не совсем понял, можно развернуто?

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

(71) хранимая процедура

(72)А, дошло.