Посоветуйте программу Учета на предприятие

[allex]

А вообще, в 1С меня больше всего прикололо вот что - объем базы у нас порядка 1 гига (это только бухгателтерия, как уже говорил ранее), и с 5 (пяти!) рабочих мест работать было невозможно, так как постоянно возникали встречные блокировки

Тут не SQL, тут терминальный сервер нужен.

[KostyaY]

тут терминальный сервер нужен

Не нужен. Тут другой продукт нужен. Написанный руками тех, кто умеет нормальные многопользовательские приложения писать.
Объясню почему - при открытии какой-либо таблицы файл-серверной БД, 1С блокирует её целиком. Не исправляемую запись, не некий кусок файла, в котором эта запись находится ("страница"), а всю таблицу. К чему это приводит - открывает сотрудник, имеющий права на запись, какую-либо форму, которая позволяет что-либо менять (даже если он менять не собирается, а только смотреть хочет), после этого никто больше не может ее открыть, пока он ее не закроет. Имхо, таким образом с разделяемыми ресурсами работать, коими в данном случае является такая таблица - это есть дурной тон. Либо же сознательное решение производителя вынудить неоправданно приобретать этот самый сервер приложений, стоящий, кстати, не по детски. Кстати, забавно, что 64-битная версия сервера стоит в 2 раза дороже 32-х битной.
А клиент-серверная архитектура у них трехуровневая. Клиент не работает непосредственно с sql, он работает с неким "сервером приложений", на который, собственно, и возложено разруливание конфликтов. Посему, в такой ситуации подобных блокировок уже не возникает, что дает, все таки, возможность открывать нескольким людям одну и ту же форму.
На эту тему есть статья в "базе знаний 1С".
Речь идет о версии 8.
И причем тут терминал-сервер? От него работа движка БД 1С не зависит никак. Собственно, мы на нем и работаем...

Сорри за офф. Есть предложение, либо вести обсуждение архитектур и проблем систем в личке, либо открыть отдельную тему.

[Страусь]

allex писал(а):тут терминальный сервер нужен
Не нужен. Тут другой продукт нужен. Написанный руками тех, кто умеет нормальные многопользовательские приложения писать.

От чего же.
Тут надо просто аккуратно подходить к продукту. Могу привести пример. Одна крупная сотовая контора, макрорегион Урал, 300 пользователей, v8 SQL версия.
На такие объемы (выше 1 гига) и если она будет расти, лучше ставить SQL.

Объясню почему - при открытии какой-либо таблицы файл-серверной БД, 1С блокирует её целиком. Не исправляемую запись, не некий кусок файла, в котором эта запись находится ("страница"), а всю таблицу. К чему это приводит - открывает сотрудник, имеющий права на запись, какую-либо форму, которая позволяет что-либо менять (даже если он менять не собирается, а только смотреть хочет), после этого никто больше не может ее открыть, пока он ее не закроет. Имхо, таким образом с разделяемыми ресурсами работать, коими в данном случае является такая таблица - это есть дурной тон. Либо же сознательное решение производителя вынудить неоправданно приобретать этот самый сервер приложений, стоящий, кстати, не по детски. Кстати, забавно, что 64-битная версия сервера стоит в 2 раза дороже 32-х битной.
А клиент-серверная архитектура у них трехуровневая. Клиент не работает непосредственно с sql, он работает с неким "сервером приложений", на который, собственно, и возложено разруливание конфликтов. Посему, в такой ситуации подобных блокировок уже не возникает, что дает, все таки, возможность открывать нескольким людям одну и ту же форму.

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

[KostyaY]

Никогда не обращал внимание, как два бухгалтера никому не мешая одновременно открывают расходные накладные, формируют их, и проводят?

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

По сравнению с остальным, цена за сервер Предприятия в 36 тыщ рублей не является не детской ценой

За 64 бита - 72 тыщи, кстати. Учитывая то, что речь идет только о бухгалтерии с 5 пользователями на тот момент, увеличение стоимости 1 лицензии на 7 с лихвой тыр (для 32 бит, для 64 - в два раза больше) - это очень много.

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

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

На такие объемы (выше 1 гига) и если она будет расти, лучше ставить SQL.

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

макрорегион Урал, 300 пользователей, v8 SQL версия

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

[ShineOn]

при открытии какой-либо таблицы файл-серверной БД, 1С блокирует её целиком

SQL-версия и файл-серверная версия - две разные вещи! В файл-серверной версии файл БД при открытии его одним пользователем блокируется на уровне файловой системы ОС, а не на уровне "сервера приложений" (которого в этой системе вообще нет, как такового). В SQL-версии файл БД открывается не отдельным пользователем, а СУБД. Любые изменения в БД выполняются именно SQL-сервером, а не пользователем, пользователь всего лишь передаёт команды в СУБД (посредством интерфейса 1С). А уже задача самой СУБД отслеживать очередь запросов и возможные конфликты.

На такие объемы (выше 1 гига) и если она будет расти, лучше ставить SQL.

Я бы даже сказал не "лучше", а "необходимо".

[KostyaY]

В файл-серверной версии файл БД при открытии его одним пользователем блокируется на уровне файловой системы ОС

Нет, Игорь, не так совершенно! Если бы было так, то файл-серверных баз не существовало бы вообще. Операционная система не будет блокировать файл, если это прямо не запрошено приложением при обращении к соответствующей функции API операционки. В терминах 1С это открытие бд в "однопользовательском" режиме (или что-то вроде того).
Работает это примерно так - возьмем БД Access. Создается файлик с тем же именем, что и база, но с расширением ldb. Собственно, это и есть журнал блокировок, в который и пишется, что и как в данный момент заблокировано.
Блокировки могут быть разные. Например, их отсутствие как таковое. Или блокировка только одной записи на время ее модификации. Или блокировка т.н. "страницы" кратной 4 или 16 кбайт, в которой находится модифицируемая запись. Или блокировка всей таблицы. Применяемый способ определяет частоту возникновения конфликтов и сложность их разрешения. Самое простое - запретить все нахрен на уровне файла. При блокировании таблицы - сложнее. Записи - еще сложнее.

Я бы даже сказал не "лучше", а "необходимо"

Ребят, вы чего? 1 гиг много?! Это небольшой объем! Не терабайт, а гигабайт! В процессе борьбы с внедренцами мы, ради демонстрации этого, плодили тестовые базы от 1 до 3 гиг на акссесе и на навижн, сажали на них по десятку автоматических клиентов, которые тупо делали какие-либо операции записи в одни и те же большие таблицы. И все бежало на ура, и постоянных жестких блокировок не вызывало. Я крайне не люблю по многим причинам файл-серверный доступ к БД, но в данном случае это должно быть вполне приемлемым вариантом.

[ShineOn]

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

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

[KostyaY]

Блокировка отдельных записей внутри файла возможна только в случае наличия некоторой "прокладки" между клиентом и файлом БД

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

Если есть необходимость, готов объяснить более подробно позже, сейчас времени мало.

[Demid]

Народ платформа 8.2 вышел, там много чего изменилось, неужто по прежнему всё так плохо (это о высказывании, что только клиент работает с БД). На мой взгляд 1С перестраивается, и что называется : "правильным путем пошли товарищи". У них ведь появились всякие там тонкие, толстые и даже веб клиенты, которые в принципе с БД работать напрямую не умеют (если только 1С не изобрела какую-то новую нанотехнологию работу через веб с БД ).
По поводу файлового режима хранения БД согласен, по-прежнему тупит, но бороться можно.
Кстати, а 1С-скую Postgre SQL ни кто не юзал?

[Страусь]

Страусь писал(а):На такие объемы (выше 1 гига) и если она будет расти, лучше ставить SQL.
1 гиг - это небольшой объем. 5 пользователей - это смешное кол-во. Про продукт, который, фактически, не может работать с таким объемом и количеством пользователей в файл-серверном режиме, я не могу сказать, что он написан качественно.

Два примера.
40 пользователей (не бухгалтеров, менеджеров по продажам). Версия 7.7, файловая версия. Объем базы 7гигов. Каждые десять минут еще и распределенка. И ничего - работают, живут.

Страусь писал(а):макрорегион Урал, 300 пользователей, v8 SQL версия
Наверное, возможно. Но возникают вопросы - сколько пользователей работают одновременно и что именно они делают в системе? Часом, это не центр+филиальная сеть, где каждый филиал работает со своей базой, раз в сутки сливая наработанное за это время?

Это параметры работы одной базы данных. Само собой, это распределенка и все уходит в центр. Мы обслуживали свой макрорегион. В нашей базе было от 200 до 250 пользователей одновременно.

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

[KostyaY]

40 пользователей (не бухгалтеров, менеджеров по продажам). Версия 7.7, файловая версия. Объем базы 7гигов

Да, так и должно быть, хотя, скорее всего, переход на sql при таком объеме будет уже точно оправдан. Хотя, если людей устраивает производительность, то почему бы и не оставить...

Леша, я это не придумал. Все мои выводы были сделаны по результатам работы с партнером 1С, который висит у них на сайте в первой десятке, имеет сертификацию по исо 9001 и т.п. Все вопросы многократно обсуждались с ними, и озвученные мной проблемы были во многом ими же подтверждены.

Я не сомневаюсь, что можно внедрить 1с на большом предприятии с сотнями рабочих мест. Сделать можно всё. Но, сдается мне, это штучные примеры, требующие значительных трудозатрат и доработок. Кроме того, неясно, какая нагрузка на этом множестве клиентов...

Думаю, что у этого продукта (впрочем, равно как и любого другого...) имеется немало слабых мест. И любой разработчик, полагаю, знает об этом куда лучше меня. Для нас эти слабые места оказались критичны в такой степени, что речи о внедрении его где-либо, кроме бухгалтерии, не идет.
Что, например, не нравится меня:
1. Как уже писАл выше, реализация распределенки.
2. Крайне низкая производительность кода, написанного на встроенном языке. Кстати, до сих пор не понимаю, почему нельзя было лицензировать VBA, являющегося своего рода стандартом встроенного языка.
3. Просто запущенное клиентское приложение жрет немало ресурсов. Непонятно почему. Для меня это критично - люди в массе своей работают на терминал-серверах.
4. Упоминаемый выше переход на 1С под SQL повлек за собой установку дополнительного физического сервера. Вернее, двух, по числу основных площадок. Судя по их загрузке 5-6 бухгалтерами (на каждой из площадок), они не с документами работают, а моделируют ядреные взрывы...
5. OLE/COM объекты подтягивать можно. Но связывание только позднее (late bindings). Как падает при этом производительность объяснять, думаю, не надо.
6. Из таблиц на sql сервере практически ничего нельзя взять непосредственно, так как структура физического хранилища совершенно не соответствует логическому.
7. Кстати, вызывает вопросы реализация sql. В базе нет ни одного view, ни одной встроенной процедуры/функции, ни одного констрейна, ни одного триггера. Даже ключи есть далеко не везде. По моему, это странно, и свидетельствует о неэффективной работе с sql сервером.

Да, еще...
Лет уже много назад, когда только-только появилась версия 1С под MSSQL, то ли 7, то ли 7.5, то ли 7.7... Не помню. Мы попытались запустить у себя этот продукт. Не склалось, так как внедренцы явно недооценили сложность задачи, и так и не смогли за несколько месяцев работы предоставить хотя бы работоспособный прототип. Кончилось все тем, что их фирма закрылась, чтобы не возвращать нам деньгу. Я обратился в головную контору, которая в Москве, на Селезневской, хотелось вернуть деньгу за лицензию, хотя бы дилерскую цену (около 2 т.уе). Причем, мы возвращали весь комплект. Деньгу нам не вернули, мотивируя это тем, что книжки и коробка несколько изношены. На просьбу приобрести новые книжки и коробку были посланы, ибо книжки может купить только франчайник, а коробку они вообще никому отдельно не продадут из принципа, так что ловить нам нечего. Имел долгую беседу с одним из замов Нургалиева (это который руль, насколько я помню), так вот - зам это и разъяснил. Решение было принято на уровне руля, чтобы не создавать прецедент, так как орлов, вроде нас, немало. И у них есть такой термин - "проблемное внедрение", которое политически всегда вешается на франчайзи, даже если вины его нет, а проблемы вызваны самим продуктом. Так что, Алексей, будет кто-то из твоих клиентов недоволен - виноват будешь ты.

[Страусь]

Так что, Алексей, будет кто-то из твоих клиентов недоволен - виноват будешь ты.

Это я знаю. Прекрасно знаю. Кто же еще виноват, как не продавец