| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
---|Ветка была без названия|---
Dmitry1 © (2002-10-16 13:58:00)Кто нибудь может посоветовать где можно посмотреть реализацию метода списания товара по FIFO.
Mike Kouzmine (2002-10-18 15:06:00) [1]>2Johnmen: у него типичный подход программиста на парадоксе, >фоксе и прочем 1с.
>Не обращай на таких внимание - они скоро вымрут как класс, не >выдержав напора современных технологий.
Странное утверждение, по меньшей мере. Сейчас, волею судьбы, я работаю с парадоксом, на пред. работе - клипперная база и Оракл, не писал, но читал, в году 96, 97 - Интербейз. Завтра скажут на DB2 - пересяду без проблем. Скажут перейти на другой язык - без проблем. О каких программистах Вы говорите? А база на парадоксе - идет обкатка идей (за два месяца сделан полный макет), как работа будет принята - переделаю на интербейз или иже с ними.
А Ганс может быть и прав, хотя у меня работает по другому.
MsGuns (2002-10-18 14:02:00) [2]>Alexandr © (18.10.02 13:37)
>Или весь этот разговор прошел впустую?
См.пост MsGuns © (18.10.02 13:34) и не надо видеть сарказм там, где им и не пахнет.
Насчет "Вымрут как класс". Не дождетесь ! Ты не смотри, что мы худые и кашляем 8)). Дай срок, молодец, и
-Не пройдет и полгода,
и я возвращусь..
.. но не для того, чтобы "снова уйти на полгода"
Alexandr (2002-10-18 13:50:00) [3]по-моему, мои проповеди возымели действие...
радостно.
MsGuns (2002-10-18 13:47:00) [4]>Alexandr © (18.10.02 13:37)
>Или весь этот разговор прошел впустую?
См.пост MsGuns © (18.10.02 13:34) и не надо видеть сарказм там, где им и не пахнет.
Насчет "Вымрут как класс". Не дождетесь ! Ты не смотри, что мы худые и кашляем 8)). Дай срок, молодец, и
-Не пройдет и полгода,
и я возвращусь..
.. но не для того, чтобы "снова уйти на полгода"
Alexandr (2002-10-18 13:37:00) [5]пожалуйста, конечно.
Но ты хоть выводы какие-нибудь сделал для себя?
Или весь этот разговор прошел впустую?
MsGuns (2002-10-18 13:34:00) [6]>Alexandr >Jeer
Спорить, действительно, не о чем. Вам же обоим спасибо за весьма полезную для меня дискуссию
PS Как это ни смешно, но к сабжу эта дискуссия относится весьма косвенно 9;)))
MsGuns (2002-10-18 13:33:00) [7]>Alexandr >Jeer
Спорить, действительно, не о чем. Вам же обоим спасибо за весьма полезную для меня дискуссию
Alexandr (2002-10-18 13:30:00) [8]2Johnmen: у него типичный подход программиста на парадоксе, фоксе и прочем 1с.
Не обращай на таких внимание - они скоро вымрут как класс, не выдержав напора современных технологий.
Johnmen (2002-10-18 13:27:00) [9]>MsGuns © (18.10.02 13:14)
>У меня такое ощущение, что меня хотят выставить на посмешище.
Это неверное ощущение !
Мне очень интересно, что думают и как делают другие !
Alexandr (2002-10-18 13:22:00) [10]
> Блин, прочитал и задумался..
всегда есть над чем подумать...
> Надо уточнить один очень маленький, но очень ВАЖНЫЙ нюанс.
> Я в принципе не против ФИЗИЧЕСКОГО хранения оперативного
> остатка, но я против ОТСУТСТВИЯ хранения информации о движении
> товара собственно в данных об этом товаре, т.е.нормальной
> картотеки ! Хранение самих накладных как таблицы (таблиц)
> накладных или как элементов таблиц картотеки не играет особой
> роли и, действительно, зависит от возможностей конкретного
> СУБД.
конечно, партионный учет остается... Куда уж без него.
Таблица оперативных остатков это зеркало, линза через которую лучше видно остатки.
> И я ПРОТИВ определения остатка товара как арифм.операции
> между <остаток до> и <кол-во по накладной>, отстаивая концепцию
> его определения как сумму по ВСЕМУ движению по товару, начиная
> с первой, сальдовой записи, которая действительно замещает
> все движение ДО при архивации "старого" и удалении его из
> рабочей БД
Ну это вы FoxPro с Парадоксом обкурились.
Работали бы вы с нормальными базами данных, такая бы чушь у вас из головы быстро бы повылетала...
>
> И второе. Я почему-то стараюсь ориентироваться на клиентов,
> которые не могут себе позволить высокопроизводительные "твердые"
> и "мягкие" средства для компьютеризации своего хозяйства,
> ориентируясь на дешевые и достаточно быстрые технологии
> (Paradox, например), зная при этом, что хлопот у меня прибавится.
Кто докажет мне, что для сетевого парадокса нужно меньше ресурсов и меньше денежных вложений, чем для Firebird,
и при этом кто на парадоксе получит склад быстрее чем на Firebird при прочих равных условиях, тот пусть первым кинет в меня камень.
> Но мне не безразличны мои клиенты и я знаю, что когда они
> дойдут до современных технологий прежде всего финансово,
> они обра
> тятся за помощью не к кому-нибудь, а в мою фирму.
А потом, когда я им покажу возможности своих программ, они тебя помидорами закидают.
Все познается в сравнении.
Сорри, что местами был излишне резок. Но таков тут общий стиль обсуждения.
Johnmen (2002-10-18 13:20:00) [11]>Alexandr © (18.10.02 13:00)
1.
2.
...
Именно так !
Jeer (2002-10-18 13:19:00) [12]>что меня хотят выставить на посмешище
Нет, не так.
Просто технология разработки FS и CS разняться.
Поэтому и возникает разное отношение.
Для мелких проектов (200-300 тыс записей), 50-60 таблиц я использую типичный файл-сервер DBISAM, но правда исключительно в режиме SQL. Это приходиться учитывать при проектировании.
MsGuns (2002-10-18 13:14:00) [13]>Товарищ, "породивший" ветку, судя по всему, работает на на "Газпром", и не на крупный банк
Следует читать
Товарищ, "породивший" ветку, судя по всему, работает нена на "Газпром", и не на крупный банк
Johnmen © (18.10.02 12:55)
>MsGuns © (18.10.02 12:47)
>Довод 1.
>Не понял...
А я не понял, чего Вы не поняли..
>Довод 2.
>Ничего подобного !
К чему относится, к доводу 2 или к тому что это интересно ?
Жду продолжения...:)
А стОит ли ? У меня такое ощущение, что меня хотят выставить на посмешище.
Jeer (2002-10-18 13:10:00) [14]>Alexandr © (18.10.02 13:00)
>passm © (18.10.02 13:05)
Вот и подтверждение
Alexandr (2002-10-18 13:08:00) [15]люди!!!!!!!!
меня вообще видно?
MsGuns (2002-10-18 13:08:00) [16]>Alexandr © (18.10.02 12:42)
Блин, прочитал и задумался..
Надо уточнить один очень маленький, но очень ВАЖНЫЙ нюанс.
Я в принципе не против ФИЗИЧЕСКОГО хранения оперативного остатка, но я против ОТСУТСТВИЯ хранения информации о движении товара собственно в данных об этом товаре, т.е.нормальной картотеки ! Хранение самих накладных как таблицы (таблиц) накладных или как элементов таблиц картотеки не играет особой роли и, действительно, зависит от возможностей конкретного СУБД.
И я ПРОТИВ определения остатка товара как арифм.операции между <остаток до> и <кол-во по накладной>, отстаивая концепцию его определения как сумму по ВСЕМУ движению по товару, начиная с первой, сальдовой записи, которая действительно замещает все движение ДО при архивации "старого" и удалении его из рабочей БД
И второе. Я почему-то стараюсь ориентироваться на клиентов, которые не могут себе позволить высокопроизводительные "твердые" и "мягкие" средства для компьютеризации своего хозяйства, ориентируясь на дешевые и достаточно быстрые технологии (Paradox, например), зная при этом, что хлопот у меня прибавится.
Но мне не безразличны мои клиенты и я знаю, что когда они дойдут до современных технологий прежде всего финансово, они обра
тятся за помощью не к кому-нибудь, а в мою фирму.
Товарищ, "породивший" ветку, судя по всему, работает на на "Газпром", и не на крупный банк с разветвленными сетями и модерн-технологиями, вот поэтому и затеялся спорить с Digitman
Jeer (2002-10-18 13:06:00) [17]>MsGuns © (18.10.02 12:47)
Уважаемый, не месите тесто из глины и муки.
1.При чем здесь пересортица ?
Если работа организована не верно, то никакой сервер не спасет.
2.Разве кто-то утверждал здесь, что все валиться в одну таблицу остатков ? Не припомню.
На самом деле все сводиться к выбору наиболее эффективного интервала сворачивания остатков.
Не фиксировать ДОКУМЕНТЫ вообще - это вроде как бред, по моему.
3. В целях оперативного представления информации допустимо формирование промежуточной таблицы остатков. Но ! Смотря для кого и для чего. Менеджер может руководствоваться этой таблицой, но формирование отгрузки делается НЕ ПО НЕЙ ! И менеджер будет поставлен в известность о рассогласовании (уведомлением и/или количеством в документе)
4. Возврат делается возвратными накладными, а не правкой кол-ва. Это азбука..
passm (2002-10-18 13:05:00) [18]Johnmen © (18.10.02 12:55)> Предполагается, что менеджер выписывает какое-то количество товара, но уже на складе кладовщик выдает другое (количество/содержание).
MsGuns © (18.10.02 12:47)> Для этого вводятся в таблицу накладных выписанное количество и фактическое количество.
MsGuns © (18.10.02 12:47)> <Довод 2.> Для этого есть документ "Возврат от покупателя".
Неверный остаток при технологии клиент/сервер с применением триггеров просто невозможен :)
Alexandr (2002-10-18 13:00:00) [19]твои доводы безусловно интересны и убедительны, но показывают они недостатки FoxPro и других файловых баз данных.
Для них с твоими утверждениями я согласен на 100%.
Однако если рассматривать клиент-серверную базу данных (боюсь показаться навязчивым, но Interbase например), так вот там эти проблемы очень просто решаются.
Примерно так
1) Таблица приходных накладных
2) таблица расходных накладных
3) Таблица текущих остатков
4) Триггеры на первых двух таблицах, автоматически инкрементно меняющие количество в таблице остатков.
5) Таблица остатков таким образом меняется только сервером, пользователи к ней напрямую доступа не имеют
6) При выводе текущих остатков показывается таблица текущих остатков, поскольку продавцам пофигу от кого, сколько раз и почем приходил товар, но при необходимости они могут посмотреть выборку из первых двух таблиц по конкретной позиции
7) нормально реализованные механизмы транзакций обеспечивают целостность данных, несмотря на зависания, падения и шаловливые ручки.
Проблемы?
Johnmen (2002-10-18 12:55:00) [20]>MsGuns © (18.10.02 12:47)
>Довод 1.
Не понял...
>Довод 2.
Ничего подобного !
Жду продолжения...:)
| |
Страницы: 