Выделено из другой темы, после этого сообщения - SH
------------------
Вы когда-нибудь видели лицо бухгалтера, который обнаружил, что сданные в органы отчетность за прошлый период отличается от тех, что в базе?
В таблице детализации документа как минимум есть код товара, кол-во и должна быть единица измерения базовая и выбранная, это позволяет достоверно хранить данные и отображать их без каких-либо последствий после изменений в НСИ товаров.
Пользователь не знает что храниться в базе, ему это не объяснить, он должен видеть актуальную информацию, если вместо 360 шт. яиц он затем увидит 9000 шт. в накладной прошлого квартала, сколько времени ему потребуется докопаться до сути, даже при условии, что он знает об этой "фиче". Программа виновата всегда, защита от дурака должна быть везде где это только возможно, это вам ответит любой разработчик.
Я просто сводил эти косяки к тому , что в sh и так обширное поле для злоупотреблений, а так можно списать еще и на программу. Весь мой спич про данные сводился к этому. Чем чище данные , тем проще поймать.
Вопрос по sk7: база у него в DOS/Windows варианте та же , т.е. UDB или что то другое?
---------- Добавлено в 13:46 ---------- Предыдущее сообщение было размещено в 13:38 ----------
Я не собираюсь менять р-кипер. В моем случае надо правильно выбрать, т.к. внедрение будет с нуля. Вопрос по тормозам на айко меня очень сильно беспокоит. Это после внедрения не заметно, но после 1 года эксплуатации может оказаться,что никто об архивировании данных и не думал, т.е база пухнет запросы отрабатывают медленнее, при разделения на оперативный и архивный период данная проблема легко решается, но решена ли она для айки я не знаю. Еще один камень в айку от меня это то, что если я не ошибаюсь, она на .net во фронте написана на c#. Если это так, то потребуются гораздо более производительные компьютеры на фронт, чем для кипера.Поэтому, чтобы отказаться от кипера с хаусом, нужны железобетонные аргументы. Пока их никто не предъявил.