По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Дома у меня как для себя ИПшника стоит на одного пользователя как раз SQL ;)
Все работает, но планируем с моим приходом перенастройку сервера, вот и задумался о переходе на SQL.
Обеспечение безопасности тут никакое, но вроде и не нужно.
Вот и мучаюсь или сделать сразу как правильно или не трогать никогда.
Пока не вижу для себя убедительных оснований ни для одного из вариантов.
Вот и спрашиваю у более опытных.
Все работает, но планируем с моим приходом перенастройку сервера, вот и задумался о переходе на SQL.
Обеспечение безопасности тут никакое, но вроде и не нужно.
Вот и мучаюсь или сделать сразу как правильно или не трогать никогда.
Пока не вижу для себя убедительных оснований ни для одного из вариантов.
Вот и спрашиваю у более опытных.
Если регулярность резервного сохранения данных такова, что время на восстановление этих данных в случаях аварий устраивает пользователей, зачем лишние затраты? ИТ структура должна обеспечить: 1- производительность, 2- надежность. Сами определяйтесь.
На данный момент, прошлым сисадмином архивация была сделана раз в сутки батником в автозапуске копирование раром в папку на том же диске.
А какие тут затраты? Только мое время на перенастройку ПО. А вот со смыслом делать или нет, определиться не могу сам, потому и спрашиваю.
А какие тут затраты? Только мое время на перенастройку ПО. А вот со смыслом делать или нет, определиться не могу сам, потому и спрашиваю.
(9) Шутка. Видимо, не слишком удачная.
При переходе на SQL нередко отмечают замедление операций записи (в SQL на это больше накладных расходов). Но тут уже от сервака зависит.
В принципе, само проведение может ускориться, если узким местом были запросы в проведении (как правило, на запросах, особенно сложных, SQL дает прирост производительности). Но помню случаи, когда люди получали замедление чуть ли не в разы на перепроведении больших периодов при переходе на SQL.
(10) Чисто на всякий случай. А то есть подозрение, что ты не одинэсник и можешь быть не в курсе. В 1С "переход на SQL", это не просто смена хранилища для базы. Это еще и переход на трехзвенку. Нужно покупать доп. ПО, т.н. "сервер приложений 1С" на который требуется отдельная недешевая лицензия. Именно он будет взаимодействовать с SQL. А все пользователи будут взаимодействовать с сервером приложений.
При переходе на SQL нередко отмечают замедление операций записи (в SQL на это больше накладных расходов). Но тут уже от сервака зависит.
В принципе, само проведение может ускориться, если узким местом были запросы в проведении (как правило, на запросах, особенно сложных, SQL дает прирост производительности). Но помню случаи, когда люди получали замедление чуть ли не в разы на перепроведении больших периодов при переходе на SQL.
(10) Чисто на всякий случай. А то есть подозрение, что ты не одинэсник и можешь быть не в курсе. В 1С "переход на SQL", это не просто смена хранилища для базы. Это еще и переход на трехзвенку. Нужно покупать доп. ПО, т.н. "сервер приложений 1С" на который требуется отдельная недешевая лицензия. Именно он будет взаимодействовать с SQL. А все пользователи будут взаимодействовать с сервером приложений.
что вы, прям, как дети?
1. значит базы маленькие - того и 10-ть на файловой не тупят
2. база имеет свойство расти и 2ГБ - не за горами
3. сравнивать "тупизну" базы ДБВ и Сиквелл имеет смысл на базе в 2Гб и 3 пользователях, а если, "около 10" однозначно Сиквелл
1. значит базы маленькие - того и 10-ть на файловой не тупят
2. база имеет свойство расти и 2ГБ - не за горами
3. сравнивать "тупизну" базы ДБВ и Сиквелл имеет смысл на базе в 2Гб и 3 пользователях, а если, "около 10" однозначно Сиквелл
(17) просмотривал записи в поисках размеров базы. Нашел.
"Каждая база 3-12 ГБ. Баз 8 штук.
Переходили на ЗуП 3.1 в марте, так из 2.5 вытащили только остатки. Теперь отчетность собирают из двух баз. "
.
Однозначно запланировать и выполнить переход на SQL.
Файловая база > 2 Гиг при активной работе - получить "нарушение целостности структуры данных". Иногда в файловой это лечится с частичной потерей данных, а иногда нет.
Не нужно ждать пока грянет гром с такими базами.
"Каждая база 3-12 ГБ. Баз 8 штук.
Переходили на ЗуП 3.1 в марте, так из 2.5 вытащили только остатки. Теперь отчетность собирают из двух баз. "
.
Однозначно запланировать и выполнить переход на SQL.
Файловая база > 2 Гиг при активной работе - получить "нарушение целостности структуры данных". Иногда в файловой это лечится с частичной потерей данных, а иногда нет.
Не нужно ждать пока грянет гром с такими базами.
(17)
Переход ЗУП 2.5 - 3.х и так только с остатками и при этом их нужно все внимательно руками перепроверить. При переносе Документов ошибок в разы больше.
Поэтому переходить рекомендуется в начале года.
Не все так гладко как декларируется.
Каждая база 3-12 ГБ. Баз 8 штук.
Переходили на ЗуП 3.1 в марте, так из 2.5 вытащили только остатки. Теперь отчетность собирают из двух баз.
Переходили на ЗуП 3.1 в марте, так из 2.5 вытащили только остатки. Теперь отчетность собирают из двух баз.
Переход ЗУП 2.5 - 3.х и так только с остатками и при этом их нужно все внимательно руками перепроверить. При переносе Документов ошибок в разы больше.
Поэтому переходить рекомендуется в начале года.
Не все так гладко как декларируется.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот