Ok, so my site is just like "Post Your Order" rather than the usual online payment method since I will be shipping the item first then the cash which is the Cash On Delivery offered by Shipping services here.
I have a users table which have user_id, email, password, first and last name, etc.
an user_order table which have order_id, user_id_fk, order_status, order_placed, address_id_fk
an order_items table which have order_item_id, order_id_fk, product_id, quantity, size_id_fk
address table address_id, user_id_fk, street, city, province, etc
So, if the user is registered it's easy to do this since i would just link their user_id to the user_order table and the address from their address_book
My problem is, how do i do that with guest checkouts? I'm trying to avoid them to be forced to register even though it's easy.
What on my mind right now is to just insert them to the users table too, but with their password as NULL and just make a guest group and put them to that group.
But that may cause a problem, email in my users table must be unique, guest checkouts may happen more than once from the same email soo... now what?
should i just add column to the orders table? another, name, email, address? so it's not tied to the users? that's possible but there's a feature i would like the registered user to have... to track their Order History.
Help please... Thanks :D ;)
I agree with "Drew Pierce" but from other side to give you another option
first you should read about eCommerce platform (for example OpenCart), how they drive this stuff.
second you don't need to add the each guest to the user table for the following:
1- guest does not have any right to see the history of orders or ... etc
2- email field must be mandatory in checkout and there is notification email will send to him also (maybe you add confirmation email.. up to you).
3- all what you need to save in your DB is the order details in the order table
4- all the process between you and the guest will be via his email
5- he do not have right to track any order or see his activities till he become a real user
6- order details must always has the all detail about the user even if he is real user (it will be duplicated data for real user but the user can change his email or phone number in any time, where he can not do it for the old order ,, so you always know the real history of the orders)
7- in the user table, there is only one guest user but in the order table there are many orders and each order has its details, email, phone number ,,, etc
the main thing is getting their money. if they want to remain a guest let them. remind them that only users registered can receive promotions and see prior activity. prior activity while not a registered user WILL NOT be seen later.
let's say they have 10 orders from that email address. so what, put them in as new users each time and plop their email addr in there. flag that user as a guest. so 10 new guest type users for grandma@blahblah.com. No email goes out. afterall, people could be spoofing the system using some poor grandma's email addr.
now they want to be a registered user. email is sent and they have to click on it to become a user (link in email).
now that 11th purchase is from a registered user (grandma@blahblah.com). Order history: 1 order.
seems strait forward to me.
I would recommend doing as you thought, just add the user and add a column 'guests' int(1) where if the user is a guest, this value is set to 1 and if not, 0.
Then just set the password to an empty string too.
For usability reasons, you might actually want users to be able to see past orders placed with their e-mail address. The billing e-mail field answers the question "whom do you authorize to view this order?". This way, grandma@blahblah.com can place several orders, and then once she actually registers (by changing her password), the past orders placed as a guest will be there for her to track. So try this flow, sometimes called the shadow profile pattern:
users table, create the account with a zeroed password hash and a null confirmed_on date.is_guest column to user_order.confirmed_on is not null, require the user to log in. This means all orders prior to confirmed_on are guest orders, and all orders afterward are logged-in orders.Send the guest an e-mail receipt containing a password reset link. Make sure this goes out with correct SPF and DKIM records. Label the link with something like this:
Sign up to manage your orders with $store_name.
In rare cases, you may be listed as the billing contact for an order that you did not place. If so, follow this link to cancel the order.
When the user first follows an e-mailed password reset link, set the confirmed_on date.
If someone who is not grandma@blahblah.com enters grandma@blahblah.com on a guest order, the real owner of grandma@blahblah.com would get the e-mail receipt and thus a chance to cancel it.
The other way is to associate orders to sessions rather than users. You're probably already making a random session ID (and storing it in a cookie) to distinguish a guest's cart from another guest's cart. So change the user_id_fk in your user_order table to a session_id_fk. Then link session IDs to user IDs in whatever user_session table you're already using.