Всем доброго времени суток.
В наличии есть серверная 1с с количеством баз около 100. Пользователей всего 2-3 человека.

Подскажите, на сколько правильно в данной ситуации будет перенести все на файловые базы вместо SQL? Пользователей больше 3 точно не будет, одновременно могут работать в 2 базах.

Хотелось бы оптимизировать серверные ресурсы, т.к. сейчас большая часть уходит под MS SQL и регламентные задания (типа индекса полнотекстового поиска).

Объем баз какой?

(0) Файловая однозначно.

Если во главу угла ставите экономию ресурсов, то наверное оптимальней файловые. Но по мне так это экономия на спичках.

В среднем 400мб. есть пара баз на 1 гиг.

(1) В таком режиме не может быть очень больших баз.
Я так понимаю что это обслуживающая бухгалтерия.

(5) Она самая :)

(3) Если хочется быстрой и удобной работы - файловая.
Иначе серверная.

(6) У меня на обслуживании шесть штук таких :)

(7) Вообще между словами  "хочется" и "правильно", есть огромная разница и уровень понимания этой разницы как раз и характеризует специалиста.

(9) И что же по вашему правильно?
Вы вообще знаете для чего нужна SQL база, в чем ее отличие от файловой?

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

Не спорю - это грамотно и правильно. Но ради небольших баз городить SQL сервер мне кажется перебором.

(10) Я уже все сказал, дальше вам решать это ведь ваши базы, ваша ответственность за ее целостность и сохранность, если ваша ответственность стоит дешевле чем соответствующее железо то вы совершенно правы.

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

(12) Уважаемый, сказать можно что угодно. Надо бы аргументировать.

(12) (14)  Давайте только без холивара?

(14) Я уже намекнул что тут надо оценивать риски.

Грамотно и правильно это когда софт и архитектура подобрана под задачи.
В данном случае клиент серверный вариант это неграмотно и неправильно.

(16) Какие именно риски?

(17) А задача какая? Если сэкономить на железе то да, а если обеспечить бесперебойную работу, сохранность и безопасность то нет.

Есть штатный вариант работы 1с - файловый.
Это наиболее быстрый и удобный вариант работы.
Но он имеет некоторые ограничения.
Например ограничен размер баз - если таблицы большие база не сможет работать на файловой.
Или проблема с блокировками при множестве одновременно работающих пользователей.
Поэтому если вы упираетесь в эти проблемы, либо есть вероятность что упретесь в них в ближайшем будущем, нужно не жалеть денег  и переходить на SQL.
И это будет правильно и грамотно.

Если же не упираетесь - преходить на SQL не нужно. И это будет правильно и грамотно.

(19) Ну хотя бы бесперебойная работа - с ней уже проблема.
Появляется дополнительная точка отказа - SQL сервер.
Он упал и упали все ваши базы. И вся работа стала.
А в файловой - упала одна база, да пофиг пользователи работают   с другими.
Нужен постоянно дежурящий сисадмин, который будет добавлять базы на сервер.
Потому что базы тут регулярно меняются - один клиент ушел, надо отдать базу, другой наоборот подписался на обслуживание, надо добавить базу.

В случае с файловой - это прекрасно делает и бухгалтер.

Если есть SQL рабочий, то зачем переводить все на файловые? Чтобы потом бэкапить 100 баз вручную? Чтобы удалить могли легко и просто папку с базой а потом искать?

(22) Ресурсов жрет немерянно.
Бэкапить в случае SQL сложнее, удалять, перемещать, добавлять тоже.

(21)
"А в файловой - упала одна база, да пофиг пользователи работают   с другими.
Нужен постоянно дежурящий сисадмин, который будет добавлять базы на сервер. ..."


Вот поэтому тебе денег мало и платят....

(0) где планируешь хранить файловые?
Пользователи со своих компов запускают или в терминале?

Бухгалтера насоздают этих баз у себя на рабочем столе или вообще фиг найдешь

(24) Нормально платят.

Кстати они могут создавать, а потом админ пачкой переносит на сервер

Может настроить регл задания? Поотключать лишние. Обработкой можно

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

SQL хорош когда с базой работает десяток и более пользователей в среднем.

А в данном случае с базой в среднем будет работать 0,1 пользователя.

(30) предлагаешь бухгалтеру создавать папки и прописывать остальным эту же базу?

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

(32) Зачем?
Там работает несколько бухгалтеров.
К одному принесли базу на обслуживание, он ее кидает на файловый ресурс общий.
Если кому-то надо еще с ней работать - пропишут в 1с путь и все.

(33) Переубеди аргументированно.

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

Или ты работал с организациями которые ведут исключительно учет своих данных в двух базах? И у них в этих двух базах работают сотни пользователей.

(35) Зачем? Мне сдается у нас с вами даже на уровне элементарных терминов уже непонимание. Ликбез не входил здесь в мои планы.

(37)Каких именно элементарных терминов?
Вы не зная ситуации советуете что попало.
Не думая для чего оно нужно и почему.

Просто кто-то сказал вам что SQL это круто, вот вы теперь все готовы на SQL перевести.

А умные люди оценивают что именно в данном случае нужно. А не руководствуются идиотскими догмами.

(23) > Бэкапить в случае SQL сложнее
В каком месте сложней?

(39) Ну бэкап SQL делать чем то кроме средств SQL не стоит, ибо будут проблемы.
Т.е выбор механизма бэкапа ограничен штатными средствами, нужно настраивать планы бэкапа для большого количества баз, во время бэкапа идет приличная нагрузка на сервер.

(25) Файловые на сервере. Доступ по RDP (RemoteApp) или веб. Пока не решил что удобнее будет.

Бэкап на уровне всей вируталки ежедневный.

(41) Бэкап удобнее делать через теневые копии.
Включаешь теневое копирование каждый час или каждые два часа - в случае проблем можно будет откатить базу или все базы на нужное время.
Бэкап - подключаешь нужную теневую копию, упаковываешь в архив, и в хранилище.

А зачем виртуалка?

(42) Сервер в облаке, так что по факту это виртуалка :)

(43) Тем более данные в данном случае нужно бэкапить отдельно.
Причем бэкап с данными желательно хранить по месту работы.

(44) Думаешь через теневые копии лучше будет?

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

(45) Главное саму теневую копию бэкапом не надо считать.
Это вещь ненадежная.
Т.е сделал копию, а с нее уже бэкапишь.

Давно ли файловые стали быстрее скульных? 1с точно не 7,7?

(48) 1c 8.3, редакция 2.0

(48)Да всегда были.
Сравни скорость работы файловой базы размером 0,5Гб работает один пользователь с тем же самым на том же оборудовании с вариантом SQL.

(50) Отчеты, оборотки, карточки тоже быстрей на файловой?

(51) Да.
Исключения - очень большой объем данных, т.е большая база. Т.е не этот случай.

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

Пока у тебя 1-2 пользователя и небольшая база - никаких преимуществ от SQL не будет, одни недостатки.

(53) Небольшая и большая база по твоим меркам - это какие?

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

(54) Которая не упирается в ограничения файловых баз по таблицам.
Для бухии небольшая обычно 400-4000Мб в этих пределах.
Больше бывают крайне редко.

Среднестатистическая база в районе 500Мб

Для семёрошных бухфирм перенаправлял в базах на единый общий КЛАДР. В восьмёрке можно вынести эти таблицы в какой-нибудь модный внешний источник данных?

(58) Нет. А зачем?
Места на диске  жалко?

(58)Хотя если извратиться можно придумать и в восьмерке подобное, но более хитрым способом.