Здравствуйте!
Розница 2.2.5.26
Рассматриваем переход с файлового варианта работы на клиент-серверный.
Размер базы 12 ГБ.
Одновременное количество работающих пользователей 10.
Как думаете, подойдёт ли на нам решение PostgeSQL?
Какая версия платформы 1С показала себя стабильно в работе?
Очень рад буду, если опишите личный опыт работы с данным ПО. Заранее спасибо!
Розница 2.2.5.26
Рассматриваем переход с файлового варианта работы на клиент-серверный.
Размер базы 12 ГБ.
Одновременное количество работающих пользователей 10.
Как думаете, подойдёт ли на нам решение PostgeSQL?
Какая версия платформы 1С показала себя стабильно в работе?
Очень рад буду, если опишите личный опыт работы с данным ПО. Заранее спасибо!
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Если все пользователи кассиры, то подойдёт или нет однозначно тяжело сказать.
Автоматические блокировки у этой СУБД такие же как и у файловой. Блокирует только таблицы целиком.
Если сервер не очень быстрый и чеки будут проводиться какое-то ощутимое количество времени, то будут конфликты блокировок.
Автоматические блокировки у этой СУБД такие же как и у файловой. Блокирует только таблицы целиком.
Если сервер не очень быстрый и чеки будут проводиться какое-то ощутимое количество времени, то будут конфликты блокировок.
(23)Видит у вас покупатель ручку на витрине и просит продать ему таких 135 шт. Пойдёте на склад пересчитывать?
Я же вроде написал кому то нужно видеть остатки, кому то нет. На основной работе у меня например остатки не ведутся в магазине.
А вот на другой обязательно знать что есть, а чего нет на остатке в момент продажи.
Я же вроде написал кому то нужно видеть остатки, кому то нет. На основной работе у меня например остатки не ведутся в магазине.
А вот на другой обязательно знать что есть, а чего нет на остатке в момент продажи.
(44)Я вроде и не передёргивал. А сразу написал что в разных магазинах(организациях) работа устроена по разному. Где то хотят видеть остатки, где то нет. Кому то принципиально что бы не видели. Кому то надо на оборот что бы видели.
По этому и говорить что на кассе не должно быть остатков это прям для всех правильно как то не очень наверное правильно.
Но вы конечно знаете лучше всех и решили всех научить как надо делать правильно.
По этому и говорить что на кассе не должно быть остатков это прям для всех правильно как то не очень наверное правильно.
Но вы конечно знаете лучше всех и решили всех научить как надо делать правильно.
(49)Зависит от задачи, а не от вашего понимания что есть правильно, а что нет.
Вы же не будете доказывать директору магазина автозапчастей что не правильно что были остатки на кассе. Если он говорит что его сотрудник в момент продажи должен видеть какой остаток товара у него есть.
Вы же не будете доказывать директору магазина автозапчастей что не правильно что были остатки на кассе. Если он говорит что его сотрудник в момент продажи должен видеть какой остаток товара у него есть.
Забыл добавить что в этой базе основные пользователи в основном АУП, в розничных магазинах стоят файловые узлы (у нас РИБ).
Как раз таки центральную базу переводим на серверный режим.
Вообще какие то ограничения на Postgre были замечены? (например по сравнению с MS SQL)
Как раз таки центральную базу переводим на серверный режим.
Вообще какие то ограничения на Postgre были замечены? (например по сравнению с MS SQL)
Извините, что не по теме. Никак не могу узнать, какие ограничения стоят на версию PostgreSQL pro Standard? Интересует ограничение в размерах БД, таблиц, в количестве БД, таблиц, в количестве одновременно работающих пользователей и т.д.
(18)
У меня были базы в 30Гб и работали в файловом варианте.
Тут дело в таблицах. Если размер одной таблицы в базе превысит пороговое значение то файловая перестанет работать.
Есть ресурсы, которые говорят что файловая от 4-12 ГБ остаётся работоспособной.
У меня были базы в 30Гб и работали в файловом варианте.
Тут дело в таблицах. Если размер одной таблицы в базе превысит пороговое значение то файловая перестанет работать.
(19) Смотрел структуру Иб с помощью утилиты V8TableSizes.exe ( и там у нас таблица с чеками более 4 ГБ,
Регистр накопления "Товары на складах" 3,5 Гб.
Не знаете когда настанет этот порог?
Вообще знакомый ездил в Центр Обучения 1С г. Москва и там почему то категорично отговаривали от Постгрэ, агрументируя вроде как ненадёжностью.
Регистр накопления "Товары на складах" 3,5 Гб.
Не знаете когда настанет этот порог?
Вообще знакомый ездил в Центр Обучения 1С г. Москва и там почему то категорично отговаривали от Постгрэ, агрументируя вроде как ненадёжностью.
(25) Не знаю (не помню) как эта утилита показывает размер, но кажись предел у файловой 4Гб на ВНУТРЕННЮЮ таблицу (или как там ее). Обычные данные, индексы и блобы хранятся в разных внутренних таблицах. То есть скорее всего у вас еще приличный запас есть. Но лучше всего как-то проверить соотношение данных и индексов в таблицах, которые у вас подбираются к пределу. Если нельзя этого сделать напрямую на файловой, то можно тестово ее загрузить в тот же MSSQL.
(31) Речь про работу через сетевую шару, скорее всего. Тут особых пруфов и не надо. Уронить восьмерочную базу при сетевых сбоях намного проще, чем семерочную (за счет того, что один мегафайл со сложной структурой). И вероятность растет пропорционально количеству пользователей.
Поэтому и стараются с файловыми работать локально (через терминал или веб-сервер).
Поэтому и стараются с файловыми работать локально (через терминал или веб-сервер).
(25) С надежностью там все хорошо. Если не отключать f_sync или как там его. Пусть не заливают.
Основные минуса постгреса такие же как у всего опенсорса - нужно вникать, настраивать и с разношерстным тулингом тоже самое (хотя, для любого линуксоида это обычное дело). В то время, как в MSSQL все из коробки. Еще спасибо, что документация хорошая, что нетипично для опенсорса :)
И учтите, что при переходе на СУБД скорее всего получите просадку на производительности тех же транзакций записи, например.
Поэтому пилотный запуск обязательно, чтобы понять на каком свете вы очутитесь. MSSQL все-таки попроизводительнее будет, особенно если на том же сервере через shared memory работать будет. Тут разница может быть довольно заметная, если сравнивать с виндовым postgres (который пилят по остаточному принципу). Вот если сравнивать отдельно стоящие СУБД, где postgres под линуксом - то там худо-бедно настроенный постгри (без явных узких мест) вполне себе сопоставим с MSSQL по производительности. То есть хуже, но ненамного.
Основные минуса постгреса такие же как у всего опенсорса - нужно вникать, настраивать и с разношерстным тулингом тоже самое (хотя, для любого линуксоида это обычное дело). В то время, как в MSSQL все из коробки. Еще спасибо, что документация хорошая, что нетипично для опенсорса :)
И учтите, что при переходе на СУБД скорее всего получите просадку на производительности тех же транзакций записи, например.
Поэтому пилотный запуск обязательно, чтобы понять на каком свете вы очутитесь. MSSQL все-таки попроизводительнее будет, особенно если на том же сервере через shared memory работать будет. Тут разница может быть довольно заметная, если сравнивать с виндовым postgres (который пилят по остаточному принципу). Вот если сравнивать отдельно стоящие СУБД, где postgres под линуксом - то там худо-бедно настроенный постгри (без явных узких мест) вполне себе сопоставим с MSSQL по производительности. То есть хуже, но ненамного.
(56)
А я где то с этим спорил?
А если он спрашивает сколько там зелёной кафельной плитки на остатке? Или пусть на кассу тащит со склада или сам считает?
"бест-практис на фронте ничего не считать, особенно остатки. ибо раз уж человек на кассе стоит с товаром, то этот товар есть и его нужно продать."
А я где то с этим спорил?
А если он спрашивает сколько там зелёной кафельной плитки на остатке? Или пусть на кассу тащит со склада или сам считает?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот