I'm creating a Motorcycle store system, i wondering if i need to create one table that contains orders, the sales orders and the purchases orders with a column that will be called OrderType that determine if its purchase order or sale order
the same with Payments, money that i pay to supplier and money that customer pay to me, should be in table that called payment and column that determine if its outgoing payment or income
is that ok? or i need to create other tables
I would consider against it... Purchases are from a vendor YOU get the products from to build/fix/manufacture something.
Sales orders would have a customer you are selling to and thus would be foreign keys to different tables... unless your customer table has your vendors too and that has some column to identify difference as Vendor vs Customer.
Additionally, as you expand your design development and queries, purchasing history, etc., it may be more beneficial to have them separate.
You can create a single table. Whether this is good design or unfortunate design depends on how you use the data. How many times do you ever want to query these two datasets as if they were one dataset? How many times to you query them separately?
I am trying to write a Check to make sure that a customer can only buy 10 of a certain product type (smartphone) and 4 of another product type(tv), and buy another product only during morning(before 12:30). The table is
invoice(PK invoice_no, FK product, amount, customer_name,time, FK opening_time )
Check (amount >10) would check the amount but I want to limit only a few types of products. Also product type isn't in my invoice table, should I add that to the table or can I join another table (Product) in check?
I guess this kind of validation / restriction is better fit to your application's business level rather then your data / database level
I am new to database design.
I have an assignment to design a relational database for a company that has 3 shops that fulfills these requirements:
1) A product has an ID, quantity, price and new product can be added.
2) Each shop has a name, and an ID
3) Do NOT create tables that store products of each shop, but only a "History" table that has a "status" attribute that keeps track of transaction history only (IN: add new product, OUT: check out product). Each transaction has a productID, "status", quantity check (in/out), history (timestamp), shopID. Manager only needs to make query to see each shop's current stocks of the products. Datasets should be like this:
(barcode is just replaced with productID)
4) Price: design a table structure for the price such that:
a) Price can be changed. When a price changes, there should be a method to keep track with the history and the old value of the price changes. Manager can make query to see when the price was changed and how much the old price was.
b) Discount: a discount of a particular product in a particular shop can have a discount value. For example in that week the new shop is open, its product A has a discount B% during that week.
c) Manager should be able to make a query to retrieve data of the total revenue.
I was given the first 3 tasks to design last week, and this week the fourth requirement came up and I need to change the design accordingly. How can I change my design to cope with the last requirement? Thank you.
My current design for the first 3 requirements:
I am new to openerp v7, I want to automatically get the value of a field (a field which I have created) in a purchase order. Considering:
in both sale order and purchase order form I have created the field and displayed it
All my products have Procurement Method - make to order and I use run schedulers to convert sale orders to purchase orders automatically
How do I get the value of the custom field in the purchase order directly from the sale order?
Any kind of help would be much appreciated.
I'm currently trying to redesign a Point of Sale database to make it more normalized, which will help tremendously with managing the data, etc. I'm a little bit unsure about the best design practices, based on the data I have to deal with. First of all there are basically two sets of measures, which share common keys. There is inventory data, units and dollars, and then point of sale data, units and dollars. Each of these is a customer, store, item and date level.
What I've done (mostly in theory at this point) is to create separates table for
Item level information
Item_ID,
Customer_ID
itemnumber
(and a few other item specific information).
Stores
Store_ID,
Customer_ID,
Store Number,
(and essentially address information)
Customer
Customer_ID,
Customer Number
(other customer specific information like name).
So in addition to those "support" tables, I have the
Main Inventory Data
Store_ID
Item_ID
I also have POS Data table, with the exact same ID's.
Basically my questions are:
should I include the Customer ID in the Pos Data and Inventory Data tables, even though they are a part of both the stores and items tables?
My second question would be, if I do add the customer ID, if I would join all of these tables together,
would I join the customer ID from all of the tables (Pos Data, Stores and Items OR Inventory Data, Stores and Items) to the customers table or
would just joining from the Pos Data table be sufficient.
Let me give a few additional details, regarding the data. As an example, we have two Customers, CustomerA and CustomerB. CustomerA has several stores whose store numbers are 1000,1025, 1036 and 1037. CustomerB also has several stores, whose store numbers are 1025, 1030, and 1037. Store numbers 1025 and 1037 happen to be the same between customers, but the stores themselves are unique and completely different.
CustomerA's Store Number 1000 sells three of our items (this is a wholesale perspective), which are Items ABC, DEF and EFG. CustomerA's Store Number 1025 also sells three of our items, which are ABC, HIJ and XYZ.
Each of these items contains two import pieces of data, in regards to its relationship to its specific customer and store number, Point of Sale data and Inventory Data. Point of Sale data would be in the form of PosUnits, which would be the quantity of an item that were sold, and PosDollars, which would be the total Dollars of the item that were sold in that store (essentially the number of units times the price it was sold for). The Inventory Data would be in InventoryUnits, which is the quantity of an item that is in stock at a store. [one thing to note, I separated inventory and pos data into separate tables, because we don't always receive both pieces of data from every customer. Also inventory and POS data are generally analyzed separately].
So, back to my example, CustomerA's Store Number 1000, item ABC may have sold 100 units, which is $1245.00. CustomerA's Store Number 1025, may have sold only 10 units of the same item for $124.50.
Now if we go back to CustomerB, it just so happens this Customer also has an item named ABC that it sells in many of their stores. CustomerA's item ABC is a completely different product from CustomerB's item ABC. It's purely coincidental that they named them the same thing.
Let me add this last point of clarification, which I probably should have stated earlier. My perspective is as a wholesaler. When I say item, I'm speaking of the customers item number, not the wholesalers item number. There is a cross reference involved in getting to the wholesalers item and the customer may have more than one of their item number the reference the same wholesaler item number. I don't think it' necessary to delve into that, though.
Question #1: As part of the normalization rules, you should avoid to include redundant data in any table unless there are performance issues that require de-normalization. there are thousands of articles that will explain why avoiding redundancy.
As for Question #2: in the rules are only pick the columns that you need in your queries, if you need the Customer_ID pick it from where is cheaper for the database
Allow me to raise one more question
why do you have repeated Customer_ID in Stores and Item_level when you can join them thought the Main Inventory Data. this is another redundancy.