[ОТВЕТИТЬ]
Опции темы
25.01.2017 21:19
 
Причем если мне не изменяет память, данные по изменению документа доступны по каждому без шаманства.
Следовательно долгих разборок не будет, с учетом четких ролей и проверок, жесткого логирования операций, с доступностью инфы по документам, кто, где и когда.
Роли распределяются в соответствии с должностями. В случае форс мажора, кто-то зашел не со своего места, не под своим логином и решил устроить сладкую жизнь, всегда можно отследить, где это произошло, как минимум место "преступления" и запретить в ролях эту операцию, если например рабочее место доступно для множества сотрудников.

Идею бороться в первопричиной в СуперМаге Плюс - полностью поддерживаю. В итоге на вопросы некоторых клиентов, а как с вот этим борьба идет, бывали недопонимания, а зачем с этим бороться? нет причины, нет следствия.
25.01.2017 21:23
 
Цитата:
Crush А, вообще, правильнее всего сделано в буржуйских системах. Там проведенный документ ни при каких обстоятельствах корректировать нельзя. Хотите изменить количество - создавайте сторнирующий документ.
Только хотел об этом написать, но потом подкорректировал комент, т.к. об этом речь не шла.
Так вот, клиентов, желающих как в буржуйских системах - каждый второй.
СуперМаг Плюс может поддерживать полный запрет на работу задним числом - это всего лишь настраиваемое право, причем по ролям, т.е. у кого то может быть, у кого-то нет. Равно как и можно запретить редактировать действующие документы :)

В итоге ни один, ни один клиент на это не согласился в действительности! Потому что это Россия :))) Если бы наши поставщики были дисциплинированы, равно как и сотрудники, которые день в день принимали бы документы - вопросов бы не было.
Но даже у себя в компании, даже пытаясь хотя бы в электронном виде получать документы как можно быстрее (скан), ерунда выходит. Все ровно только в одном случае, когда мы работаем с компанией в системе электронного документооборота. А в остальных - человеческий фактор, когда иногда ошибку в документах приходится неделями выяснять.

Дебиторка по первичке - это гемморой всех видов бизнеса. Сейчас некоторые покупатели идут другим путем: сначала весь пакет документов, потом только товар и только потом оплата. Хотя и этот путь не избавляет от проблем, т.к. приход товара и первичный документ - не всегда совпадают :))
25.01.2017 21:30
 
Цитата:
Crush А, вообще, правильнее всего сделано в буржуйских системах. Там проведенный документ ни при каких обстоятельствах корректировать нельзя. Хотите изменить количество - создавайте сторнирующий документ.
Есть у нас Navision в Библиоглобусе. Ничего хорошего в российской действительности.
25.01.2017 23:00
 
Цитата:
OlegON Детализацию и отчеты можно сделать с помощью фичи СУБД - FGA. Даже включать и исключать по каким-то условиям и прочее. Вопрос в невостребованности такой фичи для аудитории этого софта. Если хранить все изменения с соответствующими аттрибутами на сетевом магазине с кучей народа, база распухнет до невообразимых размеров очень быстро.
У меня противоположный опыт. У нас такой функционал был с самого начала, разрабатывался еще в 2004 году. Я уже настолько привык, что не понимаю, как может существовать учетная система для бизнеса, в которой все ходы не записаны. Честно, ощущение работы вслепую. Функционал в реальной жизни востребован более чем. У нас продвинутые пользователи пользуются самостоятельно. А уж при разборе полетов вещь незаменимая, позволяющая экономить массу нервных клеток.

Одно дело иметь какой-то инструмент, другое дело реальное работающее решение. Ms тоже анонсировало подобный инструмент в sql 2016, позволяющий логировать операции с базой данных без использования триггеров. Даже одинэсники включили поддержку версионирования в свою платформу, а во флагманской конфигурации УПП сделали попытку внедрить реальный функционал. Но у них все грустно с этим из-за специфичности используемой технологии...
Если с самого начала развития системы полноценный аудиторский след не был предусмотрен, то, когда появится большой слой прикладного функционала, включить это уже затруднительно.

Олег, ты прав, что лог растет быстрее основной базы. Я тоже когда-то опасался этого, предусмотрев возможность его отключения в параметрах программы. Но так ни разу и не воспользовался этой функцией. У нас используется транзакционный принцип организации лога, подсмотренный в одной старой западной системе. Сохраняемая информация минимизирована. Плата за это - более сложная схема извлечения, раскрутка, начиная с момента создания записей. Но главное, это разделение лога на рабочую часть и архивы. Это позволяет держать в модифицируемой таблице лога минимум информации, с момента создания последней резервной копии базы данных (одновременно информация переносится из оперативного лога в архивы). Архивы лога хранятся отдельно от основной базы данных, поэтому на производительность системы влияние не принципиальное.
25.01.2017 23:17
 
Цитата:
~Guest~ Только хотел об этом написать, но потом подкорректировал комент, т.к. об этом речь не шла.
Так вот, клиентов, желающих как в буржуйских системах - каждый второй.
СуперМаг Плюс может поддерживать полный запрет на работу задним числом - это всего лишь настраиваемое право, причем по ролям, т.е. у кого то может быть, у кого-то нет. Равно как и можно запретить редактировать действующие документы :)

В итоге ни один, ни один клиент на это не согласился в действительности! Потому что это Россия :))) Если бы наши поставщики были дисциплинированы, равно как и сотрудники, которые день в день принимали бы документы - вопросов бы не было.
Но даже у себя в компании, даже пытаясь хотя бы в электронном виде получать документы как можно быстрее (скан), ерунда выходит. Все ровно только в одном случае, когда мы работаем с компанией в системе электронного документооборота. А в остальных - человеческий фактор, когда иногда ошибку в документах приходится неделями выяснять.

Дебиторка по первичке - это гемморой всех видов бизнеса. Сейчас некоторые покупатели идут другим путем: сначала весь пакет документов, потом только товар и только потом оплата. Хотя и этот путь не избавляет от проблем, т.к. приход товара и первичный документ - не всегда совпадают :))
Запрет изменений задним числом не прокатывает больше из-за нашего дурного законодательства, чем из-за человеческого фактора. Люди везде совершают ошибки.
Сейчас практика такая, что по ролям настраивают количество дней, в течении которого можно вносить изменения в документы. Кроме документов есть еще справочники, за изменениями в которых надо следить...
26.01.2017 07:14
 
Цитата:
FinSoft на производительность системы влияние не принципиальное
Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.
26.01.2017 09:33
 
Цитата:
OlegON Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.
Ну это странный аргумент, у нас каждое изменение строки логируется, в том числе количества и цен (а у многих клиентов количество одновременных пользователей существенно больше 100). Более того пользователь (с правами соответствующими естественно) может включить логирование изменение любого (!), в том числе вычисляемого (!), показателя который он видит, и они этим активно пользуются. И никакой особенной проблемы с местом не замечали. Все равно те же чеки жрут значительно больше места чем вся остальная база (даже с логами). Для этого просто создается tablespace отдельный на hdd и туда скидываются редко используемые данные (логи чеки и т.п.). При этом сейчас даже в любом ноуте больше террабайта hdd диск.
26.01.2017 10:01
 
Ничего странного. Давайте от теории ближе к практике, допустим, средняя накладная из 5000 строк, сохранение деталей по каждой строке с накладными, ну, пусть 1Кб, это немного, учитывая накладные расходы, в т.ч. на индексы. Итого, 5Мб на изменение накладной. 100 человек могут выдать до 100 измененных накладных в минуту, т.е. до 500Мб в минуту прироста и записи на диск. А теперь представим, что в ЦО стекаются данные со всех магазинов и кто-то проводит инвентаризацию с простановкой цен... Очень даже круто растет база... А это еще рост и ее бекапа, т.е. диски только подносить надо будет...
26.01.2017 10:45
 
Цитата:
OlegON Ничего странного. Давайте от теории ближе к практике, допустим, средняя накладная из 5000 строк, сохранение деталей по каждой строке с накладными, ну, пусть 1Кб, это немного, учитывая накладные расходы, в т.ч. на индексы. Итого, 5Мб на изменение накладной. 100 человек могут выдать до 100 измененных накладных в минуту, т.е. до 500Мб в минуту прироста и записи на диск. А теперь представим, что в ЦО стекаются данные со всех магазинов и кто-то проводит инвентаризацию с простановкой цен... Очень даже круто растет база... А это еще рост и ее бекапа, т.е. диски только подносить надо будет...
Не совсем понял почему лог должен занимать больше самих данных. То есть размер лога = размер данных + размер данных * коэффициент правок (лога). Коэффициент правок хорошо если 10%. Итого размер базы увеличивается в 2.1 раза. При этом если взять чеки которые нет смысла логировать, то даже в системе класса ЕРП все остальные данные с логированием будут все равно в раза 2 меньше размера таблиц чеков. Итого общий размер с логами увеличится процентов на 20. А если учесть что логи и чеки можно положить на hdd то проблема размера логов по-любому надумана.
26.01.2017 10:54
 
Цитата:
OlegON Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.
Олег, рабочая часть лога обычно содержит только дневные изменения. Остальное в архивах. Считай, что они за пределами базы данных. Опять таки, мы понимаем, что логировать есть смысл только те данные, которые изменяются. В частности, в сетевой рознице львиная часть данных - это чеки, пробиваемые на кассах. Их логировать смысла нет, так как они не изменяются.
Логирование, конечно, требует дополнительные вычислительные ресурсы. Но производительность работы в гораздо большей степени зависит от структуры базы данных и методик работы с ней.


Опции темы



Часовой пояс GMT +3, время: 01:14.

Все в прочитанное - Донат - RSS - - Карта - Вверх

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.