I have a web application in which I want to create a section to fill receipt information.
I need some information such as customer ID, customer name, customer address, customer tellephone number, product ID, sales agent ID, order number, and order date. The customer ID, order number, order date, agent ID and product date will be stored in one table.
Will it be better to
generate the customer id using the mt_rand() function in PHP based on some criteria so that this info gets directly to the order table without any further queries or to
generate this ID in MySQL and query the database again to get this info and store in the order table (and I will need to store the customer ID in who bought a specific product in the orders table).
Which approach is better? Is there another approach that I should consider?
You can make use of AUTO_INCREMENT in MySQL. For example,
create table
( INT AUTO_INCREMENT) )
Let the id generation be taken care of MySQL instead of having your code generate a number and store it in database
you can also use to SELECT uuid() in phpmyadmin
Related
I am developing an online inventory management system. I have one table for the main inventory which consists of the product names, quantity and barcodes etc. I want users to log into the system each morning and log the quantity of each item they take. I then want to store this information for the admin to view. I have developed the system so that a new table gets created each morning based on the users name and date. This is allows the user to input the quantity for each product, i then subtract that column from the main inventory table when the user clicks submit. I want to know if this is a bad practice, is it necessary to create a new table each morning? If not what method should i use?
I think you should maintain a single table for inventory, and then after a create a temporary table to store the list of items the user takes which will contain the user id, inventory id, qty etc, and then update the quantity of inventory in inventory table, whenever user picks the inventory.
In short you should create a single table to store the information of inventory which user takes instead of creating a new table each day.
Insert and fetch data according to date + user.
I wonder if you are creating new table everyday, you should not create new table in any case. In the rarest scenario even if your columns are dynamic then create a table with rows representing as column and use pivot to fetch the record. For your use case you just need to have a table which stores a new record and subtract the count from main table.
I am trying to understand the database design for an e-commerce site. I am having trouble understanding on what to do in the following situation. Say the user creates an account for the first time, and makes an order. I can write php code which will add the user_id (primary-key), first name & last name. But what if I want to add the user_id in the orders table (user_id in the orders tables is a foreign key). How do I get the value, as the user_id in the customers table is auto incrementing?
Are you using two tables one for storing user details and other for placing orders ?(which is better) If so my recommendation would be to use username (not first name or last name) as primary key and store the username as SESSION variable for each login and for each order add the username in order table along with orders details
There are couple of ways to do that, you can access the newly generated user_id by LAST_INSERT_ID() and use it in subsequent transaction, or you can store it in session and use it later when inserting in Orders table.
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 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
I have a software in PHP and postgres that I use for invoicing. I am running a stock management system that I created. i am trying to create a stock movement page where I can see when a part came in, where it was issued and when and also when it was credited (if it was). I am running 5 tables for the stock. My main one is part2vendor, parts, expenses, wo_parts and int_part_issue. When I receive stock, it goes into the table part2vendor (onhand gets increased by number received). The expense table gets the details of the part number, the supplier invoice and the date received. wo_parts stores the part number issued to a workorder. int_part_issue is when I do a stock adjustment or use a part internally. I am looking to create a PHP table that would list (in date order) the 'paper trail' of a part. I can let you know table names and columns if required. Thanks.
Sounds like you need a simple history table?
Columns
part_history
id
part_id
date_modified (timestamp)
action ( or maybe action_id if you have an actions table)
vendor_id
And when you get a new part, and add it to the parts2vendor table ( i think u said) you would use the inserted part ID (or unique part id ) to add a record rto history
INSERT
(id, part_id, action, vendor_id)
46565, 5757575, "Purchased", 757575
The date will be inserted as a timestamp by postgres
Than for any part yuou can grab history relying on the uniquer id
sort by date_modified DESC.