I am doing this project, which is basically few modules from an ERP using PHP/MySQL (codeigniter framework).
I'm not sure how should I integrate the Order Placing mechanism (and other multi table dependent) features.
Eg. Customer's Order is managed by two MySQL tables, (Order and Order-Detail).
Order tables stores general order information, while Order-Detail stores ordered product information (quantity etc.), since an order can have more than one product ordered.
So, my questions are:
How is this thing basically implemented (the logic behind it)?
How it is called in the industry jargon (so I can google for ready JavaScript/AJAX or PHP libraries or snipets)?
The term for this is relational databases
You can achieve building a relational database using either mysql itself using 'innoDB' driven tables.
The logic behind it is the following (in your case)
You have 3 tables:
- Users (with userid, username, userpassword, etc.)
- PlacedOrders (with orderid, userid, productid)
- OrdersDetails (with orderid, productid, orderdate, ammount, etc.)
- Products (with productid, productname, productweith, etc.)
Here all the '...id' names are primary keys
For users the primary id is userid
For placedorders the primary id is orderid
etc.
But some tables also have another '..id' that is the primary id from another table.
like userid in the table placedorders is the primary id from users
These id's are called foreignID's
These foreignID's are linked to eachother.
The logic behind it is that for the table placedorders you won't have to include the user name or password, stuff like that.
This prevents redundancy and can improve database efficiency when you have a lot of data.
Just one more hint about how this would be used in a website:
A user first logs in using data from the table users.
Then he goes to the product page and selects the product and the ammount he wants to order.
Now when placing the order an order will be made inside orderdetails
And a all the variables (orderid, productid and userid) will be combined in placedorders
Now for the user this isn't an improvement.
But for you (or the shop) it is.
This way to see who has ordered what using data from just the placedorders table
This way you can make a (search) page where you are just one click away from seeing the users' data, product detail and order detail.
Now with some handy scripting you can easily grab the appropriate data from the product, user and order and put these on one page while you don't have everything inside one big messy database
Related
This is a fictitious example to try to illustrate some design choices I have...any thoughts or links deeply appreciated.
Imagine we have a MySQL database with a table (call it libTBL) that contains a row for each book in a library.
This table will be updated, by admins, as new books are added.
Users will be able to create a library of such books - that is, a list representing THEIR selected books.
Users can add a personal, private comment to each book and other meta data (when they started reading it, a review etc).
Users can also add their own books, but these books should not appear in the libTBL table.
What are best practices for capturing this user data?
When a user is created, create a row in a new table, with each book in the libTBL represented, so IF the user adds notes or other data we already have a home for it?
Create a new row in a user library table only when they make a note on a specific book?
-- One use case, though, is a user ordering their subset library...which would require a new row for each book they order (or all of them, depending on how ordering was implemented).
Use bookID and userID to query a user table for custom values for a particular book?
I have to develop a shopping site where I need to maintain data like "Add to Cart" and "Previous Orders" for a single user, for N number of users in a database. E.g. if there is a user named "Mark" and I need to store his 5 items previously added to cart and 4 items as previous order and there are say 100 users like him whose data I need to store, How should I solve this problem? I am using PHP and MySQL.
Each user is assigned a unique ID (you can exploit MySQL's AUTO_INCREMENT for this purpose when creating the table of users.
Then, for items the users select, you create another table including the User_ID (from the previous table), the Item_ID (from a similar table for items), the status (that would indicate the status of the item for the specific user) and an optional field that would contain the order number when the user places the order (for one or more items).
In summary, and since you are actually asking for help in designing your database, I would suggest you sit with a pencil and a piece of paper and make lists of informational elements that you need, marking the one-to-one relation between them (when applicable). This will (approximately) suggest what needs to be arrange in a record of a table (e.g. all the stable details of a user would normally go together into a single table).
I've been doing a lot of searching and reading about rating systems, but couldn't find a solution to what I'm trying to achieve...
I have a website where users, once logged in, can submit a product. Now I want other users to be able to rate those products according to 3 different criteria. I'm using php and mySQL databases to store all of the information which is working great, I'm just not sure how to incorporate the ratings now.
At the moment I have a PRODUCTS database, which holds various tables according to their category. Here's an example of a table:
TOASTERS
---
ID (auto-incrementing)
Brand
Set
Number
Name
Edition
Image (stores the location of the image the user uploads)
Any user can then rate that row of the table out of 10 for 3 criteria (Quality, Price, Aesthetic). The user average of each criteria is displayed on each product page but I would like to store each of the user's individual ratings so that I can show a short history of their ratings on their profile page. Or have a live feed of the latest user ratings on the homepage.
What I'm trying to do is quite a lot like awwwwards.com. (See bottom-right of page to see the livefeed I'm talking about)
Thanks in advance!
I think you should use single PRODUCTS table or at least create PRODUCTS table and emulate inheritance between it and category tables.
Having a table for each category can give some advantages if each category has some specific properties, but it can lead to neccesity of writing separate code to work with each table. Alternatively you can use two tables to store all custom properties 'vertically': PROPERTIES(propertyID,PropertyName), PROPVALUES(productID,propertyID,PropertyValue).
If you choose to have multiple tables and emulate inheritance, it can be achieved like this:
PRODUCTS
---
ID (auto-incrementing)
Brand
Set
Number
Name
Edition
Image
VoteCount <+
SumQuality +-updated by trigger
SumPrice |
SumAesthetic <+
TOASTERS
---
productID (PK and FK to PRODUCTS)
(toaster specific fields go here, if any)
Than you will be able to create table VOTES, referencing table PRODUCTS
VOTES
---
productID (FK to PRODUCTS)
userID (FK to USERS)
Quality
Price
Aesthetic
VoteDateTime
If it is true that overall product rating is queried much more often than voting history, as an optimization you can add fields VoteCount, AvgQuality, AvgPrice, AvgAesthetic to PRODUCTS table, as srdjans already supposed. You can update this extra fields by trigger on table VOTES or manually in PHP code.
Create separate table for storing user individual ratings (primary key, user id, product id and ratings). Create additional fields in "products" to store averages. Every time some user rates some product, you insert record in "ratings" table, then calculate averages again for given product, and update rows in products. Doing this you will have easy access to ratings, and also, you can analyse user individual ratings.
Ps - You may also wish to store how many users rated some product.
I need to keep all purchases from a single client together on a database table (It will be atored in my Orders table) and once someone is browsing a product, the system will search the dB for clients that bought that product and recommend the other products they bought (you will need to check for popularity of the other products and avoid repetition)
The data will be stored in a mysql database in a table called Orders. I then need to be able to search that database to see if other people have bought this product and if so which products they also bought.
So I've come up with this query
SELECT ProductName FROM Orders
(I have little knowledge and would like to no if I am on the right track)
I need to keep all purchases from a single client together on a database table
For this one you probably need to create a horizontal view (restricting by the client id you need to monitor the purchases) CREATE VIEW.
Could you provide your database schema ? in order to create the query you need you should join many tables, so it would be easier to provide the schema and how your tables are tied together.
try this
SELECT ProductName
FROM Orders WHERE client_id in
(SELECT client_id
FROM Orders
WHERE productname="ProductName ");
I am building a web application that has users and orders. I have a question about how to handle the relationship between the two.
An order belongs to a user. But here's the twist, a user can optionally choose to outsource an order to another user.
When an order is outsourced, the original user still remains the owner and only he can modify certain things like price, quantity etc on the order.
The user the order is outsourced to can view some of the order information and can update specific properties on the order like marking as fulfilled.
An outsourced order should show up on both users "orders index".
All the users are "equal" meaning on certain orders a user might be the owner and on others he might be fulfilling the order. A user can also fulfill his own orders.
It doesn't seem like a true many to many relationship as one of the users doesn't really own the order, he just has limited access to it.
What would be the simplest way to handle this order/users relationships? I would like to avoid using a complete permission system, is there a way to simply handle this with an "outsourced" table? How about having a user_id and outsourced_to field on the order table?
Thanks for your input!
If it's of any help, the application uses Laravel.
It seems like your Orders table has two separate relationships with the Users table.
Orders have an owns/owned-by relationship to Users.
Users(1) -- owns -- (*)Orders
One User can own many Orders. One Order is owned by only one User
Then there is a completely separate outsourced-to relationship between Orders and Users.
Orders(*) -- outsourced-to -- (1)Users
(Here I assume that an Order can only be outsourced to one other User. A User may have many Orders outsourced to them.)
The best way to represent this is to have the Orders table have a 'owner' foreign key column into the Users table and another 'outsourced_to' foreign key column also to the Users table.
What columns of Orders the outsourced user can edit will be controlled by the code and not by the dB.
A separate outsourced table will be needed only if Orders can be outsourced to multiple Users at the same time.
How about having a user_id and outsourced_to field on the order table?
Sounds good.
Also, think about a kind of de-normalization, like moving fields, which editable by "outsorced-to" user to separate table.