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

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