Доброго времени суток! Имеется с десяток идентичных баз. Сейчас рассматривается вариант покупки сервера и серверных лицензий. Было бы неплохо что-то сделать с этими базами. Чтобы бекапить, обновлять и обслужить одну базу а не десяток. Вариантов как я понимаю два: делать указывать разделители данных (тогда надо будет что-то думать с переносом данных в текущую из остальных отдельных баз) или fresh но его как я понял надо докупать отдельно и для 10 баз это как из пушки по воробьям - возни много профита не так много. Поделитесь опытом кто уже настраивал подобное?

http://s019.radikal.ru/i617/1407/f2/f0c0fc649096.jpg

Ну ты как обычно, ни буквы по существу вопроса. Стабильность признак мастерства )

>>Чтобы бекапить, обновлять и обслужить одну базу а не десяток
И в случае получения ошибки СУБД "файл базы данных поврежден", потерять сразу все десять баз, а не одну.
Бэкапить и обслуживать будут скрипты в планировщике.

Дешевле выйдет не покупать mssql, а обойтись бесплатным sql express, и вот здесь отдельные базы только в плюс - 10 гиг на базу надолго хватит при небольшом потоке документов.

(2) Потому что ты не озвучил не одной проблемы, только решение, и накидать другие.

бекап, обновление, обслуживание это всего лишь галочка напротив нужной базы в твоем скрипте. Один раз поставил  забыл. Вообще проблем нет никакой. Тем более каких то 10 баз. Ты же пытаешься решить объединением непонятно что. Получив гемор с обновлениями, с разделениями данных, с бекапами и т.д.

еще и фрешь приплел, вообще непонятно для чего

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

>>Один раз поставил  забыл
Потом добавили еще одну базу, и обязательно к ней забыли или архив или обслуживаение или еще какая нить, хрень. Если все находится в одной базе, то как раз там, один раз поставил и забыл.

>>Получив гемор с обновлениями
Обновлять 1 базу проще чем 10 мне кажется, я ошибаюсь?

(8)>> еще и фрешь приплел, вообще непонятно для чего
Для реализации одной базы на сервере, что тебе непонятно в данном случае?

(7) Опыт чего ты хочешь послушать? у меня был опыт и 20 баз бухии и все в одной, в том числе и зуп. Скажем так вот бекапы и обслуживание меньше всего парят. 1 строку в скрипте один раз добавил и пусть себе бекапится. Т.е. вопрос удобство бекапа  десятый пункт в этом вопросе. К тому же что за условия у тебя такие что каждый день новую базу добавляешь и забываешь её бекапить

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

Фреш не про это.

ты же понимаешь небывает универсального решения на все случае жизни. поэтому что ты хочешь услышать?
К примеру можно слить все данные в одну базу и потом выясниться что при проведении одной организации блокируется вся база. Т.е. кто то проводит - все остальные курят в сторонке.
А можно разделить данные настроить типовой обмен и словить ошибку "объект не найден" когда в одной базе удалили данные, и удаление промигрировало в другую базу и удалилось без контроля ссылочной целостности. Или криворукие программисты в 1С постарались (был такой прикол со справочником РИБ)
Добавим сюда постоянные косяки с РЛС, ибо 1с тетсирует все под полными админскими правами. Хочешь слить и настроить РЛС? Будь готов после каждого обновления писать заплатки и править косяки с правами.
Продолжим?
И вот ты такой геройский слил 10 фирм в одну базу, и к тебе приходит бух и говорит мы там по фирме №3 запороли данные, и нам нужно восстановить из вчерашнего бекапа, а фирму 5 нужно отдать аудитором, и да по фирме 7 придет банк и нужно чтобы там небыло лишних данных, ни справочника, ни документов чтобы мы могли дать им доступ.
Можно долго писать и про общую нумерацию счетов фактур на аванс и про невозможность одновременно по части фирм вести зп в зуп, а часть в БП...

Я уже упоминал что нет универсального ответа на твой вопрос? И уж точно вопрос бекапа это не та проблема из за которой стоит сливать 10 баз в одну

Одно из любимых занятий бухов - наводить порядок путем переименования справочника. Типа о вот элемент который лично я не использую, а давай я его возъму и переименую как мне надо, чтобы не захламлять базу. И в результате вчера была ОС "компьютер" сегодня это уже "здание". Особенно было прикольно со справочником РБП, где задаются срок списания стоимость. И потом начинается, а почему у меня в прошлом месяце списывался по 100 рублей, а в этом по 250 - программа считает неправильно. И ты такой поднимешь бекап и начинаешь играть в интересную игру - найти 10 отличий.

(7) Купи Обновлятор ))

(10) ДАДАДАДАДАДАДАДА!!!
(0) Обновлять базы можно автоматизированно.

Я понял, срач конечно веселее, чем обмен опытом :) давай сначала, я не спрашиваю, зачем оно нужно, плюсы и минусы оно очень хорошо, но если отбросить всю лирику. А тупо оставить факты. У тебя очень много эмоций которые не к месту. Но ты продолжай, я не понял почему ты возбудился, но я с удовольствием послушаю. Давай уже отвечу, не зря же ты старался

>>Фреш не про это
А про, что он? В целом да, он про сотню другую баз 1С, без необходимости плодить сотню другую баз sql. Но результат, то тот же?

(9) >>ты же понимаешь небывает универсального решения на все случае жизни. поэтому что ты хочешь услышать?
Я не спрашивал, каких то решений. Я спрашивал про опыт работы. Какие есть нюансы, что можно, что нельзя.

>>К примеру можно слить все данные в одну базу и потом выясниться что при проведении одной организации блокируется вся база.
То есть да. что-то подобного плана. Запускали, не понравились проблемы такие и такие.

>>Добавим сюда постоянные косяки с РЛС, ибо 1с тетсирует все под полными админскими правами. Хочешь слить и настроить РЛС?
РЛС здесь вообще не при делах

>>И вот ты такой геройский...
Нам не грозят такие вещи, но ок.

>>Можно долго писать и про общую нумерацию счетов фактур на аванс
Это вообще поток сознания... не знаю комментировать или так оставить

(10) У нас нет подобного плана проблем.
(9)(10)У нас базы для торговлю в розницу, поэтому всё фигня давай по новой, придумай теперь кейсы для розницы, у тебя хорошо получается, мне нравится читать.

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

Если сухо Aleksey говорит, что не стоит этого делать по следующим причинам:
1. При блокировании таблиц по одной базе1С блокируются таблицы по всей базе SQL
2. >> когда в одной базе удалили данные, и удаление промигрировало в другую базу
Там разные данные. Как удаление одного элемента может повлиять на совершенно другой мне непонятно. Каким боком здесь вообще РИБ  и синхронизации? Игнорируем.
3. Добавим сюда постоянные косяки с РЛС
Причем здесь РЛС неизвестно. Если мы говорим про разделитель, то база получает отфильтрованные данные до того как можно применить какой либо РЛС. Игнорируем.
4. Проблема в том, что если базы были объеденены, то разъеденить их целая история(как и объеденить собственно). Если данные смогли приехать в такую базу, то смогут и уехать. Косяк в том, что это долго, дорого и сложно. Аргумент.
То есть по факту осталось 1 и 4.
1 не сильно беспокоит, маленькая нагрузка. 4 уже сложнее, но база управленческая, не так критично, но заслуживает внимания.

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

(13) ИМХО. Ты и сам эмоционален. Твой аргумент в пользу объединения-возможность забыть что-то сделать в другой базе с аналогичной конфигурацией. Для этого есть скрипты и напоминалка.
Минусов в объединении больше, чем плюсов. Особенно это касается баз от разных владельцев бизнеса. Объединение допустимо только для одного владельца бизнесом. У разных владельцев должны быть разные базы. Проблема сопровождения баз не должно быть проблемой тех, чьи это базы. Научись автоматизировать администрирование базы и забудешь про свой сабж.

Если говорить про ДИИТ, на 15000 на фреше, то там более 100 нод, на каждой ноде N ое количество баз по технологии фреш. И в каждой такой базе совсем небольшое количество баз с разделителями, даже до 10 иногда не доходит.
Фреш он про то что начались проблемы с конкретной базой -> вырезаем область данных скриптом и переносим на более свободную ноду и меняем данные в управляющей конфигурации.
А так же огромный штат тех кто за этим следит.

(17) 15000 пользователей имелось ввиду

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

(16)>> Особенно это касается баз от разных владельцев бизнеса. Объединение допустимо только для одного владельца бизнесом. У разных владельцев должны быть разные базы
Владелец один. И базы все его, это розничные точки. Периодически добавляются, медленно(раз в год, полгода), может вообще перестанут, но тенденция пока в наличии. Он хочет на каждый магазин отдельную базу. То есть так было изначально и уже сложновато, что-то менять.
>>Проблема сопровождения баз не должно быть проблемой тех, чьи это базы.
Разумеется. Просто переезд на новую платформу и может быть можно было бы как-то сделать более оптимально. Вот и спрашиваю собственно.

(15)(17)(19)Все понятно, слишком много приседаний.

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

(13) О чем писать? Я могу долго писать о проблемах в ЗУП, а потом выясниться что ты спрашиваешь про розницу

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

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

(13) Про опыт. Я с БП с 2006 года, это как раз когда они с 1.0 на 1.5 переходили. У меня порядка 25 фирма, постоянно кто-то закрываются, кто то открывается. При этом порядка 10 главбухов и у каждого свой, не пересекающися набор фирм. Собственно проблемы в 1.5/2.0/3.0 они все разные. где то 1С решила что раньше не работало, где то добавило новые проблемы. Как можно описать нюансы, если неизвестно о чем речь? Об УТ10? О Рознице 2.0 или проблема обменов нескольких баз ЗУП с одной БП. Ты хотя бы кейс обозначь, а пока его нет, сложно с тобой говорить

И как это РЛС не пределах? У тебя все бухи с правами админа и имеют доступ ко всем фирмам, или все таки нужно от некоторых скрыть старые, левые, ненужные? Просто у меня изначально бух не любят когда другой бух имеет доступ к его базе, ор выше гор типа, а  вдруг она что то поменяет, а мне потом отвечать

Часть настроек зависит глобальны для всей базы и независит от организации. В частности настройка ведения ЗП. Т.е. ты в принципе не можешь в единной базе сделать чтобы ООО вела ЗП в бух, и ИП вел зп в бухии

(14)
1. про блокировки - нет это не так. Зависит от конфигурации (в БП 2.0 и 3.0 одно и тоже действие приводит к разным последствиям в плане "ожидания транзакций"). Так жа зависит от наличия РИБ и частоты обмена, этот механизм тоже вносит изрядную долю блокировок

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

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

Не сказано во всем обсуждении самого существенного:

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

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

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

(9) (10) Полностью согласен.
(14) Тебе рано сливать базы, про РЛС надо почитать сначала.Все аргументы тебе правильно Aleksey изложил.

(25) // другой бух имеет доступ к его базе, ор выше гор типа, а  вдруг она что то поменяет, а мне потом отвечать

даже внутри одной фирмочки орут, что когда одна работает в ЗУП, а другая в бухии и не дай бог кто-то там что-то друг другу поменяет.

Ну а по поводу обновления:
1)) Обновлятор
2) 1sscript
это готовые решения
Скрипты командной строки так же работают прекрасно, я работал в федеральной рознице, где было 4К файловых баз с полностью автоматическим централизованным обновлением из поставки.

там это было реализовано очень простыми PS скиптами

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

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

(32) Интересно было бы про это прочитать.

1. в SQL в скриптах есть галочка "применять для всех пользовательских базах" - поставил и забудь про то, что кто-то добавит или переименует в скуле что-то (разумеется при этом на серваке не должно быть хлама в виде копий и баз разработкит... для этого нужен отдельный SQL)
2. можно все базы слить в одну и разрулить все RLS, в твоем случае с магазинами это идеальный вариант

(0) Результат объединения в одной базе будет один - прокачанный скилл решения кучи проблем, которых бы не было без этого объединения.

но на самой деле автор топика не дал еще одного уточнения:
- автор хочет просто залить множество файловых баз в один СУБД сервер, но их у него останется множество информационных баз ИЛИ
ему хочет поупражняться в заливке всего множества баз в одну ИБ ?

(38) Вроде второе из (0) следует.

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

(39) ну не знаю - для меня это второе в топике не очевидно

(4) Почему sql express, а не постгри?

(15) "И про огромное количество технологических проблем, которые до сих пор не решены, есть только обходные пути решения."
Можно подробнее?
Какие там технологические не решенные проблемы?

(0) Приходит налоговая и говорит: дайте нам вашу базу ООО "Рога и копыта - 2". Руководство не против. Твои действия?

(7) Правильный скрипт бэкапит все базы на рабочем сервере.

Вот открыл базу свою во фреше сейчас. Жмакнул справочник.контрагенты - уже секунд 40 думает. у меня там записей штук 20 всего...

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

после киляния - открылось нормально... шаман однако

(47) "она - даже имя-пароль не спросило - запустилось сразу" // Так это ОпенИД-аутентификация. Пока не разлогинился или не прошел заданный таймаут, повторно аутентифицироваться не нужно

(44) НАзачем налоговой твоя база?

(7)
1. в скуле прописываешь регламент для пользовательских баз. При добавлении базы автоматом ее цепляет.

2. если типовые, то обновлятор.

3. В базах главбух одна? Т.е. захотят контрагента или номенклатуру переименовать.
Либо счета учета по папкам настроить, а у бухов своя теория подерутся. Если главбух один то одна база имеет право на жизнь.

Но я за раздельные.

(42) Можно и постгрес, но мс удобнее и предсказуемее как в плане глюков, так и в плане тормозов

(52) главное, бабло не забыть выплатить за лиценизрование, а так-то удобней и тормозит также :-)

(50) Решение этого вопроса не входит в компетенцию 1Сника. Ему сказали - он должен взять под козырек, и не засветить лишнего.

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