想問一個電商問題
假設還不是該網站會員的時候，可以將商品加入購物車並在最後購買
而最後一步付款成功後則會將該資料建立為會員
所以之後可以使用登入
但假設在不是會員的情況下可以加入購物車一直到購買的這段行為
大家會怎麼處理才是好的方式呢？
購物車資料表
會員資料表
我這邊目前想到的做法是
當非會員加入購物車時，購物車資料表的會員ＩＤ會是ＩＰ
而購物車>寫配送資料>寫支付資料 這幾頁都是需要會員才可以操作（或不該設限會員？）
已邀請的邦友 {{ invite_list.length }}/5
購物車不一定要往資料庫寫呀
也可以寫在
cookie
session storage
local storage
之類的地方
根據你的需求以及不同方法的特性
來決定用哪個
e.g.
cookie 基本上在清掉前都會存在 browser
不過他會有 expire time
session storage 在 頁面 或 browser 關掉前都會存在
local storage 則是除非主動清掉
不然都會一直存在
然而這幾種方法
都需要考慮 data 的 正確性 及 安全性
因為 User 都有辦法去竄改這些資料
不過本來就不應該直接相信 User 傳過來的任何資料
也沒有說購物網站一定要怎麼做
例如你的需求只是
1 . User 選完商品後加入購物車
2 . User 填寫完資料並完成付款
3 . 有個媒介可以通知客戶
這樣的話最簡單的
你只需要有個
訂單(紀錄訂單資料, 用戶配送資訊, 用戶 email)
金流驗證
就能達到目的
這個大概就像
把 FB 上購物那套玩法實例化
反正他只需要知道
你付完錢
你東西要寄到哪
就好了
然後你可規畫一些加入會員才能使用的功能(e.g. 查詢購物記錄)
User 如果想要使用那些功能
在自行考慮要不要加入會員
尤其現在很多人看到要加入會員就很懶(e.g. 我)
除非必要不然不會考慮
總結
你高興就好
沒有一定要怎麼做
看你的需求
以上僅供參考
所以不一定一定要丟到資料表去，可以先存在ＳＥＳＳＩＯＮ
這裡指的session 是瀏覽器的 session storage
不是 php 的那個 session
為什麼不能用 php 的 session？
沒有不能用
只是我上面提到的是 瀏覽器的 session storage而已 
至於 php session 適不適合
就看你的需求了
了解
順便問個問題
假設該商品有多個標籤可以設定
你會用一對多的方式分兩個資料表做關聯性
還是在商品加開一個欄位用逗點？
一對多的方式分兩個資料表做關聯性
不太懂
還是一樣要看需求呀
不過切逗號的話
一些過濾等安全性的檢查
是必須要做的
dragonH的做法是正確的，小松菜奈您先思考一下，為何用cookie、session storage、local storage，而不用 php 記錄 Shopping Cart的資料。
先評估一下這種架構好處與壞處。別太急做下去。這是程式架構的問題，未弄清楚寫下去，會害慘自己。
你會用一對多的方式分兩個資料表做關聯性
還是在商品加開一個欄位用逗點？
小松菜奈您這樣問，人家很難答您的，都已經超出您本來的問題。我也過想答您的，但估計會越問越離題，幸好有dragonH把最基礎的解答了您。先品嘗一下，dragonH的理念。
為什麼不能用 php 的 session？
有沒有想過，顧客放在購物車的物品，顧客是否一定會購買？
若果顧客只是存放，沒有打算買的意圖，您打算用多小系統資源來處理這些可能永遠都不買的物品(不要小看這些數據的佔用率，及系統的負荷率)？用cookie、session storage、local storage來分擔系統資源的損耗，是一個很有效率的方法。
一般來說都會先登入,
你有看過哪個購物網站買東西沒登入的嗎?
除非沒有會員制,
不過購物網站通常不會這樣搞,
只要有金錢交易的都要比較小心.
最好是實名登入.
有喔:D 可以參考GOSHOP的結帳流程
https://store.goshoptw.com/
你先隨便找個東西加入購物車
然後結帳，付款部份我是選7-11取貨付款
最後一步可以不需先加入會員就能完成訂購程序
我之前有在這個網站買便宜電繪板給小朋友玩
原來是這樣,
我們買東西的地方都是要登入的.
zara 好像也是
這我不會說太多。一般像這類需要自動處理的。我會選一個必要代表性的為主。
一般第一優先會先用email，再來就是用電話。很少人用住址(太長)
不過我也遇過是用住址的。
用ip並不太好，因為這很難當代表個人的資料。因為ip並不是個人專有。
所以並不建議用ip當key。
iThome鐵人賽
看影片追技術