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

← →
Dmitry1 (2002-10-16 13:58) [0]

Кто нибудь может посоветовать где можно посмотреть реализацию метода списания товара по FIFO.

← →
Mike Kouzmine (2002-10-16 14:00) [1]

А что там смотреть? Первым пришел - первым ушел. :)

← →
Dmitry1 (2002-10-16 14:07) [2]

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

← →
Mike Kouzmine (2002-10-16 14:15) [3]

По дате.
А что значит откатываться?
Смотршь по номеру, складу и группе, какие были приходы, первая запись соответствует самому первому приходу, следующая - следующий и т.д. (сортировка по убыванию и , естественно, по дате в том числе)

← →
AndreyAG (2002-10-16 14:27) [4]

В таблице приходов каждуую поставку товара делай уникальной по данному товару и после полной продажи товара освобождай поле индекса.

← →
Dmitry1 (2002-10-16 14:28) [5]

откатыватся - допустим накладную перевели в статус продано (поставили галочку), клиент отказался от товара тогда эту накладную переводят в статус выписано. соответственно товар вернули на логический склад.

так вот я и хочу посмотреть как это другие реализовывают на уровне таблиц. возможно ли при этом использовать SQL или самому по таблицам бегать?

← →
Dmitry1 (2002-10-16 14:30) [6]

а если мне необходимо продать товар из разных поставок?

← →
Александр Спелицин (2002-10-16 15:10) [7]

>>а если мне необходимо продать товар из разных поставок...
то это уже не FIFO

← →
Dmitry1 (2002-10-16 15:28) [8]

почему не FIFO ведь возможна же ситуация есть 2 прихода с суммарным количеством товара = "а" и один расход с количеством "а"

← →
Mike Kouzmine (2002-10-16 15:34) [9]

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

← →
Dmitry1 (2002-10-16 16:11) [10]

вот я и прошу примерчик. чтобы посмотреть как другие это делают.
неужто никто не делал такие вещи.

← →
Polevi (2002-10-16 17:26) [11]

есть таблица остатков товара
ТоварID ПриходID Колво

таблица содержимого счета ТСС
СчетID ТоварID Колво

расширенная таблица содержимого счета РТСС
СчетID ТоварID ПриходID Колво

юзер вводит данные в ТСС
при переводе счета в состояние, изменяющее остатки (у меня называеться СПИСАН) создаем курсор на таблице остатков и курсор на ТСС и добавляем записи в РТСС, вычитая из остатков, то есть одна строка
товар №1 100 штук в ТТС
может превратиться в 3 строки в РТСС
товар№1 20 приход1
товар№1 50 приход2
товар№1 30 приход3

при переводе счета в обратном направлении, количества из РТСС прибавляются к таблице остатков а строки из РТСС удаляются

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

← →
MsGuns (2002-10-16 18:00) [12]

Поверь старому складушнику-бухгалтерщику. Метод списания (расхода) по принципу давности хранения для ТОВАРОВ неприменим.
Когда бухи или кладовщики этого требуют, они не представляют себе все последствия их "экономичности" при работе с программой складского учета.

Я его применял много раз, но потом переделывал на полуручной или вообще выкидывал на фиг.

Кстати, на тему обязательного заведения новой карточки на каждом приходе товара. Это мог посоветовать только свистун (пардон, я так называю 1С-ников), у которого остатки "сбрасываются" не реже раза в месяц. Совершенно тухлая технология. Кроме того есть товар, МНОГОКРАТНО приходящий не только в течении месяца, а даже дня. Хлеб, молоко, например. И что же , если молока за день пришло по бидону 15 раз (часто даже с одного молокозавода), мне что, прикажете держать 15 позиций на складе ? Чушь собачья.

← →
Digitman (2002-10-16 18:05) [13]

должна быть таблица, фиксирующая акты движения по складу.

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

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

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

← →
petr_v_a (2002-10-16 18:27) [14]

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

← →
MsGuns (2002-10-16 22:08) [15]

>Digitman © (16.10.02 18:05)

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

Извините, если чем-то обидел.

С уважением. Примите и проч.

← →
Zlob (2002-10-17 08:35) [16]

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

← →
Наталия (2002-10-17 09:46) [17]

>MsGuns © (16.10.02 22:08)
На мой взгляд, Вы не правы, категорически отрицая необходимость таблицы ОСТАТКОВ товаров, так как при вычислении остатков по даблице ДВИЖЕНИЯ товаров на текущий момент это может занимать слишком много ресурсов при больших базах. А при изменении какой-либо позиции в ДВИЖЕНИИ (Digitman под актами движения подразумевал как раз то, что Вы называете "накладные" - не суть важно) триггер автоматически изменяет запись в таблице ОСТАТКИ. Этим достигается бОльшая скорость при работе со списком товара.

← →
Digitman (2002-10-17 10:54) [18]

> не могу сказать, что предмет (торговля) Вы знаете неважно.

Не можешь сказать, что "неважно" - не говори)

Схема сия взята из софта, который достаточно успешно существовал и работал задолго до того, как появился 1С - это сетевой торг.-бухг.комплекс Lanx Supermanager. А "умер" в основном из-за ограничений, которые вносила изначально задействованная в пакете СУБД FoxPro (и даже перенос ядра на MSSQL не дал полного разрешения проблем мультиклиентского доступа)

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

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

← →
Digitman (2002-10-17 10:58) [19]

Еще раз хочу подчеркнуть - приведенная схема далеко не самая худшая :

- справочник оперативного состояния складов (что, где, сколько, на какую сумму, и на основании какого акта) по каждой номенкл.тов.единице изменяется как результат отработки механизма фиксации/уничтожения актов в таблице движения по складам; объект, отражающий оперативное состояние складов, позволяет в любой точке корп.сети для любой цели мгновенно получить инф-цию о наличии товаров (своего рода - snapshot), дате постановки на учет и их количественных/ценовых характеристиках;

- акты тов.движения (обзови их как угодно, но все они имеют как минимум знак : "+" для приходных и "-" для расходных актов любого субтипа) формируются/уничтожаются на основании оприходования/расприходования(если угодно - отката) тов.документов - накладных; в зависимости от типа документа-накладной по каждой ее позиции в результате транзакции формируется/уничтожается один или более актов движения, на основании которых изменяется snapshot складов; в любой момент времени на любую интересующую дату на основании выбоки записей-актов можно получить любой отчет - те самые оборотки/сальдовки и иже с ними; запросы такие, разумеется, более тяжелые и длительные, но ведь и преследуют они иную задачу - дать состояние товара в динамике ! snapshot же складов дает статику и цель его - дать именно оперативные, самые свежие данные о состоянии интересующей номенклатуры, поставленной на учет в интересующий момент времени;

← →
Digitman (2002-10-17 11:01) [20]

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

- реальные учетные данные (по каждой номенкл.единице в приходуемом/расприходуемом документе) меняются и объявляются достоверными/недостоверными лишь в результате успешного выполнения транзакции в рамках операции оприходования/расприходования документа;

- после оприходования документ нельзя ни удалять ни модифицировать - он является основанием для проведенной складской операции, в результате которой сформированы акты соотв.движения по каждой номенкл.единице в документе для каждого фигурирующего в док-те склада, а также модифицированы соотв.элементы оперативного состояния склада/складов;

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

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

в результате :

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

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

Теперь - собственно по изнач.вопросу

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

← →
Digitman (2002-10-17 11:03) [21]

При реализации FIFO в момент оприходования док-та на расход/списание snapshot складов, упорядоченный по возрастанию даты и количеству(иногда - себестоимости), по каждой позиции в спецификации док-та сканируется на предмет локализации записей, удовлетв. условиям расхода/списания. Приходные акты движения, на которые ссылаются найденные записи, становятся первичными up-ссылками при формировании соотв.расходных актов. После формирования расх.актов локализованные записи в snapshot"е корректируются (либо уничтожаются, если расх.акт вычерпывает весь остаток от поставки). В конечном итоге документ помечается как оприходованный и транзакция подтверждается.

Расприходование (откат) документа на расход/списание ведет к следующему :
- стартует транзакция,
- по каждому эл-ту спецификации док-та локализуется акт (либо группа актов) движения,
- по up-ссылкам локализуются первичные приходные акты (возможно - в цикле до up = nil),
- в snapshot"е локализуются записи со ссылками на найденные акты поставки, если найдены - корректируются (инкремент), если не найдены - воссоздаются со ссылками на локализованные первичные акты поставки

Вот , собствено, и вся "кухня")... Как ни обзови ее "потроха", но она отвечает на вопрос

← →
MsGuns (2002-10-17 11:16) [22]

>Наталия © (17.10.02 09:46)

1. Хранить готовые остатки. Я так раньше и делал, но при необходимости иметь "горячие" остатки, (т.е. когда один оператор выписал "молока" 6 л, а другой через СЕКУНДУ должен видеть уже оставшееся кол-во) надо постоянно автоматически править отот остаток в некой таблице (условно назовем ее "Таблица остатков").При этом сам механизм (триггер или локал-процедура) по большому счету роли не играет. Вот и получается, что эта "Таблица остатков" при активной работе нескольких операторов перманентно в режиме Edit. Т.к. мои таблы были в основном на Paradox, все это при нестабильности питания регулярно "выбивало" таблицу остатков. В конце-концов я вообще отказался от ее существования.

2.Большая скорость.
Как раз наоборот ! Т.к. движение линкуется к позиции через внешние ключи (Master-Detail), то курсор ДВИЖЕНИЯ имеет не более 100 записей (одна позиция редко движентся более 20-30 раз, но бывает и до сотни), просчет суммы по ОДНОЙ колонке времени занимает мизер. В отличие от времени, затрачиваемого при записи в таблицу остатков, которая правктически всегда "под напряжением".

Впрочем, это относится к БД с весьма интенсивным базовым трафиком. Для средних и мелких фирм такая проблема обычно не стоит

← →
MsGuns (2002-10-17 11:48) [23]

>Digitman © (17.10.02 10:54) и все последующие..

На "ты", так на "ты".
Во-первых, я хотел сказать, что ты не очень разбираешься в предмете ТОРГОВЛИ (там просто лишняя частица "не"), и все твои последующие посты лишь подтверждение этому.
Да, в умении заумно и наукообразно выражать простые мысли тебе отказать трудно. Видно, что книжек начитался да и опыт работы в Клиент-Сервере немалый (чего не могу сказать о себе). Сочувствую тем непрограммистам, которые имеют несчастье общаться с тобой в качестве лохов-бухгалтеров. Однако умение закладывать крутые виражи не очень-то нужно при первозках крупнотоннажных грузов. Та схема, что ты так настойчиво отстаиваешь, является надежной только при малых нагрузках на БД.
Когда одновременно :
-5 операторов выписывают счета или накладные
-2 товароведа заводят приходы
-6-7 менеджеров просматривают остатки на предмет составления заявок на допоставку товара
-2-3 бухгалтера "правят" документы прошлого месяца
-кладовщики делают пересортицу
эта схема с транзакциями лопнет по швам или на ее поддержку надо будет ставить что-то типа Оракла на счетверенном пне-IV, класть оптоволокно и т.д. Иначе или все будут безбожно тормозить или остатки будут так же безбожно врать.

Не буду тебе доказывать свою правоту по причине полной безнадеги. Для того, чтобы это понять, надо не работать 5 лет с готовой программой, а самому написать хотя бы с пяток подобных проектов, а потом их посопровождать лет эдак по 5, да в РАЗНЫХ по специфике и объемах фирмах.

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

Мне очень жаль, что мое скромное замечание в твой адрес вызвало такую бурную реакцию, не думал, что "голубые" могут быть так самолюбивы и не терпят малейшей критики. Бери пример с того же Зотова - человек не боится сказать, что он ОЧЕНЬ МНОГО НЕ ЗНАЕТ !
И ничего ! После этого его авторитет нисколько не пострадал, наоборот вырос (например, для меня)

← →
Наталия (2002-10-17 12:03) [24]

MsGuns © (17.10.02 11:16)
1. Да хоть пять операций в одну секунду - на клиенте сделать DataSet.Refresh для одной позиции - c сервера вытягивается одна строка. (например в таблице ОСТАТКИ 5тыс.позиций) Чтобы лишнее не списали - механизм исключений.
2. Чтобы получить остаток из таблицы ДВИЖЕНИЕ (например 1 млн.записей) надо сделать select sum(кол-во) для конкретной позиции. Сервер конечно,посчитает, но всё-таки это будет медленнее.

← →
MsGuns (2002-10-17 12:24) [25]

>Наталия © (17.10.02 12:03)
>2. Чтобы получить остаток из таблицы ДВИЖЕНИЕ (например 1 млн.записей) надо сделать select sum(кол-во) для конкретной позиции. Сервер конечно,посчитает, но всё-таки это будет медленнее.

Вы недостаточно внимательно прочитали мой пост о технологии подкачки движения, где я отметил цифру 100 как макс ПО ОДНОЙ ПОЗИЦИИ. Простой пробег по строкам или агрегатное поле (еще быстрее, т.к.формируется про основном запросе) займет времени меньше, чем тот же пересчет, но с записью в "Таблицу Остатков".
Если же Вы предлагаете остаток считать по простой схеме

[Остаток] = [Остаток] -(+) [Кол-во по строке док-та]

то флаг Вам в руки. Тем более, что так делается в БОЛЬШИНСТВЕ складских программ. Сочувствовал и до сих пор сочувствую тем людям, которые до сих пор работают с подобными технологиями. Вот уж где, действительно, без откатов (о которых так вдохновенно вещал Digitman) не обойтись !
Для локалки или для 2-3 станций это работает, но не более !

← →
Polevi (2002-10-17 12:57) [26]

2MsGuns © (17.10.02 11:16)
у меня в базе 50 тыс счетов и таблица содержимого их содержит милион записей - вы предлагаете каждый раз динамически вычислять остаток по позиции создавая курсор на
SELECT * FROM Contents WHERE GoodID=12345 ???
Одновременно 10-15 операторов добавляют записи
Или я чегото не понял, или будет жуткая тормозня, если все делать по вашему

← →
Digitman (2002-10-17 13:10) [27]

>MsGuns

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

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

>>ты не очень разбираешься в предмете ТОРГОВЛИ
мне это и не требуется) ... ни профессионально ни иначе)

>>программисту наплевать, что хочет пользователь
..или он не программист

>>мое скромное замечание в твой адрес
Ну уж извини, скромным я бы его никак не назвал

>>Сочувствую тем непрограммистам, которые имеют несчастье общаться с тобой в качестве лохов-бухгалтеров

А при чем здесь бухгалтеры ? И тем блоее - лохи ? Разве о бухучете вообще идет речь ? То, как складские операции отражаются (в результате проведения) в чисто бухг.отчетности - совершенно из другой оперы. Будь уж так любезен - не меси в общую кучу подсистемы склада и бухучета)...
Скажи на милость - с каких пор ГНИ (ради чего бухгалтерия и существует в первую очередь) стала интересоваться - FIFO или LIFO уходит изделие/товар ? Произвел/Получил/Продал/Списал/Украл/Заныкал товар - будь любезен, товарищ бухгалтер, заплати/получи бабки и отчитайся как положено, когда, что, сколько, на какую сумму и на каком основании... И привяжи все это, тов.бухгалтер, к установленному плану счетов .. А как это там у тебя (или в твоей конторе), товарищ бухгалтер, организовано физически или как тебе удобней вести внутренний учет товара - по-барабану, это твои проблемы...

>>"голубые"
Это ты о чем, сударь ?

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

>>Бери пример с того же Зотова
Да всенепременно !) Как только <Юрий Зотов> сочтет нужным поучаствовать в дискуссиях и поделиться опытом в разделе "Базы данных", обязательно возьму - не сомневайся даже)

>>человек не боится сказать, что он ОЧЕНЬ МНОГО НЕ ЗНАЕТ !
И оч.правильно делает. Полностью с ним согласен, потому как сам такой)

>>После этого его авторитет нисколько не пострадал, наоборот вырос (например, для меня)

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

P.S.
Думаю, дальнейший треп на эту тему будет неуместен, ибо риск угодить в "Потрепаться" растет в геом.прогрессии)...
Предлагаю закруглиться с публичными упражнениями в демонстрации "крутости"

P.P.S.

Еще раз повторюсь - я всего лишь поделился общеконцептуальными соображениями с автором. Бредовые они или нет, понадобятся ли они ему, заинтересуют ли детали - ему выбирать.

← →
MsGuns (2002-10-17 13:36) [28]

>Digitman © (17.10.02 13:10)
>Предлагаю закруглиться с публичными упражнениями в демонстрации "крутости"

Ну и ладненько q;ь

← →
petr_v_a (2002-10-17 17:06) [29]

> MsGuns вынужден поддержать в чем-то поддержать Digitman © :))
Предлагаемая Вами схема хорошо рабаотает, пока по складам идет 100, ну 300 операций в день и система работает год ну полтора ((: Еще как при ней бороться с таким явлением, как несогласованное чтение?

← →
MsGuns (2002-10-17 19:00) [30]

>petr_v_a © (17.10.02 17:06)

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

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

Меня поразило еще СОВЕРШЕННО СЕРЬЕЗНОЕ заявление весьма уважающего себя человека о том, что СКЛАД и БУХГАЛТЕРИЯ - это абсолютно разные вещи. Тут даже возразить нечего,- язык отнимается. Но спасибо, товарный знак уже знаем.

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

Суть моего "наезда" на Digitman © в том, что я не понял его высоконаучного тона, за которым, ИМХО, часто скрывается некомпетентность. Чего от начал на меня катить бочку я так и не понял, кроме одного: товарищ возмутился какой-то там... . И вообще, я считаю, что если НЕ ЗНАЕШЬ КАК КОНКРЕТНО ПОМОЧЬ товарищу, нечего соваться с умным видом. Если я не шурупю как следует в ООПе, я вообще не высказываюсь в ветках типа API или Система. Наезжать надо по делу, сначала разобравшись в сути критикующего.

А вообще-то я заметил, что хорошим тоном на форуме с некоторых пор стало унижение собеседника, начиная с "тыкания" заведомо более старшему человеку, который к тому же обращается вежливо и на "Вы".

← →
German Ivanov (2002-10-18 03:36) [31]

Гду Вы видели, чтобы в живой фирме правили движение 3-4-х месячной давности

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

Меня поразило еще СОВЕРШЕННО СЕРЬЕЗНОЕ заявление весьма уважающего себя человека о том, что СКЛАД и БУХГАЛТЕРИЯ - это абсолютно разные вещи.

Термин АРМ расшифровывается как автоматизированное рабочее место.
Кладовщик и бухгалтер являются одним и тем-же лицом как правило в небольших конторах. Бизнес логика приложений склада и бухгалтерии совершенно различна. Это база данных у них одна. Протестуя против таблицы с "горячими остатками" вы совершенно упустили из вида что это может быть банальный вид или связанная таблица с вычисляемым полем.

то если НЕ ЗНАЕШЬ КАК КОНКРЕТНО ПОМОЧЬ товарищу, нечего соваться с умным видом

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

начиная с "тыкания" заведомо более старшему человеку

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

← →
German Ivanov (2002-10-18 03:42) [32]

Кстати по моему IMHO таблицы с огромным количеством записей это признак плохо спроектированной базы данных.
Когда мне показывают нечто вроде каталога библиотеки с 10000 записей-наименований , я обычно говорю - "А почему бы Вам было не создать таблицы с именами А,Б...Я и не разложить в них книги по наименованию?" Разумеется пример утрирован, но общая идея на мой взгляд просматривается.

← →
Johnmen (2002-10-18 09:37) [33]

>German Ivanov

Да-а-а-а... Нагнал пурги ! И по поводу БД и по поводу своих наблюдений !
Не потрудившись даже зарегиться...

>MsGuns ©

Согласен с твоими представлениями о прогр-ии и окружающих нас здесь людях...

>Вот уж против чего я возражаю КАТЕГОРИЧЕСКИ, так это вычисление
>остатка как разности(суммы) движимого по док-ту кол-ва и
>старого остатка. Доводов могу привести с десяток, но похоже,
>это мало кому интересно.

А я бы послушал (в смысле, почитал :-))...

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

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

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

У меня тоже немалый опыт написания учетных задач, еще начиная с DBASE II, а также CS.
Дополню постинги следующим: не всегда применение Оракла оправдано технической необходимостью - чаще это способ выйти на другие цены. И совсем не обязательно, что при таких ресурсах будут еще и оптимизацией заниматься.
Тот же, кто прошел "огонь и воды" ранних СУБД, тот и сейчас может с незначительными ресурсами создавать приемлимые по отклику приложения.

← →
MsGuns (2002-10-18 11:27) [35]

>German Ivanov (18.10.02 03:36)
>Гду Вы видели, чтобы в живой фирме правили движение 3-4-х месячной давности
>Если ничего не путаю отчетность сдается раз в пол-года, раз в год.

Отчетность и подделка накладных не суть одно и то же.

>Поэтому вполне возможна ситуация с продолжительным хранением и модификацией остатков(в свете нагрянувшей отчетности).

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

>German Ivanov (18.10.02 03:42)
>Кстати по моему IMHO таблицы с огромным количеством записей это признак плохо спроектированной базы данных.

В точку. Можно цитировать другим

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

А я, собственно говоря, с этого и начал (первый мой пост), выступив катерогически против использования его при списании в ТОРГОВЛЕ. Могу, конечно, пояснить, и даже привести примеры "неудобоваримости" этого метода в чисто алгоритмическом плане и "брехливости" в эксплуатации. Но автор вопроса, похоже, исчез вместе с вопросом. Может быть, испугавшись возникшей здесь свары.

← →
Johnmen (2002-10-18 11:36) [36]

>Johnmen © (18.10.02 09:37)
>>MsGuns ©
>>А я бы послушал (в смысле, почитал :-))...

← →
MsGuns (2002-10-18 11:46) [37]

>Johnmen © (18.10.02 09:37)
>Вот уж против чего я возражаю КАТЕГОРИЧЕСКИ, так это вычисление
>остатка как разности(суммы) движимого по док-ту кол-ва и
>старого остатка. Доводов могу привести с десяток, но похоже,
>это мало кому интересно.

> А я бы послушал (в смысле, почитал :-))...

Да с удовольствием.

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

Т.е. для КАЖДОЙ ПОЗИЦИИ ТОВАРА (кода товара) должно быть столько подобных записей, сколько было документов, по которым он (товар) приходил-уходил.
Т.о. НА КАЖДЫЙ момент времени существующий остаток есть не что иное, как сумма по колонке "Количество" (при условии,что расход вводлися по-красному, т.е. с минусом), который в течение дня может меняться многократно. Здесь речь идет об УЧЕТНОМ кол-ве (сумме), т.е. кол-ве, ЗАФИКСИРОВАННОМ в отчетности. Которое, если быть точным НИКОГДА НЕ СОВПАДАЕТ С ФАКТИЧЕСКИМ НА СКЛАДЕ.
(Товар уже выгружен на склад и принят кладовщиком/товароведом/менеджером, подписан путевой и машина уехала, а запись будет сделана только ВЕЧЕРОМ или НА СЛЕДУЮЩИЙ ДЕНЬ.

Если интересно, буду продолжать

← →
Jeer (2002-10-18 12:12) [38]

> Дата поступления
> Номер накладной
..
Еще ссылка на товар из справочника товара, разумеется.

1.Если это приложение торгово-учетное, то при партионном учете очень полезной бывает средне-приходная цена как
N1*P1+N2*P2+..+N2*P2
--------------------
sum(N1..Ni)

2. Разумеется, если режим работы не онлайн, товар в отчетности расходиться с наличием. Здесь надо правильно организовывать работу.
Товар сначала появляется на складе, потом в отчетности.
Товар сначала уходит из отчетности, затем со склада.
Иначе "дрова ломаются".

← →
Johnmen (2002-10-18 12:15) [39]

>MsGuns ©
>Доводов могу привести с десяток...

Мне интересны именно доводы !
И именно твои !

(А теория и концепции известны ...) :))

← →
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]

← →
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 (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 - пересяду без проблем. Скажут перейти на другой язык - без проблем. О каких программистах Вы говорите? А база на парадоксе - идет обкатка идей (за два месяца сделан полный макет), как работа будет принята - переделаю на интербейз или иже с ними.
А Ганс может быть и прав, хотя у меня работает по другому.

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