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?
Related
The company wishes to store the data of its current customers in the database, where each customer has a unique customer ID, name, address, country and country international telephone code. The company also wishes to have a list of future customers, so the company can send them
information about recent special offers. These future customers are nominated by the company employees and can be identified by their emails or telephone numbers. Once a future customer rents his first car, the customer record should be removed from future customer list and added into the list current customer.
should I create two entity for current customer and future customer? or one is enough?
It is never a good idea to move data around, because it is inefficient, slow and unnecessary.
Instead, represent an attribute as a column and update the column.
Keep just 1 table for Customers including future customers (prospects). Identify whether a customer is an actual customer or a prospect, using a column : Cust_type ('A' or 'P' for example).
Note that a prospect may become a customer and the reverse may also be true (if a prospect places a purchase order and then cancels it, for instance.) You have to keep this status updated.
Keep a separate table for all Customer Orders.
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.
I'm creating a small pet shop database for a project
The database needs to have a list of products by supplier that can be grouped by pet type or product category.
Each in store sale and customer order can have multiple products per order and an employee attached to them the customer order must be have a customer and employee must have a position,
http://imgur.com/2Mi7EIU
Here are some random thoughts
I often separate addresses from the thing that has an address. You could make 1-many relationships between Employee, Customer and Supplier to an address table. That would allow you to have different types of addresses per entity, and to change addresses without touching the original table.
If it is possible for prices to change for an item, you would need to account for that somehow. Ideas there are create a pricing table, or to capture the price on the sales item table.
I don't like the way you handle the sales item table. the different foreign keys based on the type of the transaction is not quite correct. An alternative would be to replace SalesItem SaleID and OrderId with the SalesRecordId... another better option would be to just merge the fields from InStoreSale, SalesRecord, and CustomerOrders into a single table and slap an indicator on the table to indicate which type of transaction it was.
You would probably try to be consistent with plurality on your tables. For example, CustomerOrders vs. CustomerOrder.
Putting PositionPay on the EmployeePosition table seems off to... Employees in the same position typically can have different pay.
Is the PetType structured with enough complexity? Can't you have items that apply to more than one pet type? For example, a fishtank can be used for fish or lizards? If so, you will need a many-to-many join table there.
Hope this helps!
I have a question about many-tomany relationship. I know that we have to create a junction table. But let say we have this scenario:
one table for Customers
one table for Orders
one table for products
One order can have many products and one product might be in many orders. Therefore we create a junction table.
Could I just create a junction table between Customers and products and this junction would be a Order table to store the Orders?
Thanks
If you do that, how would you know which products a customer included on a specific order? And, how would you handle the customer ordering the same product on multiple orders?
So, no, you can't just create a Customer to Product junction table because that will not give you the information you ultimately need.
I have a db with many tables. Some tables have unit price column, no tax, gst and such columns. What should i do now? Should i create GST table, HST table and PST table separately. In other words, what is the standard schema of designing the tax table?
You only need one table for tax percentages:
CDN_TAXES
tax_id (primary key)
tax_name (GST, HST, PST)
tax_percentage
Because HST covers both PST and GST, I'd model this as three columns in the PRODUCT/etc table and use a CHECK constraint to enforce that either the HST column be associated, or at least one of PST/GST is associated to the product.
The amount of tax per sale, should be stored in a SALES table. Tax tables in Canada are updated twice a year, and the percentage can change. Which means if you want to reprint a receipt that is accurate, you have to capture the tax amounts at the time of sale.
I think it depends. For storing the type of tax and a rate, sure, you can normalize it in a table - and even capture it changing over time with a start and end date (although the actual tax charged on a sale would always need to be stored).
However, typically you will need more tax configuration. In the US, for instance, we have some things which are never taxed (milk), tax free days when nothing (with some exceptions like cars) is taxed temporarily, and special days when certain things are not taxed (hurricane preparation items like batteries and generators).
So your product table would certainly not hold a tax amount, but may hold some tax flags. Other tables may link the product to a jurisdiction which has taxes. If you have a multi-store company, some jurisdictions may tax things differently, yet you may have a common product master file and pricing might be the same across stores, but taxes would vary.
I'd say depends on the amount of columns. If you're only talking about 3 columns then i'd add them into the table and leave them empty if not used.
If however you want to expand this further and further, create a single table to hold the value, description etc.
Then maybe have a lookup table called unitGST and unitHST etc. Each of these tables contains the unit id and the id to your single table holding the value.