Один из видов деятельности фирмы, где я работаю - продажа интернет-карточек.
То есть карточки берутся у неких поставщиков, хранятся на складе, а потом продаются. Причем продается только юридическим лицам. Просто зайти с улицы и купить карточку у нас нельзя.
Карточки продаются без определенного порядка - нужно 100 таких и 50 вот таких - просто достают коробки, что ближе лежат.
И вот сегодня девочка, к-я занимается всем этим делом, попросила написать программку для учета таких карточек - приход, расход, текущее состояние на складе. В принципе, все.
Мое предложение использовать 1С было отвергнуто.
Вот теперь сижу и придумываю структуру базы.
Пока что придумал вот что:
1)
Storageobject_idobject_nameobject_units_idobject_countobject_sale_price
хранит остатки на складе - наименование объекта хранения, ед. измерения (ссылка на таблицу-справочник), количество (может быть "0"), цена, назначенная директором для продажи.
2)
Unitsunit_short_nameunit_full_nameunit_description
это справочник единиц измерений
3)
Ordersorder_idorder_object_idorder_countorder_dateorder_invoice_numberorder_company_id
это приход товара - наименование товара (ссылка на таблицу Strorage), количество товара, дата, номер накладной, компания-поставщик (ссылка на соотв. таблицу)
3)
Salessale_idsale_object_idsale_countsale_datesale_invoice_numbersale_company
это расход. структура таблицы аналогична 2). (кстати, может, следует объединить таблицы 2-3?)
4)
Companycompany_idcompany_name....
таблица компаний (как поставщиков, так и клиентов) - ее детальная структура на данный момент не интересна.

Допустим, закупили 1000 карточек на 10 часов доступа в интернет. Тогда я представляю себе работу программы так:
1) обновляется таблица Storage - если такой объект уже существует, то изменяем поле object_count на купленное количество, иначе - добавляем новую запись;
2) добавляем запись в таблицу Orders;
Теперь продаем:
1) обновляем таблицу Storage - вычитаем продаваемое количество из object_count (в итоге может получиться 0);
2) добавляем запись в таблицу Sales.

Подскажите, пожалуйста, насколько такая структура жизнеспособна, чего не хватает, что лишнее?

Не могли бы Вы дать чуток более развернутый ответ? Желательно, с аргументами. Что не так?

Old Nick
Благодарю за ответ. Постараюсь поправить свою схему.


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

Cripp1024
Велосипед изобретаем, господин студент? Советую пойти поработать в какую-нибудь приличную складописательскую контору. Там за годик-другой всему научитесь.
То есть, по-Вашему, если человек изобретает велосипед - это обязательно студент? Когда заканчиваешь ВУЗ, то приходит ВЕЛИКОЕ ОЗАРЕНИЕ? Все задачки решаются в уме? Если у Вас так и было, рад за Вас безмерно.
У меня, к сожалению, все гораздо приземленнее. Надо лишь работать и работать - только тогда получается. Что я, собственно, и стараюсь делать. И на форуме спрашиваю чтобы НАУЧИТЬСЯ, а не получить щелчок по носу.
..
Может, тогда подкинете готовое решение? Тогда не буду изобретать велосипед. :)

СерегаДа пожалста. Только цена то меняется. И ты никогда не будешь знать ни по какой цене купил, ни по какой продал. Ты знаешь только цену на сегодня.
Не понимаю. Я же храню цену продажи/покупки в "таблицах регистрации движения" ((с) Old Nick )? Поэтому я всегда могу сказать, по какой цене купил, а по какой продал.
А цена в Storage - отдельный параметр. Это лишь предписание директора.

Old Nick
Хм.. Вы правы. Спасибо.