Многоуважаемые программисты. Вопрос может немного не по теме, но тем не менее. Пишу складскую программу firebbird + delphi 7.0. Опыт небольшой. Подскажите, пожалуйста, стоит ли хранить промежуточные остатки товаров, взаиморасчетов в отдельных таблицах? Я рассчитываю их на конец месяца при проведении документа при помощи хранимой процедуры. Далее при наступлении следующего месяца (расчетного периода) переношу их с предыдущего месяца, а далее опять при проведении документа их изменяю, потом при наступлении следующего месяца опять переношу и т.д. Или можно вообще отказаться от промежуточных итогов. Не будет ли это тормозить на большом объеме данных, т.к. документы придется просматривать с начала ввода? А промежуточные итоги нужно тоже пересчитывать, если документ проводить задним периодом. Может, кто проектировал склад? Как рассчитывал остатки? Поделитесь опытом. Намекните. С уважением, Андрей.

Чем 1С не устроил?

>Andrey2025   (02.04.10 23:29)  
кол-во записей в месяц? порядок?

> Германн ©   (03.04.10 02:31) [1]
>
> Чем 1С не устроил?

Нафиг он сдался?

> Andrey2025   (02.04.10 23:29)  

Вообще - смысла нет. Если только не очень много. Хотя, если такие вопросы - значит не много. Так что не стоит :)

> Или можно вообще отказаться от промежуточных итогов. Не
> будет ли это тормозить на большом объеме данных, т.к. документы
> придется просматривать с начала ввода?


Если документов будет максимум 100000, то тормозов не будет (если запросы грамотно написать и индексы в нужных местах проставить), если порядка 1млн, то будет в 10 раз медленнее :)

>Loginov Dmitry ©   (03.04.10 16:10) [4]
для FB и миллион не проблема при условии

если запросы грамотно написать и индексы в нужных местах проставить



если порядка 1млн, то будет в 10 раз медленнее :)

это не соответствует действительности)

> это не соответствует действительности)


для расчета остатков придется пройтись по всем записям таблицы от начала до указанной даты. Чем записей больше, тем медленнее. Очевидно, что в данном случае зависимость линейная, или близка к ней.

> для расчета остатков придется пройтись по всем записям таблицы
> от начала до указанной даты. Чем записей больше, тем медленнее.
>  Очевидно, что в данном случае зависимость линейная, или
> близка к ней.

для получения остатков по товару, необходимо пройтись по индексу - full scan таблицы(это именно "пройтись по всем записям таблицы от начала до указанной даты") здесь совершенно не причем

> для получения остатков по товару, необходимо пройтись по
> индексу - full scan таблицы(это именно "пройтись по всем
> записям таблицы от начала до указанной даты") здесь совершенно
> не причем


Поскольку остатки нужно рассчитать разом для всех товаров, то обойдется весь индекс-дата вплоть до заданного значения. И чем больше записей, тем больше времени все это займет. Таким образом зависимость будет линейной, или близка к линейной.

Класс ! Чел не знает ни складского учета, ни программирования и садится писать программу. И тут же появляются доброхоты-помощнички :)

> Чел не знает ни складского учета, ни программирования


Через 15 лет освоит!
:)

Удалено модератором

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

> Класс ! Чел не знает ни складского учета, ни программирования
> и садится писать программу. И тут же появляются доброхоты-
> помощнички :)

Коммент без основания.
А всем остальным спасибо, хоть за какую-то помощь.

> Andrey2025   (04.04.10 00:54) [12]
>
> Очень бы хотелось получить информацию по работе ThreeWiev
> или его модификациях, может, кто даст ссылку, где скачать
> описания подробное этого компонента. Нужно для организации
> древовидной структуры справочников наподобие 1с.
>

Так может лучше купить 1С?

P.S. Ты бы хоть для начала освоил "правильнописание". TreeView.
Потом попытайся прочитать справку Delphi по компоненту TTreeView.

> Так может лучше купить 1С? P.S. Ты бы хоть для начала освоил
> "правильнописание". TreeView.Потом попытайся прочитать справку
> Delphi по компоненту TTreeView.

Извини, описался. Кое-что уже нарыл по данному компоненту в doc формате. Постараюсь разобраться. И вообще, причем здесь 1С? Это форум по delphi. Справки Архангельского читаю, но их одних недостаточно. Если у кого есть полезные ссылки на статьи по данному компоненту или подобным, в частности по построению дерева на основе данных, рекурсивным запросам, буду очень рад, остальной флуд типа 'ничего не знает' прошу не писать.

> Andrey2025   (04.04.10 03:07) [15]
>
>
> > Так может лучше купить 1С? P.S. Ты бы хоть для начала
> освоил
> > "правильнописание". TreeView.Потом попытайся прочитать
> справку
> > Delphi по компоненту TTreeView.
>
> Извини, описался. Кое-что уже нарыл по данному компоненту
> в doc формате. Постараюсь разобраться. И вообще, причем
> здесь 1С? Это форум по delphi.

Да это форум по Дельфи. Но на этом форуме никто не приветствует разработку велосипедов.
А чем ещё ещё является твой сабж, как не разработкой нового велосипеда?
Я уж не перехожу на "отдельные личности", на которые ты ссылаешься. :)

> Германн ©   (04.04.10 02:08) [14]


> Так может лучше купить 1С?
>

Дался тебе этот одинэс..

> Andrey2025   (04.04.10 03:07) [15]

Смотри в сторону DevExpress - там все есть.

> turbouser ©   (04.04.10 03:24) [17]
>
>
> > Германн ©   (04.04.10 02:08) [14]
>
>
> > Так может лучше купить 1С?
> >
>
> Дался тебе этот одинэс..
>

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

Вот лично мне он не дался. Я следую линии ИШ. Он всегда полагался (по крайней мере внешне) на Microsoft. :)

> Вот лично мне он не дался. Я следую линии ИШ. Он всегда
> полагался (по крайней мере внешне) на Microsoft. :)
>

Т.е. на уже разработанные велосипеды. :)

> Свят, свят. Упаси господь.Но тут вопрос, имхо, стоит так:
>    Малообученный студент пишет что-то, что ему задал мало-
> знающий начальник, который думает, что нужно сделать так-
> то. Вот лично мне он не дался. Я следую линии ИШ. Он всегда
> полагался (по крайней мере внешне) на Microsoft. :)

Пока ничего, кроме флуда не предложил, т.к. предложить нечего, я сразу это понял с первых твоих постов.

> Смотри в сторону DevExpress - там все есть.

Это что-то новенькое для меня, будем разбираться. Спасибо.

>Loginov Dmitry ©   (03.04.10 19:55) [8]

>
> Поскольку остатки нужно рассчитать разом для всех товаров,
>  то обойдется весь индекс-дата вплоть до заданного значения.
>  И чем больше записей, тем больше времени все это займет.
>  Таким образом зависимость будет линейной, или близка к
> линейной.

кому нужно рассчитать сразу? для чего?
уже сошлись на том, что нужна одна таблица
типовая задача(с учетом того, что данные по движению за всё время хранятся в одной таблице - без промежуточных итогов): получить остаток по товару на дату.
какой смысл считать остатки ПО ВСЕМ товарам каждый раз?
причем здесь линейность зависимости?)

> какой смысл считать остатки ПО ВСЕМ товарам каждый раз?
> причем здесь линейность зависимости?)


Я так понимаю, что основная сложность в том, что требуется возможность вычисления остатков товара на указанную дату. Остаток отдельного товара на указанную дату мало кому интересен, следовательно должен быть какой-то отчет по остаткам товаров на складе на указанную дату. И тут учитываться будут все товары.

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

> кому нужно рассчитать сразу? для чего?уже сошлись на том,
>  что нужна одна таблицатиповая задача(с учетом того, что
> данные по движению за всё время хранятся в одной таблице
> - без промежуточных итогов): получить остаток по товару
> на дату.какой смысл считать остатки ПО ВСЕМ товарам каждый
> раз?причем здесь линейность зависимости?)


Остатки товаров нужно рассчитывать для подбора в форме (примерно как в 1с торговля и склад), а также для контроля остатков при проведении документов на определенную дату (здесь нужно рассчитывать только по определенным товарам).

> Кроме того, нужна возможность рассчитать остаток отдельного
> товара на текущий момент времени.

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

Напрасно автор обиделся :)
Однако на лицо типичная ошибка начинающего, но энергичного программиста - не понимая задачи перебирать инструменты.
В самом деле, все эти "деревья", "девэкспрессы" и прочая - это всего лишь молотки, пилы, сверла..
У автора же, ИМХО, главная проблема - это путаница в ПРЕДМЕТЕ. А именно в складском учете, о че красноречиво свидетельствует вот эта фраза :

"Далее при наступлении следующего месяца (расчетного периода) переношу их с предыдущего месяца, а далее опять при проведении документа их изменяю, потом при наступлении следующего месяца опять переношу и т.д. Или можно вообще отказаться от промежуточных итогов. Не будет ли это тормозить на большом объеме данных, т.к. документы придется просматривать с начала ввода?"

1С здесь советовали не случайно, написать нормальную складскую программу много быстрее, детально изучив 1С Склад (а я бы советовал начать с 1С Бухгалтерии). При этом внимание обращая не на "рюшечки" в виде древовидных справочников 1С (вот еще "чудо": во-первых страшно корявое, а во-вторых легко реализуемое безо всяких дев- и прочих экспрессов), а на МОДЕЛЬ документооборота, ОБЪЕКТЫ учета и связи между ними.

>Andrey2025   (04.04.10 11:17) [25]
>Для этого я завел дополнительную таблицу, где хранятся оперативные >остатки товаров на текущую дату на определенном складе.

Что значит "на текущую дату" ? А если товар не двигался полгода, то что, этот остаток надо переписывать и хранить на каждый последующий день ?

>Данные там изменяются при помощи хранимой процедуры при проведениии
>(удалении) документа.

Да поймите же, что ПОФИГ где они там изменяются, В ХП, триггере или вообще с помощью клиентских запросов - это именно "рюшечки". Главное - это ПРАВИЛЬНОЕ обеспечение целостного перехода БД из одного состояния (до документа) в другое целостное (после документа).

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

Во эта фраза говорит о том, что Вы банально "не в теме". Опять же отошлю к 1С - разберитесь с проводками и проведенными (откаченными) документами

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

Просто набор трескучих фраз, по мнению автора должных убедить общественность в том, что он типа крутой и знает что почем. Какие промежуточные таблицы и что Вы в них будете хранить ? Да еще при обновременной работе с разными документами с нескольких компов.
Каким боком тут объемы ? В курсе ли автор: что 1С, которую он так не любит, но "уши" которой торчат буквально из всех его высказываний, "тормозит" в основном не от объемов, а совсем по другой причине ?

> 1С здесь советовали не случайно, написать нормальную складскую
> программу много быстрее, детально изучив 1С Склад (а я бы
> советовал начать с 1С Бухгалтерии). При этом внимание обращая
> не на "рюшечки" в виде древовидных справочников 1С (вот
> еще "чудо": во-первых страшно корявое, а во-вторых легко
> реализуемое безо всяких дев- и прочих экспрессов), а на
> МОДЕЛЬ документооборота, ОБЪЕКТЫ учета и связи между ними.
>

Спасибо за предложение. При написании программ в 1С существуют уже готовые инструменты, как регистры и БухгалтерскиеИтоги. Там не возникает вопрос. как хранятся промежуточные итоги и т.д. Их только рассчитывай, группируй, при помощи запросов, методов. Например, при написании книги продаж в бухгалтерском учете (вернее ее доработке) у меня не возникло никаких проблем, а вот при написании книги продаж по оплате для firebird и delphi 7 возникло много подводных камней. Да даже Строка ввода денежных сумм, в 1С есть два знака после запятой, а в delphi пришлось писать для этого кусок кода, чтобы было как в 1С (выравнивание справа, два знака после запятой, форматированный ввод). Да и справочники в 1С не проблема.  Задал владельца, родителя, периодический реквизит и все. А на делфи нужно подумать немного. Пока сделаешь такой же справочник номенклатуры как в 1С с периодическими реквизитами и возможностью их редактирования. Но это уже все на начальном этапе сделано было. Думаю пока отказаться от промежуточных итогов и доделать книгу продаж.

> >Для этого я завел дополнительную таблицу, где хранятся
> оперативные >остатки товаров на текущую дату на определенном
> складе.

Зачем на последующий день? Таблица не хранит остатки по датам. Она хранит оперативные остатки, пересчитываются только те товары, которые указаны в таблице документа.

>  что он типа крутой и знает что почем

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

И все же было б лучше если б Вы объяснили почему не устраивает 1С, особенно при том, что имеется опыт и знание ?

По поводу "птицы" и дэлфи:
Если Вы писали сиквели для 1С, то построить их аналоги в птице будет для Вас нетрудно.
Дэлфи сама по себе не имеет отношение ни к каким базам, а вот компоненты-другое дело. Для их освоения и понимания нужно, конечно, какие-то время. Именно для птицы рекомендую книгу "Мир Интербэйз".

Отличие программирования 1С от более универсальных типа Дэлфи, действительно, немалое, но заключается оно не только в компонентах (в 1С тип оно сама, а в Дэлфи нужно кувыркаться), - это бороется со времененм наработкой собственных инстументов.
На мой взгляд куда большей "перемывки" мозгов при уходе от 1С требует переход с сугубо локальной на КС-технологию. Это для "свистуна", как правило, достаточно сложно и требует времени ибо 1С здорово "портит" само понимание работы с базами данных

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

Вот не советовал бы. Хотя бы потому, что "книга продаж" не имеет однозначного толкования, тем более реализации. Более того, она вообще не является обязательной и в мощных учетных системах ее попросту нету за ненадобностью.
ИМХО, советую "плясать" от складской (бухгалтерско-складской) карточки. Именно в карточки заносится информация о резервировании или движении ТМЦ из материальных документов (накладных, счетов-фактур, актов списания, возвратных накладных и т.д.).
Если несколько складов (точнее, не складов, о материально-отвественных лиц), то на каждом складе (МОЛ) - своя карточка.
На этой же карточке и САЛЬДОВЫЕ остатки, которые пересчитываются лишь при операциях СТОРНИРОВАНИЯ. Во всех остальных случаях перепроведения документов прошлыми месяцами - полный откат и полный пересчет всей картотеки. Все остальное - от лукавого.

> 1С здесь советовали не случайно, написать нормальную складскую
> программу много быстрее, детально изучив 1С Склад

Ещё быстрее заплатить 1С, что бы они это сделали.
Кстати и быстро, и не дорого, и есть с кого спросить если что не так.
А иначе новый велосипед в большинстве случаев.

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

в чем проблема?


>  Остаток отдельного товара на указанную дату мало кому интересен

серьезно?)
на этом дискуссию можно заканчивать))


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

какой смысл "городить огород" с триггерами?
чтобы жилось веселее?

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

ну а как дерево строить
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=488
очень понятно. А то переставишь систему - и начался поиск и перестановка всех сторонних компонентов..
А некоторых уже к этой версии делфи нет, не которые более не поддерживаются..

---------
Тоже раз пригласили - написать типа такого
Я сказал - 2 месяца.
Месяц - первый тестовый вариант, второй месяц - обкатываем.
Мне их главный сказал, что это не серьезно - современные средства типа, уровень техники типа, и вообще
бороздеть космическое пространство или небороздеть!?

Я стал про движение, документы, задние числа / сторно, средневзвешенные/фифо..
Он мне про таблицу остатков, куда каждый баран могет внести числа...

И чем ёксель не подошел им?..
И чего я 36 рублей потратил, чтоб съездить к ним, спрашивается..

Я - прощаться, типа увидемся как нить.
Он - мне "а вы типа сильный программист то вообщето?"
Я - хз, пока не жаловались особо
Он - а скажите мне, если вы нормальный прораммист, какая сейчас максимальная частота процессора? Памяти?
Я - хз. А нафига?
Он - это хороший программист обязан знать!
Я - прощаться, типа не, не увидемся, 100%..

Мораль - иногда сами не знают что хотят. И лучшее -  время свое не тратить.

12 ©   (05.04.10 09:18) [35]

Таких элементарных вещей не знаешь, как с тобой после этого разговаривать

>12 ©   (05.04.10 09:18) [35]

Мораль - иногда сами не знают что хотят. И лучшее -  время свое не тратить.

99% "не знают, что хотят"
мораль: умей объяснить. а после того, как объяснишь, самому понятнее станет -  оно и к лучшему.

> Мораль - иногда сами не знают что хотят. И лучшее -  время
> свое не тратить.


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

>Jeer ©   (05.04.10 22:33) [38]
>Когда дойдешь до того, что будешь объяснять им как они должны работать >и они будут слушаться, вот тогда и начинай программировать.
>Не раньше.

Речь не мальчика, но мужа
:)

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

> sniknik ©   (05.04.10 23:42) [40]
>
> "нарвешься" на одного дебила который "хочу чтобы по моему"
> чисто из принципа, и крест на карьере...
>

http://pda.delphimaster.net/?id=1265588356&n=3
[27] [33] [34]

И чего вы на парня набросились?

> [0] Andrey2025   (02.04.10 23:29)

Ты так и не озвучил ответ на
> [2] Кщд ©   (03.04.10 10:00)

Документооботот до 5000 расходных накладных в месяц по 20-30 позиций. Отпуск с 3-х складов (с двух в основном). Присутствует складское перемещение, перепроведение задним числом, сторно. Партионный учет не ведется, считается по среднемесячной. Бывает, товар отпускается, раньше чем приходуется, но это не суть важно. Можно либо не контролировать остатки при отпуске, либо вводить фиктивный приход. Оплата через банк, кассу, взаимозачеты.
Вообще, тема расчета, хранения  остатков, очень наболевшая. Недавно просветился, что есть топики уже по нескольку страниц. И про таблицы для хранения промежуточных и текущих итогов, и про то, что мне пока не понять. В общем, однозначного ответа никто и не даст.

Дети Ивана Кулибина

> В общем, однозначного ответа никто и не даст.

Да в общем то наверное да. Тем более рабочий вариант ломать - трижды подумать надо.
Попробуй склонировать БД и проверить ходовые запросы на более-менее реальных объемах. Сразу и понятно будет.

>Andrey2025   (06.04.10 13:57) [43]
>Документооботот до 5000 расходных накладных в месяц по 20-30 позиций. Отпуск с 3-х складов (с двух в основном). Присутствует складское перемещение, перепроведение задним числом, сторно. Партионный учет не ведется, считается по среднемесячной. Бывает, товар отпускается, раньше чем приходуется, но это не суть важно. Можно либо не контролировать остатки при отпуске, либо вводить фиктивный приход. Оплата через банк, кассу, взаимозачеты.
Вообще, тема расчета, хранения  остатков, очень наболевшая. Недавно просветился, что есть топики уже по нескольку страниц. И про таблицы для хранения промежуточных и текущих итогов, и про то, что мне пока не понять. В общем, однозначного ответа никто и не даст.

Вот уж, бином Ньютона:
Мелкий опт, продукты питания, куча менеджеров, в меру (а иногда и нет) ворующих, вовсю  юзается "серый" нал. Хозяин считает бабло "плюс-минус тыща", главбух либо его жена (любовница), либо регулярно новый

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

> [46] MsGuns ©   (06.04.10 21:21)

Но как вы узнали все это, Холмс?!!! (с) д-р Ватсон.
8-)

Илиментарно, Ватсон !

>до 5000 расходных накладных в месяц по 20-30 позиций.

99% жрачка. Самый ходовый товар. Причем рынок изобилует ИТД и ЧП, работающими, как правило, с наликом

>Отпуск с 3-х складов (с двух в основном). Присутствует складское перемещение, перепроведение >задним числом, сторно. Партионный учет не ведется, считается по среднемесячной.

Магазинов нет, товар отпускается непосредствненно со складов, причем расчет часто на месте
Характерен также переезд товара из склада на склад.
Впрочем, возможны торговые киоски (лотки на рынке). Там учет товара ессно по общей сумме

>Бывает, товар отпускается, раньше чем приходуется, но это не суть важно. Можно либо не >контролировать остатки при отпуске, либо вводить фиктивный приход

Товар может поступать в киоски непосредственно от производителя, минуя склад (туда потом только накладные доставляют, причем с существенным опозданием) Например - хлебобулочная продукция или пиво.
Хорошая среда для воровства, причем бороться с ним бессмысленно.

>Вообще, тема расчета, хранения  остатков, очень наболевшая.

А вот это самый цимус ! Поскольку остатки фактические - это "парафия" завскладом (киоскерши), "компьютеризировать" их учет нереально. Хотя бы потому, что на каждую точку комп не установишь (особенно на те, которые на колесах - т.н. выездная торговля, вовсю процветающая на периферии). Да и на складе внедрить комп/учет очень затруднительно из-за пресловутого "человеческого фактора" :) Поэтому-то и ведутся товарные книги, куда пишутся "красивые" циферки. Ессно, все ручками. Шариковыми :)

> MsGuns  (07.04.2010 10:57:48)  [48]

Полиграф Полиграфовичами

Тут смотрю даже и на счет работодателей разговор зашел. Особо добивает то, что зачастую о конкретных задачах с тобой начинают разговаривать после теста на IQ. Каждому свое.

> Andrey2025   (07.04.10 18:27) [50]

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

>Германн ©   (08.04.10 01:28) [51]
>Может кто-то решал. Может кто-то и решил

Решал.
И не раз.
Но не решил
:)

> Но не решил
> :)
>

Не ты один.
Не только такую задачу.

> Германн  (08.04.2010 02:20:53)  [53]

Вы приговор подписываете.