Крикливенко Виталий[quot Ler_A]С]
А Вы считаете, было необходимо ознакомить главных специалистов предприятия со структурой базы данных???

Дальше читать тем, кого действительно интересует практические вопросы по системе, а не теоретические сентенции.

Готов делиться опытом ....

С уважением,
Крикливенко Виталий,
Заместитель начальника УИТ по развитию информационных технологий,
ГП НПКГ "Зоря"-"Машпроект"


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


Крикливенко Виталий
А давайте это обсудим в отдельном топике. По-моему тема изначально другая: "Кто знает об IT-предприятии...........". Так мы можем докатиться и до обсуждения количества "табличек".


Более интересует качество. И тема была изначально "Кто знает об IT-предприятии..........."

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

Крикливенко Виталий... Поверьте мне, я не только интересуюсь структурой базы, но прекрасно в ней ориентируюсь (если можно так выразиться по отношению к структуре базы данных), поскольку это одна из моих прямых обязанностей...


[quot Крикливенко Виталий]
Где конкретные вопросы? Или вы считаете вопрос о том, как и что называется, конкретным? Почему все так вцепились в эту таблицу. Никого не интересует, как проходит процесс внедрения, какие контуры, какие проблемы были на этапе внедрения, технические вопросы, организационные, методологические, да мало ли...

С уважением,
Крикливенко Виталий,
Заместитель начальника УИТ по развитию информационных технологий,
ГП НПКГ "Зоря"-"Машпроект"

А меня в данном случае не интересует "как проходит процесс внедрения".
Так же, как и названия таблицы или полей. Если, как утверждается, в месяц проходит до 50000 документо-строк по ТМЦ, то структура базы должна быть хорошо сконструирована. В противном случае система будет требовать больших ресурсов, а производительность по мере насыщения базы данными будет падать.

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

Дело даже не в новом варианте проблемы 2000 года, о которой рассказал «хочу все знать». Если в одной таблице хранится информация по остаткам ТМЦ только в пределах года, то соответственно нет истории, нет возможности анализа за достаточно продолжительный период времени и соответственно решать различные управленческие задачи..

Что вызывает большие сомнения – это то, что месячные остатки хранятся в базе данных, если они не подтверждены соответствующими документами (например, инвентаризацией). Не думаю, что на производственном предприятии по каждому подразделению (надеюсь, что такое поле имеется) каждый месяц проводится инвентаризация. Соответственно получается, что база физически содержит документально неподтвержденные документом ПРОМЕЖУТОЧНЫЕ итоги. В этом случае, решая проблему ускорения обращения к данным, получаем проблему синхронизации данных по остаткам с операциями движения ТМЦ. Проблема синхронизации данных по остаткам обусловлена тем, что остатки и движение находятся в разных таблицах, и таблица остатков требует автоматического перасчета (и возможно одновременно она должна быть редактируемой). Например, если 2 числа месяца возникает необходимость обращения к предыдущему периоду и внесения соответствующей коррекции, то это требует автоматического пересчета остатков. Более правильный подход – это динамический пересчет остатков от последней инвентаризации и хранение остатков (точнее результатов инвентаризации) в одной таблице с движением ТМЦ. Тем более, что построение запроса по одной таблице будет выполняться быстрее, чем обращение к нескольким таблицам.

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

Garya2 Ler_A. Если в рамках одной транзакции формируется и движение, и пересчитывается остаток, то никогда и ни при каких условиях некорректные остатки там возникнуть в принципе не могут. Если же есть сомнения по этому поводу, то в большинстве учетных систем предусмотрена специальная операция. Называется она по-разному "принудительный пересчет остатков", "ремонт" и т.д. и т.п. Но по сути она может пересчитать еще раз то, что уже было посчитано.


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

mazzy
Ведь правда, здесь хороший форум?

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

Отбросив всю рекламную мишуру.

Garya]Потому что даже супернадежное ПО и оборудование иногда дает сбои. Однако, отсюда не следует, что вычисляемый "на лету" итог будет корректен, а хранимый итог - некорректен. Вероятность того, что какой-то из них окажется некорректным, существенно не отличается.

Перед этим Вы доходчиво объснили, зачем нужны автоматизированные системы, а далее выяснилось, что доверия к ним нет.
Если от сбоев оборудования не уберечься, то все остальное дело "рук человеческих", например, некорректной логики функционирования ПО.

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

Если же хранить нередактируемые промежуточные итоги, то это прямой путь к снижению надежности ПО. Ведь обязательно должны быть и редактируемые итоги.