I need help on designing database table for online store. Here is my class diagram :
So I wonder is there anything wrong with my tables? Because it all seems separated. For example, this is how my online store works. First, needy resident creates product which link the Store needy resident table to Product table. Then, when customer order product, the information of needy resident would be pass along from product table to ordered product table. After that, I check for payment. If the ordered product status is paid, the ordered product price would be pass to Payment table and from the Payment table, I can update my Store needy resident's sales amount. It's very complicated and I am quite blur of it also.
So my question is, can somebody please help me check if my class diagram got some error for linking?
Thanks in advance.
Related
I am making a system similar to our Play Store's star rating system, where a product or entity is given ratings and reviews by multiple users and for each entity, the average rating is displayed.
But the problem is, whether i should store the ratings in database of each entity with a list of users who rated it and rating given, but it will make it hard for a user to check which entities he has rated, as we need to check every entity for user's existence,
Or, should i store each entity with rating in user database but it will make rendering of entity harder
So, is there a simple and efficient way in which it can be done
Or is storing same data in both databases efficient, also i found one example of this system in stackoverflow, when the store up and down votes of a question, and give +5 for up vote while - for down vote to the asking user, which means they definitely need to store each up and down vote in question database, but when user opens the question, he can see his vote, therefore it is stored in user's database
Thanx for help
I would indeed store the 'raw' version at least, so have a big table that stores the productid/entityid, userid and rating. You can query from that table directly to get any kind of result you want. Based on that you can also calculate (or re-calculate) projections if you want, so its a safe bet to store this as the source of truth.
You can start out with a simple aggregate query, as long as that is fast enough, but to optimize it, you can make projections of the data in a different format, for instance the average review score per product. This van be achieved using (materialized) views, or you can just store the aggregated rating separately whenever a vote is cast.
Updating that projected aggregate can be very lightweight as well, because you can store the average rating for an entity, together with the number of votes. So when you update the rating, you can do:
NewAverage = (AverageRating * NumberOfRatings + NewRating) / (NumberOfRatings + 1)
After that, you store the new average and increment number of ratings. So there is no need to do a full aggregation again whenever somebody casts a vote, and you got the additional benefit of tracking the number of votes too, which is often displayed as well on websites.
The easiest way to achieve this is by creating a review table that holds the user and product. so your database should look like this.
product
--id
--name
--price
user
--id
-- firstname
--lastname
review
--id
--userId
--productId
--vote
then if you want to get all review for a product by a user then you can just query
the review table. hope this solves your problem?
So I'm fiddling with how you could design the basic db schema for a webshop. Sure, there's a lot of missing details here and there, but I just want to get the most basic stuff right.
Some basic requirements for the shop, which I'm trying to make a schema of:
The shop has an inventory of products. Each product has a price, but this price should vary depending on sales. Customers can make orders for multiple products at a time, and should be able to see their order history. When the order has been completed, there should be a track and trace number.
So, the following image is what I've come up with so far. I'm sure something is missing, I'm just not really sure what, also how to model the dynamic price aspect.
I think this is the according to your question give a flow of it how to create a schema and Additional that Link here please visit once you will find some amazing part.
A common way to handle variable price would be to introduce a rebate schema. This can be implemented as association class between Product and Sale by adding some rebate to amountSold. Of course there are many different ways, but this is one at hand.
I'm missing a relation between Order and Customer.
Not sure what you intend with the Inventory aggregating ProductList. To me a Inventory lists Product. There might be the need to a store location and a PurchasePipe
That's my class diagram at the moment:
I believe I can control the level of stock at each venue by the difference between the quantity of purchased ingredient and the quantity of beverage sold (as each beverage is composed by ingredient).
However, I have a requirement that should allow users to transfer ingredients between venues, and I am wondering what is the best approach for that...
A new purchase order would add the product to one venue's inventory, but how can I remove it from the other one?
Just in case someone get to this question, here goes my solution:
I decided to create a table transfer_stocks to register all the transfers between venues. This table is also used to solve any discrepancy when stock is counted (when recipient_id is nil, it means wastage or stock missing in the venue -sender_id).
The products in stock is calculated by de difference between purchases, sales and stock transferred.
My class diagram:
I'm fairly new at access and I have no clue how to handle this situation. I dont even know where to start so any help would be greatly appreciated.
So I have to design this data base that has items such as "audio board X.xx" When a customer orders lets say "audio board 2.4", the database will know that the board requires 2x4K Resisters and 4x2uf Capacitors and 2X4401 BJTs. And it would automatically pull them from the inventory when processing this order so later on I can just look at the inventory list lets say at the end of the week and will know what parts i would need to order to restock.
now, i looked for help online, the only thing i could find similar was something called "Bill of Materials" AKA "BOM" sheets or something... but none of them told me how to make one or anything like that.
I'm really new at this, and am a total noob. I'm using Access 2010. Any Help would be appreciated.
First, read http://r937.com/relational.html
You will need a design on the lines of:
Parts
ID -->Primary key
Description
Etc
Components
ID -->Primary key
Description
Etc
PartsComponents --> Junction table
PartID ---) ??
ComponentID ---)
If a part can have only one of each component, life is simple enough and PartID + ComponentID is your primary key, if a part can only have a set number of a particular component, it may be possible to treat the set as a single item, if the part can have a variable number of a component, things get a little more complicated. A quantity field in the junction table would probably work, though.
You then have a fairly standard set of tables for customers and orders, including an order detail table, which gets updated by an append query from the junction table information when a customer selects a part.
first of all sorry for my bad english hehehe I need some help, I want to design a database for a website, like a mini Amazon. This database will manage every kind of products (TV, cars, computers, books, videogames, penciles, tables, pants...), but also, each product must have some properties (that will be indexed) for example, if the product is a book, the properties will be something like genre, year, author. If the product is a TV, the properties will be something like size, color, also year. And if the product is a car, the properties will be something like year, color, model, for example. So, this is my idea:
One table to manage departments (like electronics, books...)
One table to manage categories of the departments, this table will be a child of the previous. If the department is electronics, here will be audio, tv and video, games... (each category belongs to one department, the relationship is one department to many categories)
One table to manage the products (each product belongs to one category, the relationship is one category to many products)
One table to manage properties (like year, color, genre, model...)
One table to engage products with properties, this table will be called ProductProperties
Im not sure if this is the best way, the database will be huge, I will develop the database on MySQL. But, I think this is not the best way, this article talks about "Database Abstraction: Aggregation and Generalization" http://cs-exhibitions.uni-klu.ac.at/index.php?id=433, in other words generic objects (I think), but this way is old (70s). In this article http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/ in the section "One table to hold all domain values" says that this is a wrong way... Im saying all of this because of the table ProductProperties, I dont know if I make this table or if I make especific tables for each kind of products.
Do you have any suggestion? Or do you have a better idea?
Thanks in advance, take care!!!
1.One table to manage departments (like electronics, books...)
2.One table to manage categories of the departments, this table will be a
child of the previous. If the
department is electronics, here will
be audio, tv and video, games... (each
category belongs to one department,
the relationship is one department to
many categories)
Why? One table, categories, forming a hierarchy. More flexible.
3.One table to manage the products (each product belongs to one category,
the relationship is one category to
many products)
Why? Allow m:n here. A product in many categorries.
Im not sure if this is the best way,
the database will be huge
Ah - no. Sorry. Nontrivial, yes. Hugh? No. Just to get you an idea of hugh - I have a db I am adding 1.2 billion rows PER DAY to a specific table. On average. THIS is big. YOu end up with what - 100.000 items? not even worth mentioning.
Pablo89, the description of what you want is very close to what the AdventureWorks database for SQL Server does. There are many examples of using AdventureWorks on the Web from web applicatons to reporting to BI.
Download and install SQL Server Express 2008 R2. Download and install the sample database for the above product. Inspect the database design for AdventureWorks.
Use AdventureWorks as examples in questions you may post.
I use AdventureWorks because I use SQL Server. I do not say it is better than other database products I say this because I know AdventureWorks.
I do not think that some database can work fast with 500,000,000 items. Complete tree of products categories for amazon.com contains 51,000 nodes (amazoncategories.info). Also the data is updated hourly, so saved product information can be incorrect. I think the optimal way is to store categories tree only get the product data at runtime using Amazon's API.