adonis
03-23-02, 01:31
| hi all, I am currently designing a database for a small company scenario. The case will sound a little bit simplistic but i find myself turning in circles on some points. This little company imports items(like a watch, or a bracelet) : Problem no 1: how to modelise the Item table (and its associated tables)? ex: a Timex watch can be of size (,8,9,10) and of color (yellow,red green...) how do i modelize my items so that on the invoice i know what exactly is being sold? how much i have in stock, on hand ? will the type Timex have 1 unique item # number? or will every combination have an item number? Now a customer makes an ORDER, the order contains ORDERED ITEMS, i assume the orderDate falls under ORDER table, and quantity falls under ordered items. This will create an invoice, the invoice will contain the invoice#, order#, date, and amount. In order to keep track of the company's sales, should the invoice update a CustomerAccount Table? if the customer decides to return some of the items, should i create a CREDITMEMO table? or simply update a field under ORDEREDITEMS like quantityReturned? What if when the customer makes a payment, is custID and payment date enuff to identify the customer's payment? if no, what info is necessary? then i need aCUSTOMERACCOUNT table to update a customer's balance? if a customer pays a check or by credit, how to deal with the check no? or the credit expiration date? ccnumber? I would really appreciate any guidance!!!!! desperately yours, Adonis |