MGR OTiger
Ваше поклонение Аксапте уже переходит все границы. Вы про такое понятие как логика слышали когда нибудь? У Вас в машине есть задняя передача? Вот предстаьте что ее не стало. Сплошное преимущество-не правда ли?

А скажите, при чем тут автомобили?
У Вас при движении задним ходом одометр тоже назад крутится? И бензин в бак льётся?

Если не в курсе-просветлю, на механических одометрах именно так и происходит, крутится назад.
А вот насчет бензина я не понял. При движении вперед, по Вашему, он в бак льется?

MGR
Расскажите мне преимущества удаления разнесенных операций?

Ну зачем сразу удаление. Хотя удаление-показательный пример, если Вам нужно просто удалить, зачем организовывать сторно? Чтобы базка поболее была в объемах? А смысл? Посмотреть, кто и как где ошибался? Так история на это есть.
Зачем засорять рабочую БД? Редактирование из той же оперы. Смысл городить кучу лишних записей, если можно исправить существующие?
Я не говорю о таком методе, как о единственно верном. Я просто предлагаю пользователю давать выбор. А он уже сам разбереться кому такие права давать, а кому нет. Но выбор дролжен быть всегда и во всем. Чем больше выбора, тем комфортнее, и так во всем. Или Вы не согласны?

MGR
Клиенту дай волю - он балансы в ручную будет вбивать, ибо ему проще так будет в случае расхождений. Готовы Вы и на это пойти?
Смешно

MGR OTiger Если не в курсе-просветлю, на механических одометрах именно так и происходит, крутится назад.

Уже лет семь не ездил с механическим. Тут у меня пробел в знаниях.

Я тоже, но знания остались

MGR
Нет. Удаление разнесенной операции приводит к тому, что БД находится в том же состоянии, что была до этой операции (ну если после этого новых не было).
Вы привели пример автомобиля - значит автомобиль по вашему если мы ехали вперед 1км, а потом назад 1км, то состояние должно быть таким же. То есть бензина в баке должно не измениться. Я лишь Вашу логику продолжил :)

Ааа, ну так нас логика может завести далеко. Можно еще и оператора приплести, он как в случае с бензином, моложе не стал, когда распроводил.
А может еще и пару пончиков схрумкал...

MGR
Смысл в том, чтобы всегда знать всю историю.
Вы так и не ответили - что будет, если в УУ попали результаты операций, которые потом были удалены? То есть процесс консолидации усложняется?
В моей практике была ситуация, когда бухгалтер сделал проводку неправильную, через неделю её удалил - но за эту неделю данные пошли в центр. Операция была большая, шуму было много. А бух отказывался от ошибки - пока бекап не был поднят и ему не показали.

Вы сейчас говорите о частном случае, а я вообще. Когда данные консолидируются где то, т.е. куда то отправляются, согласен, здесь лучше всего сторно. И то в случае если данные уже ушли. А если еще нет, почему бы не дать возможность подправить и перепровести операцию.
И опять же, не у всех же так(данные отсылаются), кто то работает на одной БД.
Кстати, при использовании истории даже бэкапа не прийдется поднимать. Т.е. причина ищется без сотрудника поддержки, а силами обычного пользователя с правами.

MGR
Да, размер базы увеличивается, но не критично - редко когда откатываются более 1%.
История съедает больше.

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

MGR
На мой взгляд в пределах открытого периода делать можно что угодно - удалять, редактировать. Но закрыли - и всё, баста - только сторно.

Согласен, но "некоторые системы" вообще никак не позволяют...

MGR
Не всегда. Иногда большой выбор - зло. Малый выбор - конвеер, там производительность больше.
Ну насчет производительности я бы не был так уверен. Да и откуда такая зависимость взялась между возможностью выбора и производительностью?

MGRПричем тут оператор? Я не требовал чтоб водитель так же помолодел? Они - внешние по отношению к системе.
Изначально системой была БД, но Вы зачем-то приплели как пример системы - автомобиль. Так я и прицепился - теперь Вам и отцепляться :)

Странный у нас разговор получается. Если не понятно-давайте разложу по полкам с той же машиной и бензином.
В некоторых случаях вернуться из точки "B" в точку "A" быстрее(и бензина меньше затратите) просто включить заднюю передачу и вернуться метров на дцать назад. А не пытаться развернуться через некую точку "С". И времени больше потратите и бензина. Или Вы задней передачей вообще не пользуетесь?
MGR

Вы сейчас говорите о частном случае, а я вообще. Когда данные консолидируются где то, т.е. куда то отправляются, согласен, здесь лучше всего сторно. И то в случае если данные уже ушли. А если еще нет, почему бы не дать возможность подправить и перепровести операцию.

Ну разве интересно рассматривать сферического коня в вакууме? И продуктивно-ли?

Причем тут сферический конь? Я пытаюсь сказать, что вариантов масса и нельзя зацикливаться на частном случае. А Вы мне про вакуум какой то? По теме есть что сказать?

MGR

И опять же, не у всех же так(данные отсылаются), кто то работает на одной БД.

Ну да. Только обычно там тоже могут быть:
- консолидирующие таблицы
- олаповские кубы
- отчеты в налоговую или для владельцев

Ну и что страшного случится с Вашими консолидирующими таблицами, там все поменяется автоматом. А про Кубы я вообще не понял в чем проблема. У меня тоже кубы, пока вопросов не возникало. А про налоговую вообще смешно. Мы кажется уже договорились, что позволяем редактировать, удалять не всегда, ессно есть закрытые периоды. Более того, есть учет, который налоговой вообще не касается никаким образом. Проведение операции как правило тянет за собой процесс создания проводок как для налогового, бухгалтерского, так и для управленческого учета. Никто не мешает поправить в настройках атрибуты которые касаются только управленческого учета и перепровести операции хоть за весь год. При этом бух и налоговый лягут один в один, а управленческий в каких то моментах изменится. Но это так, из жизни и не руководство к действию ессно

MGR

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

Даже и не спорю. Во многих системах существует аудит. Правда его наличие ресурсоемко - лишние триггеры, лишние операции с БД.

Копейки, учитывая что историю ведем только тех данных, которые важны для компании, выборочно.

MGR

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

Мы говорим о самописке?
И потом - а какая разница, где история? Это не принципиально для производительности системы - впрочем мы конечно можем историю даже на другом сервере хранить. Это да. Лишние несколько тыщ долларов только затем, чтобы вести аудит?

Вот на другом сервере это лишнее. Так что аудит бесплатен. А причем тут самописка, не самописка. Что за лейблы то клеим. Тут была тема про самописки-почитайте-очень интересно...

MGR

Ну насчет производительности я бы не был так уверен. Да и откуда такая зависимость взялась между возможностью выбора и производительностью?

Конкретный пример зависимости количества выбора и производительности.
Делается какая-нибудь операция, например банковский платеж. Имхо сразу выгодней ограничить оператора выбором счета из диапазона, контрагентов - банки, соответствующие аналитики и пр.
Ведь противоположный подход - дать ему вводить любой счет и пр. - приведет к тому, что он будет долго-долго думать: "а какой мне нужен счет?".

Так же пример одной системы - форма журнальной операции по умолчанию содержит все доступные поля. Работать конечно можно, но тяжело.
Поэтому во время внедрения мы для разных операций делаем другие формы, в каждой из которой редко более 15-20 доступных полей используется.
Соответственно пользователь уже ограничен в выборе. Он не может задать код ОС при вводе операции с банком. Плохо это или хорошо? Я считаю - хорошо.

Не путайте понятия пожалуйста. Это ограничения совсем другого плана. Вы разницу улавливаете, ограничения по действиям или ограничения по выводимым данным? Тут скорее был бы более правилен пример, что пользователю дается право выбрать один из двух счетов. Он один выбрал ошибочно, а поменять на другой система не дает...

MGR OTiger
В некоторых случаях вернуться из точки "B" в точку "A" быстрее(и бензина меньше затратите) просто включить заднюю передачу и вернуться метров на дцать назад. А не пытаться развернуться через некую точку "С". И времени больше потратите и бензина. Или Вы задней передачей вообще не пользуетесь?


Именно сторно и является в такой ситуации аналогом задней передачи.
А ещё вариант - очередь UNDO/REDO
В нормальной системе (да хоть ворд возьмите) при выполнении UNDO информация о отмененной операции не удаляется, а формируется некое "сторно" в REDO.
Ведь оператор (пользователь) мог не то удалить. И что тогда делать?
Пример. Надо удалить операцию с номером 123. Но случайно оператор удалил операцию 122, в которой всё было похоже, только контрагенты разные. Как быть? Надо вернуть операцию 122 и удалить 123.
Операции 122 и след простыл, как мы будем восстанавливать? Какой там контрагент? Какой центр затрат?
У нас возникла операция 124 (сторно от 122). Либо она в черновике и можно удалять, либо если удалять никогда нельзя - аккуратно создаём операцию 125, которая полностью повторяет 122. В описании пишем "ошибочно отсторноровано как №122 и повторно проведено".
А затем пытаемся отсторнировать 123. До тех пор пока точно 123 не отсторнируем. ;)

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

MGR

Причем тут сферический конь? Я пытаюсь сказать, что вариантов масса и нельзя зацикливаться на частном случае. А Вы мне про вакуум какой то? По теме есть что сказать?
Не нравится мне Ваш тон. Значит вакуум - не по теме, а одометры Ваши - по теме? 8-О
Я приводил конкретный пример, а Вы вместо ответа не пойми что про вакуум у коня. Или я просто не понял тонкости Вашего замечания?. И какой ответ желали получить?

MGR

Ну и что страшного случится с Вашими консолидирующими таблицами, там все поменяется автоматом.

Не всегда балансовые таблицы (или консолидирующие) разумно заполнять триггерами автоматически. Это к вопросу об "общем случае" в вашей нотации и о "сферическом коне в вакууме" в моей.

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

MGR

А про Кубы я вообще не понял в чем проблема. У меня тоже кубы, пока вопросов не возникало.

А не проблема. У меня щас нет кубов.
Но знаю пример, когда есть кубы обновляющиеся каждую ночь, а у одного знакомого - раз в месяц. Долго считается, но более частые обновления не нужны.

Так в Вашем случае сторно Вы нарываетесь на такую же проблему. Впрочем так же как и с консолидирующими таблицами...

MGR1. Рад что посмешил Вас.
2. Вроде ничего не договаривались про закрытые периоды.
3. И столько геморроя для того что бы удалить (изменить) одну операцию? В случае сторнирования - один раз настраиваются правила переноса в НУ/УУ, а потом делаем простое сторно (причем это может быть кнопочка, нажимаемая при просмотре оригинальной операции)

1....
2. Сами писали, что если период закрыт, то править нельзя, и я кажется даже с Вами согласился
3. Вы знаете, это все теория. Я всегда клиентам предлагаю оба варианта, еще ни разу никто не захотел через сторно(бухгалтера не в счет ). Зайдите на AXForum. Там столько сообщений именно по этой проблеме. Народ приходит и спрашивает КАК? А им в ответ - Да Вы лохи и ничего не смыслите в этой жизни. Сторно делайте. А им в ответ, хотим просто исправить. А им, ну вот если через ж..у то вообщем то можно вот так переиначить проблему.
Так что не рассказывайте мне про геморрой.

MGR
А что важно? Вроде разговор шел про операции, а не справочник контрагентов?
Ну и какие копейки при аудите по главной книге?

Ну это смотря какую историю и как сохранять. Можно сдуру устроить аудит остатков товара, только зачем? Не проще идти от исходных операций?

MGR
Это так кажется только - вроде бы не все СУБД поддерживают транзакции в нескольких БД.

Опять ищем частный случай невозможности реализации? Давайте еще вспомним файл сервер. Вы с какой СУБД работаете, там это невозможно?

MGR

А причем тут самописка, не самописка. Что за лейблы то клеим.
Причем тут лейблы? Это был просто интерес, ибо я не слышал о системе, в которой аудит ведется в другую базу.

Так если логически рассуждать, так проще. Зачем забивать рабочую БД мусором?

MGR
В одной системе видел интересно реализованный интерфейс допустимых действий. Красивый граф такой возникал. Между статусами документа можно было рисовать дуги - действия. Такое и не красивыми способами можно реализовать - не суть. Суть же в том, что потратив время на настройку подобного графа потом уменьшить пользователю степени свободы, однако добавить удобства.
А если вернуться к любимым Вами автомобилям - зачем сейчас строят дороги? Казалось бы, надо забить на них, а люди будут покупать Wrangler-ы, УАЗики и прочие Hummer-ы.
Расходов государству никаких. А на вышеуказанных авто можно проехать почти везде без всяких дорог.
Однако строят дороги, уменьшая свободу пользователей. И если я еду из Москвы в Питер - у меня есть только одна (немного утрирую) дорога. А так было бы - бесконечно.
Но так лучше - потому как:
а) я не думаю о том, как мне ехать в Питер. Я лишь смотрю на указатели
б) я доеду на своей машине быстрее
Вы знаете, по моему пора заканчивать. Уже тяжко если честно. Простая задачка на сообразительность Вам про дорогу Москва - Питер. Едем неважно откуда куда. Перед известной Новгородской объездной на заправочке, Вам водила встречный говорит, там "вилы" - авария, пробка часа на 3. Вы попретесь на объездную? Или все таки проедете через Новгород?

GaryaOTiger, не злоупотребляйте, пожалуйста цитированием. Модератор.

Остается лишь полностью согласиться! Написали красиво, я бы так не смог