Вход | Регистрация
 

Несколько баз 1С в одной базе SQL

Несколько баз 1С в одной базе SQL
Я
   Web00001
 
16.03.19 - 06:43
Доброго времени суток! Имеется с десяток идентичных баз. Сейчас рассматривается вариант покупки сервера и серверных лицензий. Было бы неплохо что-то сделать с этими базами. Чтобы бекапить, обновлять и обслужить одну базу а не десяток. Вариантов как я понимаю два: делать указывать разделители данных (тогда надо будет что-то думать с переносом данных в текущую из остальных отдельных баз) или fresh но его как я понял надо докупать отдельно и для 10 баз это как из пушки по воробьям - возни много профита не так много. Поделитесь опытом кто уже настраивал подобное?
 
 
   ДенисЧ
 
1 - 16.03.19 - 06:58
   Web00001
 
2 - 16.03.19 - 07:22
Ну ты как обычно, ни буквы по существу вопроса. Стабильность признак мастерства )
   ansh15
 
3 - 16.03.19 - 08:12
>>Чтобы бекапить, обновлять и обслужить одну базу а не десяток
И в случае получения ошибки СУБД "файл базы данных поврежден", потерять сразу все десять баз, а не одну.
Бэкапить и обслуживать будут скрипты в планировщике.
   Провинциальный 1сник
 
4 - 16.03.19 - 08:16
Дешевле выйдет не покупать mssql, а обойтись бесплатным sql express, и вот здесь отдельные базы только в плюс - 10 гиг на базу надолго хватит при небольшом потоке документов.
   Aleksey
 
5 - 16.03.19 - 08:43
(2) Потому что ты не озвучил не одной проблемы, только решение, и накидать другие.

бекап, обновление, обслуживание это всего лишь галочка напротив нужной базы в твоем скрипте. Один раз поставил  забыл. Вообще проблем нет никакой. Тем более каких то 10 баз. Ты же пытаешься решить объединением непонятно что. Получив гемор с обновлениями, с разделениями данных, с бекапами и т.д.
   Aleksey
 
6 - 16.03.19 - 08:44
еще и фрешь приплел, вообще непонятно для чего
   Web00001
 
7 - 16.03.19 - 09:04
>>Потому что ты не озвучил не одной проблемы, только решение, и накидать другие.
Я хотел бы послушать опыт других людей в этом вопросе, вроде бы для этого и сделан форум?

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

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

(8)>> еще и фрешь приплел, вообще непонятно для чего
Для реализации одной базы на сервере, что тебе непонятно в данном случае?
   Aleksey
 
8 - 16.03.19 - 10:29
(7) Опыт чего ты хочешь послушать? у меня был опыт и 20 баз бухии и все в одной, в том числе и зуп. Скажем так вот бекапы и обслуживание меньше всего парят. 1 строку в скрипте один раз добавил и пусть себе бекапится. Т.е. вопрос удобство бекапа  десятый пункт в этом вопросе. К тому же что за условия у тебя такие что каждый день новую базу добавляешь и забываешь её бекапить

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

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

Я уже упоминал что нет универсального ответа на твой вопрос? И уж точно вопрос бекапа это не та проблема из за которой стоит сливать 10 баз в одну
   Aleksey
 
10 - 16.03.19 - 10:46
Одно из любимых занятий бухов - наводить порядок путем переименования справочника. Типа о вот элемент который лично я не использую, а давай я его возъму и переименую как мне надо, чтобы не захламлять базу. И в результате вчера была ОС "компьютер" сегодня это уже "здание". Особенно было прикольно со справочником РБП, где задаются срок списания стоимость. И потом начинается, а почему у меня в прошлом месяце списывался по 100 рублей, а в этом по 250 - программа считает неправильно. И ты такой поднимешь бекап и начинаешь играть в интересную игру - найти 10 отличий.
   МимохожийОднако
 
11 - 16.03.19 - 10:54
(7) Купи Обновлятор ))
   palsergeich
 
12 - 16.03.19 - 11:14
(10) ДАДАДАДАДАДАДАДА!!!
(0) Обновлять базы можно автоматизированно.
   Web00001
 
13 - 16.03.19 - 11:40
Я понял, срач конечно веселее, чем обмен опытом :) давай сначала, я не спрашиваю, зачем оно нужно, плюсы и минусы оно очень хорошо, но если отбросить всю лирику. А тупо оставить факты. У тебя очень много эмоций которые не к месту. Но ты продолжай, я не понял почему ты возбудился, но я с удовольствием послушаю. Давай уже отвечу, не зря же ты старался

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

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

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

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

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

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

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

(12)Тут немного кастомизированные базы. И после пары последних обновлений пришлось немного приседать не в плане переноса изменений, а в плане, работы с данными. Пугает, что забудешь, что-нибудь сделать в одной из баз и вспомнишь через полгода когда уже бекапами и не пахнет. Мы искренне надемся, что государаство не подкинет каких нибудь шуток с ккм и мы еще поживем хотя бы полгода. Но уверенности нет.
   Web00001
 
14 - 16.03.19 - 11:51
Если сухо Aleksey говорит, что не стоит этого делать по следующим причинам:
1. При блокировании таблиц по одной базе1С блокируются таблицы по всей базе SQL
2. >> когда в одной базе удалили данные, и удаление промигрировало в другую базу
Там разные данные. Как удаление одного элемента может повлиять на совершенно другой мне непонятно. Каким боком здесь вообще РИБ  и синхронизации? Игнорируем.
3. Добавим сюда постоянные косяки с РЛС
Причем здесь РЛС неизвестно. Если мы говорим про разделитель, то база получает отфильтрованные данные до того как можно применить какой либо РЛС. Игнорируем.
4. Проблема в том, что если базы были объеденены, то разъеденить их целая история(как и объеденить собственно). Если данные смогли приехать в такую базу, то смогут и уехать. Косяк в том, что это долго, дорого и сложно. Аргумент.
То есть по факту осталось 1 и 4.
1 не сильно беспокоит, маленькая нагрузка. 4 уже сложнее, но база управленческая, не так критично, но заслуживает внимания.
   palsergeich
 
15 - 16.03.19 - 11:55
(13) Фреш он не про сотни баз в одной, он про единицы баз в одной.
И про специальный механизм который скрывает реализацию.
И про огромное количество технологических проблем, которые до сих пор не решены, есть только обходные пути решения.
   МимохожийОднако
 
16 - 16.03.19 - 11:56
(13) ИМХО. Ты и сам эмоционален. Твой аргумент в пользу объединения-возможность забыть что-то сделать в другой базе с аналогичной конфигурацией. Для этого есть скрипты и напоминалка.
Минусов в объединении больше, чем плюсов. Особенно это касается баз от разных владельцев бизнеса. Объединение допустимо только для одного владельца бизнесом. У разных владельцев должны быть разные базы. Проблема сопровождения баз не должно быть проблемой тех, чьи это базы. Научись автоматизировать администрирование базы и забудешь про свой сабж.
   palsergeich
 
17 - 16.03.19 - 11:59
Если говорить про ДИИТ, на 15000 на фреше, то там более 100 нод, на каждой ноде N ое количество баз по технологии фреш. И в каждой такой базе совсем небольшое количество баз с разделителями, даже до 10 иногда не доходит.
Фреш он про то что начались проблемы с конкретной базой -> вырезаем область данных скриптом и переносим на более свободную ноду и меняем данные в управляющей конфигурации.
А так же огромный штат тех кто за этим следит.
   palsergeich
 
18 - 16.03.19 - 11:59
(17) 15000 пользователей имелось ввиду
   palsergeich
 
19 - 16.03.19 - 12:03
Явно этого не говорится, но на обучении вскользь проскакивает, что фреш не самая удачная реализация и требует высокой квалификации. Если требуется стабильность - делайте по старинке каждая база по отдельности и автоматизируйте свою работу самостоятельно.
   Web00001
 
20 - 16.03.19 - 12:08
(16)>> Особенно это касается баз от разных владельцев бизнеса. Объединение допустимо только для одного владельца бизнесом. У разных владельцев должны быть разные базы
Владелец один. И базы все его, это розничные точки. Периодически добавляются, медленно(раз в год, полгода), может вообще перестанут, но тенденция пока в наличии. Он хочет на каждый магазин отдельную базу. То есть так было изначально и уже сложновато, что-то менять.
>>Проблема сопровождения баз не должно быть проблемой тех, чьи это базы.
Разумеется. Просто переезд на новую платформу и может быть можно было бы как-то сделать более оптимально. Вот и спрашиваю собственно.

(15)(17)(19)Все понятно, слишком много приседаний.
   1snik_d
 
21 - 16.03.19 - 12:37
(20) Очень вовремя тема появилась. Тоже терзался в сомненьях, теперь не буду слеплять базы, лучше по старинке.
   Aleksey
 
22 - 16.03.19 - 13:42
(13) О чем писать? Я могу долго писать о проблемах в ЗУП, а потом выясниться что ты спрашиваешь про розницу
   Cyberhawk
 
23 - 16.03.19 - 13:44
Во Фреше самый косяк для требовательных к производительности баз - это низкоселективные индексы из-за разделителя на первой позиции в ключе.
Хотя помнится давеча скуль предлагал и в неразделенной базе ЕРП создавать индекс, подвинув разделитель с первого места. Т.е. он где-то и без фреша тоже гадит.
   palsergeich
 
24 - 16.03.19 - 13:49
(23) И не только, на том же обучении говорили что много технологических проблем до сих пор, которые без участия вендора решены быть не могут.
Один из примеров - при модифицированной и прошедшей аудит обработке загрузки банковских платежей гадилось в другие области.
   Aleksey
 
25 - 16.03.19 - 13:50
(13) Про опыт. Я с БП с 2006 года, это как раз когда они с 1.0 на 1.5 переходили. У меня порядка 25 фирма, постоянно кто-то закрываются, кто то открывается. При этом порядка 10 главбухов и у каждого свой, не пересекающися набор фирм. Собственно проблемы в 1.5/2.0/3.0 они все разные. где то 1С решила что раньше не работало, где то добавило новые проблемы. Как можно описать нюансы, если неизвестно о чем речь? Об УТ10? О Рознице 2.0 или проблема обменов нескольких баз ЗУП с одной БП. Ты хотя бы кейс обозначь, а пока его нет, сложно с тобой говорить

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

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

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

3 Ты хотя бы почитай что такое разделитель и для чего он нужен, сдается мне что у тебя понимания механизма далеко от действительности
   Фрэнки
 
27 - 16.03.19 - 14:03
Не сказано во всем обсуждении самого существенного:

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

Периодически с этими юрлицами происходят разные приключения, асинхронные относительно друг-друга. И это влечет за собой клич к выносу базы на отдельный носитель или комп, чтоб позволить в нее заглянуть аудитору или инспектору без раскрытия инфы о том, что рядом имеется точно такие накрученные обороты и остатки.
Так вот, имхо, проще регулярно обслуживать отдельные разные информационные базы, пусть даже в одном скл-сервере, чем внезапно, срочно и обморочно выносить отдельную организацию в отдельную базу изнутри одной большой с большим количеством организаций
   Фрэнки
 
28 - 16.03.19 - 14:04
И второй момент с отдельными розницами - это отдельные потребности обеспечения розничных точек своими независимыми от других точек кассовыми местами.
   bolder
 
29 - 16.03.19 - 14:06
(9) (10) Полностью согласен.
(14) Тебе рано сливать базы, про РЛС надо почитать сначала.Все аргументы тебе правильно Aleksey изложил.
   Фрэнки
 
30 - 16.03.19 - 14:06
(25)// другой бух имеет доступ к его базе, ор выше гор типа, а  вдруг она что то поменяет, а мне потом отвечать 


даже внутри одной фирмочки орут, что когда одна работает в ЗУП, а другая в бухии и не дай бог кто-то там что-то друг другу поменяет.
 
 
   palsergeich
 
31 - 16.03.19 - 14:08
Ну а по поводу обновления:
1)) Обновлятор
2) 1sscript 
это готовые решения
Скрипты командной строки так же работают прекрасно, я работал в федеральной рознице, где было 4К файловых баз с полностью автоматическим централизованным обновлением из поставки.
   palsergeich
 
32 - 16.03.19 - 14:09
там это было реализовано очень простыми PS скиптами
   Фрэнки
 
33 - 16.03.19 - 14:10
Если же опять будет заявлено "а у меня базы управленческие и все проблемы мне похер..." - искренне буду удивлен, т.к. зачем тогда вообще с этой проблемой "соединять или нет" пришли на форум?
   palsergeich
 
34 - 16.03.19 - 14:10
И да, в период запусков чего то большое при наличии ракокода обновлений могло быть несколько в день)
   bolder
 
35 - 16.03.19 - 14:19
(32) Интересно было бы про это прочитать.
   vde69
 
36 - 16.03.19 - 17:43
1. в SQL в скриптах есть галочка "применять для всех пользовательских базах" - поставил и забудь про то, что кто-то добавит или переименует в скуле что-то (разумеется при этом на серваке не должно быть хлама в виде копий и баз разработкит... для этого нужен отдельный SQL)
2. можно все базы слить в одну и разрулить все RLS, в твоем случае с магазинами это идеальный вариант
   ptiz
 
37 - 16.03.19 - 18:25
(0) Результат объединения в одной базе будет один - прокачанный скилл решения кучи проблем, которых бы не было без этого объединения.
   Фрэнки
 
38 - 16.03.19 - 18:29
но на самой деле автор топика не дал еще одного уточнения:
- автор хочет просто залить множество файловых баз в один СУБД сервер, но их у него останется множество информационных баз ИЛИ
ему хочет поупражняться в заливке всего множества баз в одну ИБ ?
   bolder
 
39 - 16.03.19 - 18:34
(38) Вроде второе из (0) следует.
   Cyberhawk
 
40 - 16.03.19 - 18:56
(27) "проще регулярно обслуживать отдельные разные информационные базы, пусть даже в одном скл-сервере" // Да, даже во Фреше есть возможность под каждую конфигурацию ("приложение") и/или абонента делать физически отдельную инфобазу (БД). И это очень актуально для некоторых клиентов Фреша, но конечно же таких далеко не большинство.
   Фрэнки
 
41 - 16.03.19 - 19:07
(39) ну не знаю - для меня это второе в топике не очевидно
   pavig
 
42 - 16.03.19 - 21:25
(4) Почему sql express, а не постгри?
   pavig
 
43 - 16.03.19 - 21:30
(15) "И про огромное количество технологических проблем, которые до сих пор не решены, есть только обходные пути решения."
Можно подробнее?
Какие там технологические не решенные проблемы?
   dmpl
 
44 - 17.03.19 - 11:49
(0) Приходит налоговая и говорит: дайте нам вашу базу ООО "Рога и копыта - 2". Руководство не против. Твои действия?
   dmpl
 
45 - 17.03.19 - 11:50
(7) Правильный скрипт бэкапит все базы на рабочем сервере.
   Злопчинский
 
46 - 17.03.19 - 12:04
Вот открыл базу свою во фреше сейчас. Жмакнул справочник.контрагенты - уже секунд 40 думает. у меня там записей штук 20 всего...
   Злопчинский
 
47 - 17.03.19 - 12:10
..так и не открылась. киллнул 8-ку в диспетчере задач.
запускаю повторно.
так она - даже имя-пароль не спросило - запустилось сразу.
вот такая охеренная безопасность.
может я кнечно туплю и не просекаю грандиозности замысла...
   Злопчинский
 
48 - 17.03.19 - 12:18
после киляния - открылось нормально... шаман однако
   Cyberhawk
 
49 - 17.03.19 - 13:41
(47) "она - даже имя-пароль не спросило - запустилось сразу" // Так это ОпенИД-аутентификация. Пока не разлогинился или не прошел заданный таймаут, повторно аутентифицироваться не нужно
   ДенисЧ
 
50 - 17.03.19 - 13:43
(44) НАзачем налоговой твоя база?
   Alexor
 
51 - 17.03.19 - 14:56
(7)
1. в скуле прописываешь регламент для пользовательских баз. При добавлении базы автоматом ее цепляет.

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

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

Но я за раздельные.
   Провинциальный 1сник
 
52 - 17.03.19 - 15:09
(42) Можно и постгрес, но мс удобнее и предсказуемее как в плане глюков, так и в плане тормозов
   Фрэнки
 
53 - 17.03.19 - 15:56
(52) главное, бабло не забыть выплатить за лиценизрование, а так-то удобней и тормозит также :-)
   dmpl
 
54 - 18.03.19 - 10:21
(50) Решение этого вопроса не входит в компетенцию 1Сника. Ему сказали - он должен взять под козырек, и не засветить лишнего.
   Сияющий в темноте
 
55 - 18.03.19 - 13:25
Если точки одинаковым торгуют,то проще слить в одну базу,чтобы номенклатура общая была и закупки прозрачные.
А если в каждой свои справочники,то пусть живут отдельно.
Для торговли,если на кассах фронтол или другое подобное решение,совсем не важно,где база и в каком она виде,т.к.в нее вводится приход,но если у вас холдинг,то приход выгружается из другой базы.Действий с базой минимум,поэтому,как ни сделаю,будет работать,главное,чтобы всякие маркировки и егаисы с базой обменивались без проблем.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.