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

По каким критериям нужно определять - создавать под каждую организацию свою базу или все вместе вести в одной базе.

Плюсы за много баз:
размер каждой базы поменьше, выгружать быстрее, быстродействие выше
(бэкапы понятно что по времени столько же, я имею в виду ситуацию когда нужно развернуть с сервера копию у себя и что-либо посмотреть-поправить)

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

10-15-20 организаций - все ООО "Ромашка" или есть постоянноиспользуемые ?

(0) как связаны эти организации?
кто будет обновлять зоопарк? если это пильнутая БП - вопрос очень актуальный

(0)Самы большой минус общей базы - если чтото крякнет и она сдохнет, то "кря" будет гроооомкое!:-)

(3) Для этого придуманы бэкапы.

(3) Бэкапы, бэкапы и еще раз бэкапы :)

(0) Зависит от степени "связанности" организаций. Если холдинг с централизованным управлением, одна база практичнее, чтобы потом не консолидировать отчетность.

(0) ИМХО, зависит только (!!!) от проф. уровня бухов.
Если бухи - профи то, да, в одной.
Если есть малейшее сомнение - в разных.

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

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

В свое время стоял такой же выбор.
Подумали что лучше отдельно.

Полюсов как раз больше.

Я бы развел по разным базам.

в общей базе достаточно высокие требования к нси - чтобы бухи не партизанили по справочникам меняя "чужие" реквизиты

Есть еще вариант одна база +РИБ по организациям

(10) чтобы иметь гемор с администрированием?

у нас вот много баз. нереальныйгемор. Будем переходить на одну

(12) ну вот как вариант.

Автор, план обмена по организациям для чего придуман был?

Ответ: чтобы снивелировать мучения автора при выборе вариантов :)

Была бы голосовалка, выбрал бы вариант "РИБ-база" :)

(12) Хороший вариант, при услвовии, что человек понимает, как работает РИБ.
(13) Нет там никакого геммора.
ЗЫ: Говорю не по наслышке. Я в свое время один 790 баз одновренменно сопровождал.

(12) в центральной все равно все организации будут...

(17) Дык не пускать в нее кого попало.

(12) >>  еще вариант одна база +РИБ по организациям

B чем этот вариант отличается от "одна база по нескольким организациям"?
На мой взгляд, ответ - ничем. Кроме добавления лишнего геморроя с администрированием РИБа и всех косяков и проблем, с ним связанных.

(0) Все зависит от постановки задачи и достигаемых целей. В общем случае, лучше вести в одной и рассматривать варианты, против работы в одной. Если таких нет - ответ выше.

(19) Не будет геморроя с правами доступа + администрировать и конфигурять РИБ не в пример проще, чем зоопарк баз.

(13) Какой гемор?

(22) Для начала - с обновлениями.

(16) 790???

(23) Тему про обновлятор видел?

(24) Да. Это была пИковая нагрузка. Всего через меня over 1500 штук прошли.

(25) Косячит обновлятор.

(23) Легче обновить десяток баз, чем разгрести одну оборотку.

(18)+1
Опять же вопрос, всякие передачи товаров между организациями и т. п. имеют место быть? И общая консолидированная отчетность по холдингу нужна?

(23) Вообще не вижу траблов с обновлениями, если только не на +100500 релизов сразу.

(22) Например, тех же пользователей удалять/добавлять в одну базу проще, чем в 100500 (особенно, если есть такие, которым надо с несколькими организациями работать).

(25) При обновлении ЦБ, в РИБ все само уедет штатно

(28) Формировать оборотки не в центральной базе, например.

(31) Можно автоматизировать

(25) Не панацея. Обновление может быть и выборочным.

(21) +1 про права доступа. При таком варианте права доступа на уровне базы)

В случае с РИБ получится вариант "2 в 1" же. Единственный минус - доработки/дополнения по хотелке одного буха в одной организации будут распространяться сразу на все базы. А может, это даже и не минус в случае ТС.

А еще можно сгруппировать эти организации, допустим по 3-5, и сделать несколько баз на эти группы. Критерии группировки разные могут быть. Ну, если нет никаких определенных критериев, то в этом и смысла нет

ИМХО, всё определяется степенью связанности юрлиц.
Вести учет в одной базе имеет смысл исключительно тогда, когда:
1. речь идет о ведении учета в некоем холдинге и/или группе тесно связанных юрлиц, имеющих единые системы нормативно-справочной информации (НСИ) и общую учетную политику.
2. есть реальные потребители единой сводной отчетности (руководство или единая бухгалтерия холдинга, например).

Подобный вопрос должен решаться руководством или бухами (если речь о БП). Готовы ли они выделить ресурсы и обеспечить поддержание единой НСИ и экосистемы во всех юрлицах (довольно трудозатратная задача).

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

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

В ОДНУ! Это сегодня у тебя все 10 одинаковые. А через год в каждой будут свои перделки-свистелки (гл.бухи бывают очень пробивные). И как наступит сдача отчетности, а тебе 10 нетиповых обновить на 6 релизов? Кря.

(0) Одна база и ОБЯЗАТЕЛЬНО централизованно следите за общими справочниками - Номенклатура там и прочее. Ни разу за свою карьеру не видел беспроблемных обменов между базами.

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

добавьте голосовалку: одна, несколько, РИБ.
я "за" несколько, вплоть до "каждой организации своя база".

Основной критерий - это НСИ. Если она общая, то и база должна быть одна.
Ну еще соображения секретности при аудите, если чернотой балуетесь.

Имхо, Dmitrii в (39) все точки расставил.

(43) Ты результаты корявых обменов когда-нибудь разгребал?

(46) А зачем разгребать нормально настроенный обмен?

(39)
Цитата
Все разговоры о сложности или легкости администрирования - слышутся мне бредом. Да, есть свои плюсы и минусы, но они не критичны и вполне решаемы - по-своему в каждом конкретном случае.
КонецЦитаты

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

Запускать такую обработку на рабочей базе неправильно, а правильно будет протестировать на копии.
В копии для разработки как правило не оказывается нужных данных, поэтому приходится рабочую базу копировать к себе и разрабатывать уже на ней.
И тут как раз становится очень важно сколько рабочая база весит. Если там одна организация, то выгрузка-загрузка 5 гигабайт это 10 минут. А если там 50 организаций и база не свертывалась пяток лет, то выгрузить-загрузить её это полдня. И так на каждый чих.

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

(46) нет. зачем обмены?

"размер каждой базы поменьше .. быстродействие выше "

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

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

(48) у меня бп корп с включенным RLS и версионностью. Данные с 2012 года по ~30 фирмам. dt-ник весит 10 гигов. При этом выгрузка занимает ровно 30 минут, загрузка где то минут 40-45
Есть бекап средствами скуля, там теоретически скорость развертывания выше, но мне как то и скорости развертывания из dt хватает

уриб на таких объемов тупо умирает. Особенно когда нужно срочно обновиться

(48) кстати объясни как у тебя за несколько часов на генерировались такие объемы? Если это данные за месяц (10000 документов ... 100000 записей ) то почти все они есть в вечернем бекапе. Или вы бекапы по праздникам раз в столетие делаете? Т.е. какая потребность в получения текущих данных для тестирования?

(54) то почти все они есть в вечернем бекапе


Вот это вот "почти" портит всю стройную картину

(48) >> выбрать 100000 записей из регистра сведений и сдвинуть их на день назад, ну обычная рабочая ситуация.

Это звиздец, если у вас это "обычная рабочая ситуация".
Конечно такое случается, но не каждый день.

>> то выгрузить-загрузить её это полдня.

Что вы гоните? Разворачивание из бекапа базы ~65Гб занимает меньше 10 минут. В случае, когда нужны именно сиюминутной актуальности данные (нельзя брать ночной), прибавим 15 минут на создание бекапа. Итого получаем полчаса вместо озвученных полдня.
В случае более медленных серверов - вместо получаса - час.

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

>> И так на каждый чих.

Рассказывай сказки бухгалтерам. Тут аудитория чуть более квалифицированная.

(56) Ну ок, сказки.
Щас 17-43 по Москве, поставил 75 гб базу на выгрузку в MSSQL. Ради чистоты эксперимента надо бы с утра сделать, а щас просто интересно до 10% дойдёт к шести или нет.

Запустил копирование bak файла с рабочего сервера на сервер разработки (50 метров в секунду) - как раз 75 гигов за 30 минут обещает скопировать. Остаётся порадоваться за ваши серверы, наверное быстрее гигабита сеть :)

(56) Или у вас бекапы лежат на том же сервере, что и базы? тоже вариант :)

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

А это смотря какие критерии главнее. Когда случается нечто неприятное и изымается база для проверки, лучше, когда в ней одна организация.

Для эникейщика удобнее конечно, когда все базы в одной - обнвовлять проще.

(0)Разумеется 20отдельных баз.
Плюсы -
дешево, работаем в файловом варианте, база небольшого размера.
отличная скорость работы - потому что файловый вариант, и потому что тягаешь только данные нужной базы.
Удобно добавлять и убирать организации.
Безопасно.
Удобно ограничивать доступ.

куета - когда будешь продавать одну контору попляшешь с одной базой краковяк

(59) Нифига себе проще.
Ты серьезно считаешь что 50баз обновить сложнее, чем одну, которая содержит в себе 50организаций?

50баз обновлять удобнее и быстрее.

(60) Правдо небольшая беда - ключь тогда нужен из железа.

(63) Офигеть какие люди! Сто лет уже не видно было.
Да ключик нужен железный.

(62) Как минимум дольше и не хило, но в реалиях уж лучче кажный день обновлять, чеп (61)

(64) и я рад

(0)У меня есть несколько организаций, у которых более 100рабочих баз, у одной уже более 200.

(60) какие плюсы? пользователей добавлять в 20 баз, поддерживать корректность и актуальность НСИ в 20 базах. Может удобство только когда для этого есть студент за чашку супа, которому можно доверить эту рутину

(68) Так продай одну из двадцати хотяб, вот тогда и на суп не заработаешь а только на канаву

(65)Скажем так - такие базы пилить нет смысла.
Поэтому используются типовые.
Запустил батник на ночь - к утру обновились все. Только логи прочитал и все.

Если проблема с одной базой - фигня, пользователи работают в других.

Мне разницы нет запускать батник который будет обновлять одну базу или 100баз.
Когда баз 200 уже за ночь не успевают обновляться, приходится в два приема.

+ А недай то жить в управленцах

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

(72) Ты это счас о чём юноша ?

(68) В чем сложность добавить пользователей?
Да я тот самый студент, который делает эту работу - следит за тем чтобы все эти базы работали.

По времени у меня уходит часа 2-3в месяц на одну организацию которая ведет более 200баз.
Тарелку супа наливают.

(72) А разве есть еще какие то варианты?
Разумеется аутсорс бухучета.
Сотни типовых, в файловом варианте.
В одной базе в среднем работает значительно меньше одного пользователя.

У нас 4 базы БП 3.0
Такое впечателение что на компе они воют между собой за ресурсы

(75) ну тогда естественно согласен. в (0) не сказано чем фирма занимается.

(76) Да и х с ними, с тебя то какой спрос ?

(61) обработка которая средствами скуля удаляет данные позволяет освободиться от ненужных данных за 10-15 минут

(75) Не поверишь аутсорс даже не знаю что это, есть такие корпорации.

(79) Правдо ? Ты думаю понял кому это впариваешь ?

(76)производительность труда буха падает

(62) у меня 6 баз зуп и то я периодически парюсь (то пропущу кого нибудь, то обновлю, но забуду запустить в режиме предприятия) А ты про 50 баз говоришь

(81) правда.

(82) Если это бух,а не продажник - какой на разговор о производительности ?

(79)Да ну нафиг.
А если освободиться это выгрузить организацию и отдать клиенту?
Т.е регулярно идут клиенты, и тащат свои базы.
И бывает уходят клиенты, и базы нужно отдать.
И в штате ни админа ни программера, ибо нафиг не нужен.

(84) В том смысле, что вкурил кому ты туфту гонишь ?
Типо все пучком и бухи не косячат ?

(85)например когда надо кучу документов для банка подготовить. Или НДС все сдают в последний день

(83)Как можно пропустить одну базу?
Это надо залезть в список баз и удалить ее оттуда, тогда пропустишь.
Я за месяц обновляю более 400баз, и как то не представляю как можно пропустить.

(86) Ну а кто говорит что есть универсальное решение? Помоему изначально как раз и сстоял вопрос как связаны между собой фирмф и НСИ.

(87) косячат, но как это сказывается на общую базу?

(88) А причем тут адинес ?
Кучу это только у торгашей, так тогда базы монолит.

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

(89) да вот так, позвонили, отвлекли, нужно срочно другой задачей заняться

(91) А как это касается договоров "забытых" не от той конторы и вообще инвестора другого ?

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

(95) а не так не косячат, они у меня жестко поделены на фирмы, и соответственно включен RLS. Т.е. друг другу не мешают. Максимум могут каку выкинуть типа заполнить подразделения в складе или изменить общие счета учета. Но обычно хватает один раз сказать, что так делать не надо

(97) И никто никого не подменяет по декрету или прочему кредиту ?

(94) Как это отвлекли?
Ты же не будешь обновлять руками более одной базы?

Обновления запускает планировщик задач - одно обновление.
В текстовом файле список баз.

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

Если проблем нет, то оно по полгода работает, без твоего участия.

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

(99) я по старинке

(99) Ну тут ты аут, и нам/мне "не понять"

(100) + и ? Не косячит ни разу ?

(103) нет ибо у них и так по дефолту 2-3 фирмы, они люди привычные выбирать фирму

скажем так если и косячат, то я об этом незнаю, ибо сами свой косяк правят

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

(101) Когда работаешь с кучей фирм и фирмочек занимающихся бухуслугами по старинке не получиться.

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

(0) >По каким критериям нужно определять - создавать под каждую организацию свою базу или все вместе вести в одной базе.

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

(106) у нас такого тоже нет, т.е. фирмы тоже жестко поделены, кто услугами занимается, кто закупками, а кто продажей в розницу, т.е. массовой замены договоров у нас нет

Я за много баз с опциональной консолидацией в единой базе (которая будет раздавать конфигурацию и НСИ в периферийные, но не встроенный РИБ, а сторонними средствами).

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

(110) а откуда вдруг - что НСИ должна быть общая.

(111) или так

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

(112) "опциональной"

Вот и приперлись, что все по случаю.

Лучше расскажите как при 77 избавиться без "сортировки" не меняя бакэнд, как обойти скуль без замены скульдривер понятно, а как не трогая бакэнд в 21 работать на 2012 м- 2016 м ?

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

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

Что там контролировать?

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

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

У меня тут вопрос. Вот база для 1 организации 100 гигов для 20 организаций назовем "очень большая". В принципе она запуститься если все в одну собрать?)
2 организации всегда вопрос надо ли в одной базе, а 20 организаций?

угу, сложив фсё в одну корзину проще

Получаем копию от заказчика для получения данных в консолидацию, нам нужны 5 из 30 организаций, но мы грузим копию весом базы в 500гиг. Организации никак не связаны друг с другом кроме единой конфы.

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

(123) + Если это не консолидированные данные и не общая НСИ, то все раздельно, обновление не проблема, делается поставка 1раз и обновляются все базы

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

Если просто аутсорс и требуется мобильность баз  загружать - выгружать, то отдельно, если это ГК, связанные юрллица, то общая, да и обновлять одну базу это не тридцать.

(126) Час? Нуну... Я помню, делал первичный обмен ут-бп неделю, ибо полная выгрузка просто падала по памяти...

+(121)Забыл проголосовать

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

(121) Запустится. Никогда не работал в организации крупнее ларька?

я за РИБ

у меня бухи всегда просят отдельную ставить... им так проще типа... ну хотят, нате... ))

(128) ау, настройка! сам процесс по времени непредсказуем)

(128) А через прямое подключение и со скульными базами пробовал? Я так мудохался с отпочковыванием, тоже с нехваткой памяти валилось, пока не запустил выгрузку начального образа в клиент-серверную базу вместо файловой - все прекрасно взлетело. Потом уже файловую в dt вывалил.

(134) Дык сервер надо было бы купить ещё.
А стащить базу оттуда - там такой интернет, что быстрее было приехать на место (3 часа на автобусе), забрать базу и вернуться...

(133) А сама настройка делается 5 минут, а не час

Все не читал...

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

+ Как-то так...

(137) Смотря чья эт точка зрения. Бух, админ, рук - у каждого своя колокольня )

О каких базах говорим?  для управленческого учета, для бухгалтерского или общую для всего.
Тут на 1 организацию иногда выгоднее 2-3 базы завести для разных целей. а вы на нацать пытаетесь решить по ТЗ в 5 строк.

(131)Я видел базу в 500гиг на sql это была просто опа. Админы бекап поднимали 2 дня - не смогли. Я не знаю что будет с базой в терабайт или 2 терабайта, я таких не видел, но проведя аналогию, думаю рухнет она очень быстро.

(141) Я видел базу на скл в 1.5 ТБ. Поднималась около 4 часов.

(142)Поверим на слово что такое может быть, но даже 4 часа не приемлемо. Тем более что если база станет то станет не одна организация, а сразу 15.

(141) Смените админов.. докупите железо и версию скуля.

(144)Я не стал устраиватся в эту организацию) На мой взгляд это не нормально когда база столько весит. 200гиг, ну 250гиг это потолок.

(145)  А у  MS  взгляд другой .  В характеристиках СУБД все указано .

(127) + 100

Из интереса, есть пример организаций, где все объединили в одну базу, При этом оборот каждой организации в день хотя бы 0,5 млн$? (организаций чтоб было штук 10) И интересен вопрос останавливалась ли база в такой организации, если да то какова была реакция и сколько времени восстанавливали?

(148) в таких организациях обычно все поделено на фронт офис. бекап офис и т.п. под оперативную работу своя база для аналитики своя для бухгалтерии свои. соответственно для оперативной работы фронт офис легок и легко поднимаем. А то что аналитика какое то время простоит не столь критично.

(148) чем я не пример?

всего 20 рабочих организаций, у самой маленькой оборот за март (ДО 6201) 400 тысяч, у топовой 75 млн в среднем (итого /20) 15 млн, т.е как раз 0,5 млн в день (15000/30)

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

(151)Я может не правильно вас понял 75млн руб в месяц? Если так то получается не больше 50к$ в день(в среднем) - это очень мало.

(152) тебе что именно интересно? есть количество записей внутри транзакции. Одна транзакция в день на 1 млн или 10 тысяч транзакций в день и в каждой в среднем по 2 тысячи рублей - тебе какой вариант интересен?

(153)Мне интересен вариант когда много записей, как в крупных фирмах.

(154) ну вот у него в базах, точнее в организациях, записей достаточно много. Я так подозреваю, что их возникновение происходило сразу по территориальному признаку, а затем мелкие сливались в более крупные, пока не возникло текущее состояние. Мне Алексей немножко рассказывал и я догадался где он работает :) Или даже он мне об этом прямо указал - уже не помню, как это произошло, за давностью лет.

Всё от ситуации. Для одного хозяина в одном флаконе, а для разных - в разных. По моей статистике удобнее отдельно, т.к. разбираться проще и отдавать базу проще. А обновление делать на автомате.

только так