powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / такой большой проект у меня в первые
55 сообщений из 55, показаны все 3 страниц
такой большой проект у меня в первые
    #34081725
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Приветсвую всех,
Партионный учет - именно это мне и нужно. Читал сдесь разные способы но они маленько не подходят для решения моей задачи или я может их не понял. Стандартно есть кучя филиалов с куча складов в каждый филиал. Кроме того надо вести учет опльзователей и их действия. С этим я разобрался, но вот что я некак не могу понять это как сделать приход, расход, перемищение со склада на склад, и конечно заказы. И проблема вот в чем.

Приход товаров заноситься в таблицу которая одинакова по структуре с таблицой расхода товара с маленькой разнице: приход - поставщик, расход - покупатель. А все остальное одинакавое.

Вопрос 1: Разделить в одельние таблицы приход и расход или это сделать в одну таблицу скажем операции с неким статусом операции?
Вопрос 2: Как организовать перемищение товара?
Вопрос 3: А заказы хранить в таблице приход или для этого дела надо сделать одельная таблица заказы?

Буду очень рад если присоиденитесь к беседе. БД на MSSql Server 2000. Должен признаться такой большой проект у меня в первые. На рисунке думаю будет понятнее.

Спосибо всем,
с уважением Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34081842
Jedaito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
К названиям полей надо спереди дописывать не только имя таблицы, но и имя базы. и на всякий случай имя сервера.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34082327
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если упустить такие пикантные подробности,что таблички поставщиков и пользователей сильно денормализованы, то на самый первый взгляд видны следующие недочеты (это если делать нормальную складскую учетную модель,хотя как всегда на форуме описание задачи никакое):
1.приход осуществляется не от поставщика,а от склада поставщика (это вам несомненно понадобится например для анализа с какого склада поставщика больше приходит брака :))
2.следует различать понятия "планируемый приход" и фактический. По факту абсолютно реальная ситуация: заказывается 10 единиц товара 1 на склад 2 со склада 15 поставщика, привезут само собой 5 единиц товара 1, 3 единицы товара 2 на склад 1 и 2 единицы товара 1 на склад 1 причем со складов 4 и 9 поставщика. можно его конечно послать,но факт маразма должен быть зарегистрирован и учет того что привезли тоже должен быть, ведь руководство может и решить:ладно,хрен с ним,пусть лежит товар на 2-х складах.
3.таблица заказа должна быть несомненно отдельная,так как в ней может быть много разных товаров раскиданных по разным складам и по приходам вы их в кучу не соберете.

P.S. Я бы как всегда порекомендовал бы слить в одну кучу и склады и пользователей и поставщиков, сделать между ними роли и "отношения",так как это потенциально в будущем поможет избежать море проблем.Собственно это и решит проблему перемещения между складами- это такой же приход/расход объекта учета между субъектами учета.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34082464
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CLilianВопрос 1: Разделить в одельние таблицы приход и расход или это сделать в одну таблицу скажем операции с неким статусом операции?
Одну таблицу.

CLilianВопрос 2: Как организовать перемищение товара?
Должна быть не одна ссылка на склад, а две, на склад-источник и на склад-приемник.

CLilianВопрос 3: А заказы хранить в таблице приход или для этого дела надо сделать одельная таблица заказы?
Уже было очень много копий сломано насчет хранения заголовков документов в одной или нескольких таблицах. В вашем случае на порядок проще будет реально хранить все в одной таблице, и не различать контрагентов и склады.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34082519
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To Сергей: подскажите,а на чем основывается " В вашем случае на порядок проще будет реально хранить все в одной таблице, и не различать контрагентов и склады.". ПМСМ при данной постановке задачи неясно ничего,да и проще 1 раз сделать по-уму, в Вашем же варианте мы просто теряем понятие заказа, ну а про многоскладовость заказа я вообще молчу.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34082530
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To CLilian: не путайте понятия Приход и Заказ.Не всегда Приход отвечает Заказу (к слову о план/факте).
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34082719
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
to Jedaito:
>> К названиям полей надо спереди дописывать не только имя таблицы, но и имя базы. и на всякий случай имя сервера.

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

Пример: Фил.1 ищет деталь с кодом 001 у себя он уже све продал и находит что 001 есть в Фил.5. Тогда Фил.1 просит Фил.5 сделать перемищение товара с Фил.5 на Фил.1 чтобы Фил.1 смог продать эту деталь, (п.с. 001 это оригинальный код детали).
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34082875
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
про имена это юмор такой
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34083536
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Shtockпро имена это юмор такой

:) смешно, я не врубился сразу.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34083569
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Одну таблицу.
Такой вопрос: как на счет торможения запросов? т.е. если будет скажем милион записей в каждом складе (если это вообще возможно) а складов та могут быть и тысячи, то при запросе время не будет слишком большое?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34083575
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
CLilianОдну таблицу.
Такой вопрос: как на счет торможения запросов? т.е. если будет скажем милион записей в каждом складе (если это вообще возможно) а складов та могут быть и тысячи, то при запросе время не будет слишком большое?
Сообщение адресовано: Сергей Васкецов >> Одну таблицу.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34083578
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
смотря каком запросе.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34083787
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Shtockсмотря каком запросе.
Скажем надо получить или расчитать баланс в конце месяца. Не исключино что несколько филиалов будут это делать в одинь день.
Пример:
Фил.1 считает свои приход-расход по 01.2006;
Фил.3 считает свои приход-расход по 01.2006;
Фил.15 считает свои приход-расход по 01.2006;
и каждый делает запрос по перерасчету. Сильно будет тормазить компьютер каждово из филиал или это всетаки зависит от сервера?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34084158
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как построите селект,индексы,может быть вы будете применять материализованные представления (правда по ms я совсем не специалист).
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087237
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CLilianОдну таблицу.
Такой вопрос: как на счет торможения запросов? т.е. если будет скажем милион записей в каждом складе (если это вообще возможно) а складов та могут быть и тысячи, то при запросе время не будет слишком большое?
На таких скромных данных, как Вы указали, любой троешник заставит это работать. Торможение в одну из последних очередей определяется количеством записей в таблице, и в первую очереь - правильным проектированием.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087247
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shtockв Вашем же варианте мы просто теряем понятие заказа, ну а про многоскладовость заказа я вообще молчу.
Не понял:
1. Почему теряем?
2. Что такое многоскладовость заказа?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087297
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пример текстом о балды: по договору 234 предоставить 20 рулонов стеклоткани А15, причем 5 рулонов должны быть доставлены вами на наш склад 6, вами 10-на наш склад 3,5 - переместить на ваш склад №2, мы его заберем замовывозом. Вот это и есть пример многоскладовости заказа причем как со стороны заказчика,так и со стороны поставщика.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087316
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShtockПример текстом о балды: по договору 234 предоставить 20 рулонов стеклоткани А15, причем 5 рулонов должны быть доставлены вами на наш склад 6, вами 10-на наш склад 3,5 - переместить на ваш склад №2, мы его заберем замовывозом. Вот это и есть пример многоскладовости заказа причем как со стороны заказчика,так и со стороны поставщика.
1. Я где-то писал, что в строке состава нельзя сделать ссылку на склад/контрагента?
2. Почему это вообще должен быть один заказ?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087369
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1.нет,вы писали "на порядок проще будет ..... и не различать контрагентов и склады."
2."Почему это вообще должен быть один заказ?" - а зачем это должно быть несколько?если по-сути - это один заказ,например платеж пойдет по одному заказу и меньше будет гемора бухгалтерии. Если есть желание делать несколько платежей,соотв док-тов,проводок,подписей,договоров(давайте считать те 5 платежей за 1) то бейте на несколько, только бизнесу это не надо.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087382
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати,как вам такая ситуация: контрагент поставил вам товар,но забрать его надо не со склада этого контрагента,а со склада чужого,так как у контрагента такого товара нет,но есть договоренность с уже его контрагентом.Это реальная ситуация.Можно конечно говорить,что надо наводить порядок в бизнес-процессах,но пока мы живем в россии и проще писать все по-уму сразу.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087470
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shtock1.нет,вы писали "на порядок проще будет ..... и не различать контрагентов и склады."
Это в том смысле, что в документ надо уметь подставлять как склад, так и контрагента, причем в одно и то же место. Пример - выдача МБП со склада. Ушло со склада - пришло человеку. Поэтому в заголовке и должно быть как минимум 2 поля, чтобы туда вводить "откуда" и "куда" для всех документов. А в случае с одним Вашим заказом "откуда" - это предприятие, и "куда" - тоже предприятие, зачем склады в заголовке, если это один заказ? Склады пусть в составе будут, для уточнения. А в приходе/расходе/перемещении уже склады в составе не нужны, ибо склад(ы) будет(ут) в заголовке, зато туда можно запихнуть контрагента/сотрудника, если (и когда) это понадобится.

Shtock
"Почему это вообще должен быть один заказ?" - а зачем это должно быть несколько?если по-сути - это один заказ,например платеж пойдет по одному заказу и меньше будет гемора бухгалтерии. Если есть желание делать несколько платежей,соотв док-тов,проводок,подписей,договоров(давайте считать те 5 платежей за 1) то бейте на несколько, только бизнесу это не надо.
Вопрос платежей вообще не рассматривался. Да и не понятно, почему если несколько заказов, то нельзя делать один платеж, и все их родить из одного договора. Да и не заказ оплачивается, а счет, вообще-то (хотя, я могу и заказ оплатить. да и проводки по заказам - странно как-то, только заказали - а уже какие-то хозяйственные операции понеслись?). У меня в системе отношение между любыми коммерческими документами и платежами - M:N, чего и Вам желаю.
А делить на несколько заказов можно потому, что у разных отгрузок могут быть разные согласования, временнЫе параметры, статусы, права доступа, ответственные за это лица и тому подобное.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087629
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1.Давайте тогда определяться с терминами: заказ - тождественен ли договору. я считаю - да.если у Вас нет-тогда наш спор понятен.
2.основанием для счета является договор.
3.проводки - по счетам управленческого учета
4.при чем тут отгрузки и заказы?Делить конечно можно по каждому заказу по отгрузке,но зачем?вести один заказ/договор имхо проще чем несколько (но это скорее орг вопрос :)).
5.нет разницы между человеком и складом,согласен (у меня они даже живут в одной таблице),но я полностью запутался.Может нарисуете вашу модель?

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

P.S. Непонятки в терминах всегда ведут к излишней трате воздуха в виде спора
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087666
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Модель рисовать не буду, с Вашего разрешения.
Договора и заказы разделяю.
Естественно, по заказу может быть сколько угодно отгрузок, и наоборот.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087684
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Разрешаю, но письменным описанием угадал?В общем,мир...
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087689
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а в чем разница (чисто ради спорт интереса) между договором и заказом? что-то мне кажется,что заказ у Вас это как у меня плановая отгрузка, а Ваша отгрузка - моя фактическая отгрузка?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34087719
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ладно,вернемся к этой теме ближе к понедельку.Пятница,так сказать,сокращенный день.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34088888
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Привет всем,
проанализировал ваши советы и решил сделать так (как на рисунке), покритикуйте пожайлуста примерчик.

Едиственное что осталось сделать и никак пока не сообразил как, это:
1. с данными по бугалтерии т.е. зарплата персонала (НДС и т.д.)
2. с данными по налогам по прибали и т.д.

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

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089002
I_one
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А на чём пишете клиентскую часть если не секрет ? ... И почему сервер выбран MS SQL?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089221
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
I_oneА на чём пишете клиентскую часть если не секрет ? ... И почему сервер выбран MS SQL?
Пищу я на ВБ 6.0, как я понял MS SQL предлагает хорошую систему защиты.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089449
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!
Начну с простого – с игры. Возьмем два блюдечка и положим в одно 10-15 зернышек риса. Рис – это наши «УЧЕТНЫЕ ЕДИНИЦЫ». Я прошу отгрузить 3 учетные единицы. Для этого из первого блюдца возьмем 3 зернышка и положим во второе. Я прошу отгрузить 5 учетных единиц. Сделаем тоже, но переложим 5 зернышек. Все – учетный период закончился.
Для того чтобы узнать, сколько учетных единиц у меня осталось, я их посчитаю в первом блюдце, а для того чтобы узнать, сколько я отгрузил – буду считать во втором.
Это мой ключевой принцип учета ТМЦ (на нем построены работающие много лет системы).
Некоторые моменты:
- учет ведется в «учетных единицах» на запись, т.е. каждая запись – это описание одной «учетной единицы», поле «количество» отсутствует
- в большинстве систем тип ключевого поля для «заголовочной части» - это datetime, а в таблицах Warehouse и GoodsMovement он составной из внешнего на заголовок и простого инкремента в пределах внешнего ключа.
- если надо эти две таблицы денормализуются и из заголовочной части к ним мигрируют атрибуты склада и т.п.
- в рабочих процессах все многоходовые операции (например, принять с трех складов поставщика некоторые ТМЦ и оприходовать их на 8 складов этого филиала) в композитной обработке приводятся к атомарным «приход – расход» и заносятся в таблицы.
Что позволяет:
- легкость и быстрота получения отчетных данных
- элементарная организация учета по FIFO, LIFO, индивидуальному и среднему
- масштабируемость от «я торгую» до «с нами весь мир»
Примечания:
- описан подход, а не набросок реализации
- конечно, реализация учитывает и журналы отклонений, и «человечески» фактор и др. важные и такие «интересные» моменты.
- критиковать не надо, т.к. задача была ознакомить с альтернативным апробированным подходом, а не вступать в полемику.
Успехов.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34089492
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорь
Некоторые моменты:
- в большинстве систем тип ключевого поля для «заголовочной части» - это datetime, а в таблицах Warehouse и GoodsMovement он составной из внешнего на заголовок и простого инкремента в пределах внешнего ключа.
Уважаемы Папа Игорь я не совсем понял принцип описаный выше, если не трудно обесните пожалуйста еще раз.

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

Для Лилиан.
В данное время очень занят, но может ближе к вечеру, попробую прояснить для Вас этот подход.
Успехов.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34091523
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Глянул-теперь больше походит на правду,но такие вопросы:
1. сущность Контракт (Заказ) Вы решили не выделять,хотя вначале про нее спрашивали?В чем причина?
2. Вам вроде бы все говорили,что from и to может быть как складом,так и человеком (к слову о едином реестре).Вы все равно сделали ссылку только на склад...
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092258
Уважаемый Папа Игорь, я давно отошел от стереотипов. Но теперь, следую Вашему совету, отойду от них еще дальше. Однако нужно понимать, что без физической идентификации партий, независимо от нашего с Вами расстояния от стереотипов, ни о каком "партионном учете" и "прослеживаемости" не может быть и речи.
"Внутри" Вы говорите ?
Пример. Получив 5 коробочек сахара (по 1 кг), можно "оприходовать" это как 5 партий, наклеив на коробочки ид. партий (и/или ШК):
234,235,236,237,238.
А можно "оприходовать" это как 1 партию, наклеив:
234,234,234,234,234.
"Внутри" получается по-разному. В первом случае идентифицирован "каждый килограмм". А "внутри" кусочки сахара, а "внутри кусочков" песчинки. И как же без Левшы физически идентифицировать каждую песчинку, если это нужно ?
И о каких именно "стереотипах" Вы говорите ? Возьмите теперь из коробочки 236 (первый "вариант учета"), например, 0.7 кг сахара. А теперь возьмите 0.7 кг сахара из одной из коробочек 234 (второй "вариант учета"). И поразмышляйте о разнице, отойдя от стереотипов уже бесконечно далеко.
Мы с Вами, надеюсь, понимаем друг друга. Осталось только Вам пояснить Ваш подход CLilian.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092268
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ShtockГлянул-теперь больше походит на правду,но такие вопросы:
1. сущность Контракт (Заказ) Вы решили не выделять,хотя вначале про нее спрашивали?В чем причина?
Я выделяю заказ при создания документа. Сделал я это потому что при любой операции делаеться документ, вот я и присоединил к документу статус для опредиления его и всех заказов в нем.
Вопрос: может есть и другие варианты?
Shtock2. Вам вроде бы все говорили,что from и to может быть как складом,так и человеком (к слову о едином реестре).Вы все равно сделали ссылку только на склад...
Если чесно я при проектировании упустил эту важную деталь, буду думать.

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092403
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для Лилиан.
Все нижеизложенное максимально упрощено, служит для пояснения концепции и для реальной системы в таком виде не приемлемо, но МОЖЕТ служить отправной точкой к размышлению.
Вначале немного анализа.
Учетную систему (УС) можно рассматривать как некий процессор, обрабатывающий события в бизнесе. Произошло событие важное для бизнеса – УС зафиксировала его и соответственно отреагировала.
Поэтому приготовим табличку для событий.
Код: plaintext
1.
2.
3.
4.
CREATE TABLE dbo.BusinessEvent(
	EventDate datetime NOT NULL DEFAULT (GETDATE()),
	AgentID int NOT NULL,
	EventID int NOT NULL,
 CONSTRAINT PK_BusinessEvent PRIMARY KEY CLUSTERED(EventDate ASC))

EventDate - дата/время события служит ключем
AgentID - контрагент, в случае "внутреннего" события это сам хост
EventID - вид события
Для прихода ТМЦ таблица такая:
Код: plaintext
1.
2.
3.
4.
5.
CREATE TABLE dbo.Warehouse(
	RefKey int IDENTITY( 1 , 1 ) NOT NULL,
	EventDate datetime NOT NULL,
	ProductID int NOT NULL,
	Amount int NOT NULL,
 CONSTRAINT [PK_Warehouse] PRIMARY KEY(RefKey ASC))
Для «ухода» такая:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE dbo.GoodsMovement(
	RefKey int NOT NULL,
	EventDateOut datetime NOT NULL,
	AmountOut int NOT NULL,
	ProductID int NOT NULL,
	EventDateIN datetime NOT NULL,
	AmountIn int NOT NULL,
 CONSTRAINT [PK_GoodsMovement] PRIMARY KEY(RefKey ASC))

Теперь поиграем (обработка ошибок, транзакции и т.п. не показываются):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
-- от контрагента №3 20.10.2006 14:10:02 поступили ТМЦ двух видов
-- 1. № 1 10 уч.ед. на сумму 100
-- 2. № 2 15 уч.ед. на сумму 180
DECLARE @EventDate datetime
DECLARE @Counter int
DECLARE @Qty int
DECLARE @Rest int
DECLARE @Amount int

SET @EventDate = CONVERT(datetime, '20061020 14:10:02',  113 )
INSERT INTO BusinessEvent VALUES(
	@EventDate
	,  3 
	,  1 
	)
-- товар № 1 
SET @Rest =  100 
SET @Qty =  10 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 
WHILE @Counter < @Qty
	BEGIN
		INSERT INTO Warehouse VALUES(
			@EventDate
			,  1 
			, @Amount
		)
		SET @Rest = @Rest - @Amount
		SET @Counter = @Counter +  1 
	END
INSERT INTO Warehouse VALUES(
	@EventDate
	,  1 
	, @Rest
)

-- товар № 2
SET @Rest =  180 
SET @Qty =  15 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 
WHILE @Counter < @Qty
	BEGIN
		INSERT INTO Warehouse VALUES(
			@EventDate
			,  2 
			, @Amount
		)
		SET @Rest = @Rest - @Amount
		SET @Counter = @Counter +  1 
	END
INSERT INTO Warehouse VALUES(
	@EventDate
	,  2 
	, @Rest
)
-- следующая поставка
-- от контрагента №1 20.10.2006 15:18:33 поступили ТМЦ 
-- 1. № 1 8 уч.ед. на сумму 75
SET @EventDate = CONVERT(datetime, '20061020 15:18:33',  113 )
INSERT INTO BusinessEvent VALUES(
	@EventDate
	,  1 
	,  1 
	)
-- товар № 1 
SET @Rest =  75 
SET @Qty =  8 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 
WHILE @Counter < @Qty
	BEGIN
		INSERT INTO Warehouse VALUES(
			@EventDate
			,  1 
			, @Amount
		)
		SET @Rest = @Rest - @Amount
		SET @Counter = @Counter +  1 
	END
INSERT INTO Warehouse VALUES(
	@EventDate
	,  1 
	, @Rest
)

-- отгрузим контрагенту № 5 21.10.2006 10:00:00
-- 2 уч.ед. ТМЦ № 1 на сумму 30
-- допустим учет ведется по LIFO

DECLARE @ProductID int
DECLARE @RefKey int

SET @EventDate = CONVERT(datetime, '20061021 10:00:00',  113 )
INSERT INTO BusinessEvent VALUES(
	@EventDate
	,  5 
	,  2 
	)
-- товар № 1 
SET @ProductID =  1 
SET @Rest =  30 
SET @Qty =  2 
SET @Amount = CONVERT(int, @Rest / @Qty)
SET @Counter =  1 

WHILE @Counter < @Qty
	BEGIN
		SET @RefKey = (
				SELECT   W.RefKey
				FROM (SELECT TOP  1  * FROM Warehouse ORDER BY EventDate DESC) AS W
				WHERE W.ProductID = @ProductID
				)
		INSERT INTO GoodsMovement ( RefKey
      , EventDateOut
      , AmountOut
      , ProductID
      , EventDateIN
      , AmountIn
		)
		SELECT  @RefKey
				, @EventDate
				, @Amount
				, W.ProductID
				, W.EventDate
				, W.Amount
		FROM Warehouse W
		WHERE W.RefKey = @RefKey

		DELETE FROM Warehouse WHERE RefKey = @RefKey

			SET @Rest = @Rest - @Amount
			SET @Counter = @Counter +  1 
	END
	SET @RefKey = (
			SELECT   W.RefKey
			FROM (SELECT TOP  1  * FROM Warehouse ORDER BY EventDate DESC) AS W
			WHERE W.ProductID = @ProductID
			)

	INSERT INTO GoodsMovement ( RefKey
   , EventDateOut
   , AmountOut
   , ProductID
   , EventDateIN
   , AmountIn
	)
	SELECT  @RefKey
			, @EventDate
			, @Amount
			, W.ProductID
			, W.EventDate
			, W.Amount
	FROM Warehouse W
	WHERE W.RefKey = @RefKey
	
DELETE FROM Warehouse WHERE RefKey = @RefKey

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

P.S. Увидел пост от Андрея Леонидовича и понял, что писатель из меня никакой (хороший писатель мысль свою доносит до «самых до окраин»).
Уважаемый Андрей Леонидович, «учетная единица» - это у меня не от бедности словарного запаса. Это ограничение. И 0,7 уч.ед. быть НЕ МОЖЕТ.
В каждом конкретном бизнесе это суть РАЗНЫЕ величины.
В Вашем примере для сахара ( Вы сладкоежка?) это может быть и пачка, и кусочек. Ограничение одно – атомарность. Т.е. дальнейшее «деление» невозможно (не по физической причине, а по бизнес-правилам).
Получил тонну гравия (я камнеед?), а учет веду в килограммах, значит записываю 1000 уч.ед. гравия.
Отсюда и мой вопрос про партионность и «обезличенность» внутри партии. И совет (только совет) отойти от стереотипов (не уйти в бесконечность). Наличие в моей РАСХОДНОЙ накладной строки вида “0,5 тн. гравия” не обязательно в ТАКОМ ЖЕ ВИДЕ будет отражено в таблицах.
Ваш подход, каков бы он ни был, имеет право жить и решать Ваши задачи.
Мой подход – «аналогично» (с)

Желаю здравствовать.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092415
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В последнем абзаце кода надо так (оттенил исправление):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
	INSERT INTO GoodsMovement ( RefKey
   , EventDateOut
   , AmountOut
   , ProductID
   , EventDateIN
   , AmountIn
	)
	SELECT  @RefKey
			, @EventDate
			, @Rest
			, W.ProductID
			, W.EventDate
			, W.Amount
	FROM Warehouse W
	WHERE W.RefKey = @RefKey
	
DELETE FROM Warehouse WHERE RefKey = @RefKey
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34092494
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо большое Папа Игорь за очень поеснительный пример.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34093625
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здраствуйте,
Папа Игорь у меня поевились 2 вопроса к вам и вот какие:
1. Таблицы BussnessEvent, Wherehouse и GoodsMoment можно и нужно связать между ними связями?
2. В вашем примере я заметил что поле Amount тип данных INT а есть ли смысыл менять его на MONEY или это зависит от конкретной задачи?

С уважением,
Лилиан.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34095561
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!
Ответы:
1. Я предложил Вам идею (подход). Реальное проектирование возможно только после сбора требований к Вашей системе. Поэтому ни о каких либо "связях" и "таблицах" речь не идет. На полях замечу, что "связи" - это бизнес-правила (ограничения) на данные и принять решение об их "количестве и качестве" возможно только после анализа задачи. Иногда эти ограничения кодируют на клиенте.
2. Зависит от задачи. Есть системы где деньги ХРАНЯТСЯ в типе int, в другой системе в money.
Успехов.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34095814
Все было бы хорошо, Папа Игорь, но у меня нет никакого подхода (откуда же взяться стереотипам, что за стереотипы такие ?). А недостаточность (для партионного учета и прослеживаемости) Вашего подхода я продемонстрировал. Конечно, она связана не со стереотипами (ни в коем случае !), а с осознанными ограничениями Вашего подхода. И, конечно, тоже желаю здравствовать.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34097341
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.
Отвечаю не для того чтобы мое сверху было.
Уважаемый Леонид Андреевич, я в смятении. Мое косноязычие не позволило донести ПРОСТОТУ и ЛОГИЧНОСТЬ моего подхода. Призываю на помощь строгий и великий SQL.
Из Вашей структуры хранения легко получить мою. Обратную операцию провести тоже легко. А главное - БЕЗ ПОТЕРИ ИНФОРМАЦИИ. Это очень важно, Леонид Андреевич, очень! На этом стоят правила декомпозиции и композиции. Информация не должна терятся.!!!
Делаем такой запрос к таблице Warehouse (Вы же понимаете ее структура – это пример):
Код: plaintext
1.
2.
3.
4.
5.
SELECT ALL EventDate
	, ProductID
	, COUNT(*) AS Qty
	, SUM(Amount) AS Total
FROM Warehouse
GROUP BY EventDate, ProductID
Выводятся остатки на момент последней зафиксированной сделки.
Результат имеет ТРАДИЦИОННУЮ структуру (плюс ЛЮБЫЕ необходимые атрибуты для, многократно упомянутых Вами, партионности и прослеживаемости).
Вы можете спросить, а зачем тогда эти пляски. Это позволяет реляционно (без курсоров) обрабатывать (корректировать) прошлые сделки (да-да и в этом есть неообходимость), прозрачно менять подходы к расчету себестоимости проданных товаров, прослеживать местонахождение ЕДИНИЦЫ товара вплоть до ячейки на стеллаже и т.д.
Дальнейшие упражнения с таблицами Вы можете выполнить сами. Это убедит Вас в «однонаправленности» наших рассуждений. Просто я решил пройти немного дальше в декомпозиции. Подчеркну еще раз – ИНФОРМАЦИЯ НЕ ТЕРЯЕТСЯ.
Желаю Вам всего и только хорошего.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34098304
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа ИгорьИскренне восхищен
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34098933
В смятении, уважаемый Папа Игорь, вовсе не обязательно находиться.
Если сахар Вас не устраивает, так здесь уже учитывали спирт. И я тогда предложил приблизительно "Ваш подход" (см. тему "Операция распаковки партии товара").
Вы отпейте (или отлейте - по нынешним "отравленным временам") спирта из одного конкретного ведра при любой удобной для Вас "учетной единице", и поясните что получится у Вас в учете (я уж не прошу "вырезать кусок некоторой конфигурации из листа металла, и учесть остаток"). Хоть реляционно, хоть не реляционно.
Будьте здоровы.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34099050
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я хотел дать им крылья! Они думали – их валяют в перьях. (с)
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34099256
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
оригинально! Я тоже в восхищении. 40 тыс. номенклатуры по 100 тыс каждого наименования. Единица учета - грамм. О чем вообще речь идет? Это шутки сейчас такие? Тогда спасибо. Действительно весело.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34100327
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте!

"... 40 тыс. номенклатуры по 100 тыс каждого наименования. Единица учета - грамм. ..."

Я бы подекомендовал прочесть ВНИМАТЕЛЬНО весь топик (только без обиды, ладно?), ибо Ваше высказывание "в никуда". Ни граммов, ни килограммов, ни пачек в моем подходе нет, господа. А есть, заданная бизнес-правилами, ЕДИНИЦА УЧЕТА.
В конце 90-х я проектировал базу для одной совместной фирмы. В Испании у нее работал "свечной заводик" (с), а на Украине она торговала произведенной продукцией плюс еще чем-то, включая канцтовары.
Среди прочих товаров был некий вид шампуня. Так вот он учитывался полудюжинами.
Шесть флаконов были залиты пластиком и в таком виде отпускались потребителям. Это была НЕДЕЛИМАЯ далее учетная единица. В регистрах учета хранилось не шесть шт., а одна запись на единицу учета.
Другая контора. Торговля финской наждачной бумагой. В пачке 50 листов. Единица учета - пачка. Листами фирма не торговала - только пачками.
Третья контора. Сигареты. Единица учета - блок. Получали вагонами - учитывали блоками.
Повторюсь. Единица учета задается не ФИЗИЧЕСКИМИ параметрами, а БИЗНЕС-ПРАВИЛАМИ.
Надеюсь приведенные примеры окончательно убрали "непонятку". И, конечно, как и всякий другой подход, этот имеет ГРАНИЦЫ ПРИМЕНИМОСТИ.
В испанской фирме были такие объемы:
Номенклатура - около 12000
Средний запас на ед. - 400-450
Таблица типа Warehouse содержала около 5 млн. записей. 32 байт на запись. Размер таблицы примерно 150 метров.
В таблицу типа GoodsMovement за месяц заносилось около 2,2 млн. записей. Размер записи 52 байт. Это около 100 метров.
Господа, это не те размеры и объемы, чтобы копья ломать. Хотя до меня доходили слухи, что одна контора на ГОРАЗДО больших объемах применяла этот подход.
Всем успехов и процветания.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34102158
ГРАНИЦЫ ПРИМЕНИМОСТИ. Это хорошо, Папа Игорь. И они вполне понятны. Торговля. Причем оптовая (ни спирта не отлить, ни колбасы не отрезать). И некоторые другие границы. Да, мы тут с iscrafm, наверное, зациклились на производстве. Вы правы, Папа Игорь, ГРАНИЦЫ ПРИМЕНИМОСТИ делают просто чудеса, в плане использования бесконечного множества подходов в зависимости от бесконечного множества границ.
Жизнь разнообразна, так сказать.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34102191
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа ИгорьЯ бы подекомендовал прочесть ВНИМАТЕЛЬНО весь топик (только без обиды, ладно?), ибо Ваше высказывание "в никуда". Ни граммов, ни килограммов, ни пачек в моем подходе нет, господа. А есть, заданная бизнес-правилами, ЕДИНИЦА УЧЕТА.
Да какие обиды. Я же и говорю единица учета - грамм ;) В общем любой, какой только есть сыпучий, льющийся, режущийся и т.п. запас. Слишком ограничено и сомнительный выигрышь.... "не так как обычно".
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34102333
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для Андрея Леонидовича.
Эх, дались Вам эти границы. Да от правды никуда не денешся 80 процентов контор с которыми я работал – это торговля. В производстве опыта меньше. Но «их есть у меня» (с)!!!
Производство краски (это конечно не самолеты, но все же). Объемы конкретно не помню, но среди клиентов были три мебельные фабрики и заводик по производству прицепов, платформ и т.п. Учетная единица готового продукта – килограмм.

Переработка мяса. Мясо в килограммах, сопутствующие (специи и т.п.) в граммах.
Готовая продукция – в килограммах. Объемы не большие – до 10 тн. в день.

Вы поминали задачу с металлом из которого вырезали кусок и предложили мне учесть остаток. Это наверное шутка. А скажите – ювелирное производство – это производство или торговля. Так вот золотые пластины использовали для изготовления изделий и УСПЕШНО учитывали остатки.

Напомню Вам, что я просто решил пойти дальше в декомпозиции данных. Потери информации не было. Обработка значительно упростилась. Ваша запись «спирт 0,5 л. на сумму 5 рублей» без проблемм преобразуется в 500 записей «спирт на сумму 1 копейка», если учетной единицей (подчеркну еще раз – это зависит от БИЗНЕСА) принять миллилитры. Или в 50 записей по 10 коп. если учетные единицы 10 мл. Если я буду производить спирт по 100 тн. в день, то за учетную единицу приму килограмм (литр). Т.к. потребителям отпускаю его именно в етих единицах, и учитывать «мерзавчики» не буду.

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

P.S. В настоящий момент я работаю только с небольшими (10-15 человек) конторами.
Так вот для них базы данных сделаны в традиционном формате (т.е. поле количество есть). И пять же для УПРОЩЕНИЯ учета.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34202471
CLilian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорь
Код: plaintext
1.
2.
3.
4.
CREATE TABLE dbo.BusinessEvent(
	EventDate datetime NOT NULL DEFAULT (GETDATE()),
	AgentID int NOT NULL,
	EventID int NOT NULL,
 CONSTRAINT PK_BusinessEvent PRIMARY KEY CLUSTERED(EventDate ASC))

Добрый день, сталкнулся я с такой проблемой:
при селекте не выдает никаких данных, и не могу понять в чем проблема, ощибок я не нашел да и сервер тоже не ругается при выполнении. Помогите разобраться.
Код: plaintext
SELECT * FROM dbo.BussinessEvents WHERE (b_event_date=CONVERT(datetime,'20061213 01:26:02', 13 ))
где b_event_date тип данных datetime.
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34215193
AndrF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CLilian Shtockпро имена это юмор такой

:) смешно, я не врубился сразу.

А намек-то понял? Ведь он есть...
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34229305
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CLilian
Добрый день, сталкнулся я с такой проблемой:
при селекте не выдает никаких данных, и не могу понять в чем проблема, ощибок я не нашел да и сервер тоже не ругается при выполнении. Помогите разобраться.
Код: plaintext
SELECT * FROM dbo.BussinessEvents WHERE (b_event_date=CONVERT(datetime,'20061213 01:26:02', 13 ))
где b_event_date тип данных datetime.

Здравствуйте!
Не совсем понял вопрос. Может быть в таблице НЕТ записи с b_event_date РАВНОЙ Вашему критерию. Сделайте выборку всей таблицы и посмотрите.

Успехов.

P.S. Код моих примеров вроде отрабатывает без проблем. Или нет?
...
Рейтинг: 0 / 0
такой большой проект у меня в первые
    #34481740
ByKiS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JedaitoК названиям полей надо спереди дописывать не только имя таблицы, но и имя базы. и на всякий случай имя сервера.А что никто не дописывает? По мойму удобно... Просто Name - легко запутаться. Хотя, если CustomerName, SupplierName, EmployeeName - то получается дублирование в запросах (всё-равно ведь таблица указывается) - с одной стороны. А сдругой - сразу всё видно, а если сервер дописать - вообще класс - сразу понятно где база находиться :)

Кто как пишет? Пишите имя таблицы? А то я уже собрался все поля переименовывать :)
...
Рейтинг: 0 / 0
55 сообщений из 55, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / такой большой проект у меня в первые
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]