---|Ветка была без названия|---

← →
passm (2002-10-18 12:42) [40]

Jeer © (18.10.02 12:12)> Таким образом приходим к процедуре закрытия отчетного периода.
MsGuns © (18.10.02 11:46)> Насколько я понял предлагается выдергивать информацию о товарном остатке из журналов прихода/расхода. Если так, то это, ИМХО, не долговечно - понятно почему не приветствуешь большие таблицы.
Просьба не забывать о работе в оффлайн, где, в общем случае, из точек документы могут приходить не по хронологии.
Поддерживаю четырьмя <Digitman © (17.10.02 11:01)> и <Jeer © (18.10.02 12:12)>

← →
Alexandr (2002-10-18 12:42) [41]

ну шо вы спорите?
Подход Digitman ориентирован на клиент-серверные базы данных. И там при таком подходе тормозов при получении оперативного остатка на текущий момент не будет, и быстродействие выборки остатка будет максимальным практически независимо от количества пользователей.
Подход MSGuns ориентирован на FoxPro и другие файл-серверные базы данных, где действительно очень тяжело получать оперативный остаток в отдельной таблице (и при сетевой версии с большим количеством пользователей уходит в тупик, как он и говорит).

Так что оба правы, т.к. все зависит от специфики применения подхода и средств для осуществления.

← →
MsGuns (2002-10-18 12:47) [42]

>Johnmen © (18.10.02 12:15)

Итак, выясняется, что учет фактический в любой момент времени ОТЛИЧАЕТСЯ от учета "На бумаге" (или в компе, что в данном случае одно и то же)

Довод 1.
При занесении данных в учет (компьютер или бумага) тот, кто это делает, НЕ ВИДИТ товара и заносит его по накладной. Выясняется это не сразу, а чуть погодя, и приводит к КОРРЕКЦИИ учетного (компьютерного) документа уже с поправкой информации кладовщика.
(Например, по накладной покупателю отпустили шоколад "Аленка", а он ЧАСТЬ взял "Славутич" по той же цене).
Т.е. фактически товар перевыдается (по компьютеру) Но у нас есть только:
1. Остаток на карточке (условный, как я показал ранее)
2. Количество расхода по накладной НОВОЕ, написанное на бумажке кладовщиком (или тем, кто товар отгружал со склада). Пусть даже есть старое количество, все равно возникает конкретная путаница, ПОТОМУ ЧТО ОСТАТОК на карточке определяется не пересуммировкой всех записей по позиции, а простым сложением-вычитанием абстрактного числа с новым/старым кол-вом по накладной.

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

Довод 2.
Возврат товара. Покупатель, недовольный качеством части приобретенного НЕДЕЛЮ назад товара, возвращает его с требованием замены. На складе, допустим, уже нет этого товара (на остатке 0),
находим в компе его накладную недельной давности (при условии, что он ее прихватил с собою,- для мелкого опта и тем более розницы это маловероятно). Теперь в найденной накладной надо исправить кол-во выдать с, допустим 10, на 5, а вместо него выписать другой в количестве 5. Т.е. надо "откатить всю старую накладную, поправить ее, а потом закоммитить с подсчетом нового остатка. При одновременно выполняемых хотя бы на двую компах подобных операциях Вы неизбежно получите НЕВЕРНЫЙ остаток. На одном компе будет то же самое, например, при вырубании э/сети.

Если МОИ доводы показались интересными или тем более убедительными, продолжу.

← →
Johnmen (2002-10-18 12:55) [43]

>MsGuns © (18.10.02 12:47)

>Довод 1.

Не понял...

>Довод 2.

Ничего подобного !

Жду продолжения...:)

← →
Alexandr (2002-10-18 13:00) [44]

твои доводы безусловно интересны и убедительны, но показывают они недостатки FoxPro и других файловых баз данных.
Для них с твоими утверждениями я согласен на 100%.

Однако если рассматривать клиент-серверную базу данных (боюсь показаться навязчивым, но Interbase например), так вот там эти проблемы очень просто решаются.
Примерно так
1) Таблица приходных накладных
2) таблица расходных накладных
3) Таблица текущих остатков
4) Триггеры на первых двух таблицах, автоматически инкрементно меняющие количество в таблице остатков.
5) Таблица остатков таким образом меняется только сервером, пользователи к ней напрямую доступа не имеют
6) При выводе текущих остатков показывается таблица текущих остатков, поскольку продавцам пофигу от кого, сколько раз и почем приходил товар, но при необходимости они могут посмотреть выборку из первых двух таблиц по конкретной позиции
7) нормально реализованные механизмы транзакций обеспечивают целостность данных, несмотря на зависания, падения и шаловливые ручки.

Проблемы?

← →
passm (2002-10-18 13:05) [45]

Johnmen © (18.10.02 12:55)> Предполагается, что менеджер выписывает какое-то количество товара, но уже на складе кладовщик выдает другое (количество/содержание).
MsGuns © (18.10.02 12:47)> Для этого вводятся в таблицу накладных выписанное количество и фактическое количество.
MsGuns © (18.10.02 12:47)> <Довод 2.> Для этого есть документ "Возврат от покупателя".
Неверный остаток при технологии клиент/сервер с применением триггеров просто невозможен :)

← →
Jeer (2002-10-18 13:06) [46]

>MsGuns © (18.10.02 12:47)
Уважаемый, не месите тесто из глины и муки.
1.При чем здесь пересортица ?
Если работа организована не верно, то никакой сервер не спасет.

2.Разве кто-то утверждал здесь, что все валиться в одну таблицу остатков ? Не припомню.
На самом деле все сводиться к выбору наиболее эффективного интервала сворачивания остатков.
Не фиксировать ДОКУМЕНТЫ вообще - это вроде как бред, по моему.
3. В целях оперативного представления информации допустимо формирование промежуточной таблицы остатков. Но ! Смотря для кого и для чего. Менеджер может руководствоваться этой таблицой, но формирование отгрузки делается НЕ ПО НЕЙ ! И менеджер будет поставлен в известность о рассогласовании (уведомлением и/или количеством в документе)
4. Возврат делается возвратными накладными, а не правкой кол-ва. Это азбука..

← →
Alexandr (2002-10-18 13:08) [47]

люди!!!!!!!!
меня вообще видно?

← →
MsGuns (2002-10-18 13:08) [48]

>Alexandr © (18.10.02 12:42)

Блин, прочитал и задумался..

Надо уточнить один очень маленький, но очень ВАЖНЫЙ нюанс.
Я в принципе не против ФИЗИЧЕСКОГО хранения оперативного остатка, но я против ОТСУТСТВИЯ хранения информации о движении товара собственно в данных об этом товаре, т.е.нормальной картотеки ! Хранение самих накладных как таблицы (таблиц) накладных или как элементов таблиц картотеки не играет особой роли и, действительно, зависит от возможностей конкретного СУБД.
И я ПРОТИВ определения остатка товара как арифм.операции между <остаток до> и <кол-во по накладной>, отстаивая концепцию его определения как сумму по ВСЕМУ движению по товару, начиная с первой, сальдовой записи, которая действительно замещает все движение ДО при архивации "старого" и удалении его из рабочей БД

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

Товарищ, "породивший" ветку, судя по всему, работает на на "Газпром", и не на крупный банк с разветвленными сетями и модерн-технологиями, вот поэтому и затеялся спорить с Digitman

← →
Jeer (2002-10-18 13:10) [49]

>Alexandr © (18.10.02 13:00)
>passm © (18.10.02 13:05)
Вот и подтверждение

← →
MsGuns (2002-10-18 13:14) [50]

>Товарищ, "породивший" ветку, судя по всему, работает на на "Газпром", и не на крупный банк

Следует читать
Товарищ, "породивший" ветку, судя по всему, работает не на на "Газпром", и не на крупный банк

Johnmen © (18.10.02 12:55)
>MsGuns © (18.10.02 12:47)
>Довод 1.

>Не понял...

А я не понял, чего Вы не поняли..

>Довод 2.
>Ничего подобного !

К чему относится, к доводу 2 или к тому что это интересно ?

Жду продолжения...:)

А стОит ли ? У меня такое ощущение, что меня хотят выставить на посмешище.

← →
Jeer (2002-10-18 13:19) [51]

>что меня хотят выставить на посмешище
Нет, не так.
Просто технология разработки FS и CS разняться.

Поэтому и возникает разное отношение.
Для мелких проектов (200-300 тыс записей), 50-60 таблиц я использую типичный файл-сервер DBISAM, но правда исключительно в режиме SQL. Это приходиться учитывать при проектировании.

← →
Johnmen (2002-10-18 13:20) [52]

>Alexandr © (18.10.02 13:00)

1.
2.
...

Именно так !

← →
Alexandr (2002-10-18 13:22) [53]

> Блин, прочитал и задумался..

всегда есть над чем подумать...

> Надо уточнить один очень маленький, но очень ВАЖНЫЙ нюанс.
> Я в принципе не против ФИЗИЧЕСКОГО хранения оперативного
> остатка, но я против ОТСУТСТВИЯ хранения информации о движении
> товара собственно в данных об этом товаре, т.е.нормальной
> картотеки ! Хранение самих накладных как таблицы (таблиц)
> накладных или как элементов таблиц картотеки не играет особой
> роли и, действительно, зависит от возможностей конкретного
> СУБД.

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

> И я ПРОТИВ определения остатка товара как арифм.операции
> между <остаток до> и <кол-во по накладной>, отстаивая концепцию
> его определения как сумму по ВСЕМУ движению по товару, начиная
> с первой, сальдовой записи, которая действительно замещает
> все движение ДО при архивации "старого" и удалении его из
> рабочей БД

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

>

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

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

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

А потом, когда я им покажу возможности своих программ, они тебя помидорами закидают.
Все познается в сравнении.

Сорри, что местами был излишне резок. Но таков тут общий стиль обсуждения.

← →
Johnmen (2002-10-18 13:27) [54]

>MsGuns © (18.10.02 13:14)
>У меня такое ощущение, что меня хотят выставить на посмешище.

Это неверное ощущение !
Мне очень интересно, что думают и как делают другие !

← →
Alexandr (2002-10-18 13:30) [55]

2Johnmen: у него типичный подход программиста на парадоксе, фоксе и прочем 1с.
Не обращай на таких внимание - они скоро вымрут как класс, не выдержав напора современных технологий.

← →
MsGuns (2002-10-18 13:33) [56]

>Alexandr >Jeer

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

← →
MsGuns (2002-10-18 13:34) [57]

>Alexandr >Jeer

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

PS Как это ни смешно, но к сабжу эта дискуссия относится весьма косвенно 9;)))

← →
Alexandr (2002-10-18 13:37) [58]

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

← →
MsGuns (2002-10-18 13:47) [59]

>Alexandr © (18.10.02 13:37)
>Или весь этот разговор прошел впустую?

См.пост MsGuns © (18.10.02 13:34) и не надо видеть сарказм там, где им и не пахнет.

Насчет "Вымрут как класс". Не дождетесь ! Ты не смотри, что мы худые и кашляем 8)). Дай срок, молодец, и

-Не пройдет и полгода,
и я возвращусь..

.. но не для того, чтобы "снова уйти на полгода"

← →
Alexandr (2002-10-18 13:50) [60]

по-моему, мои проповеди возымели действие...
радостно.

← →
MsGuns (2002-10-18 14:02) [61]

← →
Mike Kouzmine (2002-10-18 15:06) [62]

>2Johnmen: у него типичный подход программиста на парадоксе, >фоксе и прочем 1с.
>Не обращай на таких внимание - они скоро вымрут как класс, не >выдержав напора современных технологий.

Странное утверждение, по меньшей мере. Сейчас, волею судьбы, я работаю с парадоксом, на пред. работе - клипперная база и Оракл, не писал, но читал, в году 96, 97 - Интербейз. Завтра скажут на DB2 - пересяду без проблем. Скажут перейти на другой язык - без проблем. О каких программистах Вы говорите? А база на парадоксе - идет обкатка идей (за два месяца сделан полный макет), как работа будет принята - переделаю на интербейз или иже с ними.
А Ганс может быть и прав, хотя у меня работает по другому.

---|Ветка была без названия|--- Найти похожие ветки