I have a list of users with information, currently at like 60+ and a list of products that users could have, which contains like 15 products as of right now. Both lists will grow with the users one growing at a greater speed than the products one.
Is it better to add a products field to the users table and just keep the products there or should I make a separate table for products and under each one, add the users that own that product.
Or does it just not even matter.
One user might have more than one product, so a join table is a good option.
Related
I have three tables: items, sold, and invoice. The item table tracks individual item prices and descriptions, the sold table tracks items the belonging to a particular invoice, and Invoice tracks the date and other information. Invoice has a one-to-many relationship with sold and sold has a one-to-many relationship with items.
Here are the relevant columns in my tables: invoice(invoiceID, total) sold(soldID, invoiceID, itemID) item(itemID, description, price)
I currently have no way to track the total price for the invoice without manually summing the items. The total column in invoice must be manually inserted.
I'm looking to create a trigger the finds all the rows i sold that have a matching foreign key for invoiceID, then adds the prices of the relevant items and outputs that to invoice.
If this is not possible, I could also add a new price column to sold, then use multiple triggers to eventually work my way up to invoice.
I'm not in a position where I can make any significant changes to the structure of the database, so if possible it'd be best to keep the fields and relationships as is.
If anyone has any input on how to create this trigger it'll be greatly appreciated.
#stickybit is exactly right. You don't want redundant data. You should not put any sort of derived total in an invoice record. Instead you should get it with a query or a view.
It's sometimes hard for people new to using SQL to believe, but queries and views are typically just as quick for retrieving aggregates like totals.
Views and tables look precisely the same from the perspective of application software. So make a view of your invoices that shows the totals. Something like this.
CREATE OR REPLACE VIEW invoice_with_totals AS
SELECT sold.invoiceId, SUM(price) total
FROM sold
JOIN item ON sold.itemID = item.itemID
GROUP BY invoiceID
Believe it or not, doing things this way with views will save you (or the people who will use your application) all kinds of troubleshooting craziness in the future. If you do things this way, there's simply no possibility of your totals disagreeing with the details in your invoices. If you use a trigger, that's not guaranteed. And, you know, Murphy's law, big customer, incorrect invoice, you get the picture ....
I have hard-won experience backing up my suggestion. I suspect #stickybit does too. Please consider it.
I am developing a classified website by using ASP.net and my DB is MYSQL.
In there I am using a header table to store common records of an ad. like ad title, description, published date like wise. And I am using separate tables for store job category, real estate and vehicle categories etc.
Now I noticed that the column of many categories are identical. so now I have two approach
1) Follow the current approach ( 1 header table and separate tables for each categories )
2) Add extra columns to the header table and store all data in one table and maintain a column to identify the category of the ad.
So which is better by considering the performance when each category have millions of records.?
If you have questions to clarify to give an answer please ask.
Thank you very much
It depends on how you will use the categories, if you have to search or aggregate across multiple categories then one table is probably better, if you have lots of categories, then again one table is better.
How much of a performance penalty will you really pay for having to select records based on the category if you have a suitable index set up?
I have designed an ERD for a website I am about to build.
This website has 2 groups: the USER and the COMPANY. Different companies (or shops, to be precise) have the option of logging into the site and enter new products into the system. The users can then log in and view products based on brands and categories.
In the ERD I have created all the tables, fields and one-to-many relations to the best of my knowlegde. I think that went well until the category tables.
I want the products to be categorized in like "MEN&SHOES", "KIDS&CLOTHES". I figured out I am going to need 2 tables for that: CategoryPersonGroup & CategoryProductGroup. But I do not know what is the right approach to link this to the products table. Please help! This is my ERD:
I think many to 1 relations between product and category tables would be convenient such as:
Product (N) -- has -- (1) CategoryProductGroup
Product (N) -- has -- (1) CategoryPersonGroup.
You can use inheritance approach to this matter, i.e. make category table to store any values that are common to all the articles, and then make separate tables that will inherit category table, in which you can store your own values for that tables. And that's it, just link the main category table to persons and voila.
We have a products table. Users can create new products as copies of existing products.
Instead of simply duplicating this data, we're thinking in order to minimize database size, we would store only the differences from the "parent" product. (were talking thousands of products)
My thinking is that, for each new "child" product, we create a new record in that same table which has a "parent" field which has the ID of the parent product.
So, when querying for the "child" product, is there a way to merge the results so that any empty fields in the child record will be taken from the parent?
(I hope this makes sense)
Yes, you can do this.
Say for example Your table name is Product and you want to retrieve name of child product, Then you can query as,
select IF(c.productName = '',p.productName,c.productName) as childProductName
from Products p,Products c
where c.ID = p.ParentID
Similarly you can do this for other fields.
I would anticipate that you'd want to have child products of child products (e.g. product C is based on product B, which is in turn based on product A.) And there would be children of those and so on (especially with user generated content.) This could get out of hand very quickly and require you to make either long cumbersome queries or collect the data with code rather than SQL queries.
I'm just offering this as a consideration because the saving is size often yield a cost of processing time. Just be sure you consider this before you jump into something that can't easily be undone.
Suppose i have tables
Products -------product_id , name , price , size
shopping_cart------cart_id,item_id,user_id,quantity
order----order_id , user_id ,totalprice , date
orderHistory---------user_id , item_id,date,order_id
I am confused how should i store shopping history because if i store item_id , then there may be the possibility that some product may be deleted , then what should i display in history.
There is possibility that price , size , other dimension of that product changes with time but in history i don't want to change
so how should i design the database
For the product deletion issue, try including something like an "Active" (boolean) field in the product table. This way you don't need to physically delete products, just deactivate them. Then you can build your code so that inactive products don't show in the catalogue, but they are still available in your database to show in the order history section.
I'm guessing you're trying to create something like an "OrderLine" table with your OrderHistory table. You should only need to link this to products, and your order header (Order) tables, you don't need to link it to users as the order header table is already linked to a user. If you add some additional fields like "quantity" and "price" to the OrderLine table then you can create a snapshot when the order is placed, and insert the price (at the time it was ordered) and the quantity ordered into you order history table. This way if the product price is changed over time, the information in the OrderLine table remains the same and you still have the original price.
You could still build some entities for save product history (price etc) if you wanted to hold this to show price trends, but in terms of maintaining your actual order information its not necessary.
This approach means your shopping cart table could used as a "work in progress" repository where you are only storing current carts, and once the order is completed the cart is emptied and the data inserted into your order header and order line tables.
This doesn't cover everything, but hopefully gives you some ideas on approaches you could take in regards to your questions.
I face the same problem right now, and I am solving it basically by duplicating the relevant data into a secondary table, that the order history models can look at. They will never change, and never be deleted.
This way, if prices change or titles change, you'll have a snapshot in time of the order.
Another way would be to create versioned products, and store the specific version id. When the product changes, the displayed version updates to the newest product ID.
You are duplication history either way.
In my opinion you should have a table between order and product in which you can store the information of order and product. you can use order history table for this purpose. Just store the at time of shopping information in that table. It should be a good practice to do in my opinion.
Even if the actual values changes in product table you dont need to change the values in order history table. Just touch that table only at the time when user do some kind of shopping otherwise you dont need to do.
I also suggest you to create a customer table and store customer information in that table and use also customer id in orderhistory table also. It will help you to classify the history even with respect to customer