我的想法是 商舖 shop 是一個表，用來保存商舖的資訊。 接著一個交易表，存在欄位shop_id,儲存所有商舖的交易記錄資訊。
這樣的表設計在數據量大的時候是否會有影響，有沒有更好的辦法，例如每個商舖的交易記錄都是一個表，但是感覺不好實現，因為商舖是可以動態添加的。
Mysql 在上千上萬條記錄中表現很好，這種設計可以跑的同，但是一個商舖有十個訂單平均，那麼商舖和訂單數據是10倍映射，當訂單數量相當大的時候影響性能。資料庫表也可以動態新增啊。所以你可以對訂單記錄進行分錶處理。但不能用自增的shop_id 作為外鍵，因為你分錶後，自增的id 基數回到零，就算可以手動設置，這樣很不方便，所以外鍵最好自己生成，方便分錶。產生唯一id的方法很多，你可以自己設計一套。
糾正一下我上面說的，其實我在開發中很少用到外鍵，外鍵這個東西是一個雙刃劍，建議看一下為什麼在開發中盡量避免用外鍵
Mysql 在上千上萬條記錄中表現很好，這種設計可以跑的同，但是一個商舖有十個訂單平均，那麼商舖和訂單數據是10倍映射，當訂單數量相當大的時候影響性能。資料庫表也可以動態新增啊。所以你可以對訂單記錄進行分錶處理。但不能用自增的shop_id 作為外鍵，因為你分錶後，自增的id 基數回到零，就算可以手動設置，這樣很不方便，所以外鍵最好自己生成，方便分錶。產生唯一id的方法很多，你可以自己設計一套。
我的理解就是設計一個商鋪表，還有一個交易表，交易表的外鍵是商舖表的主鍵，總的來說，MySQL還是可以抗住很大的壓力的，再就是可以利用一些開源的解決方案，或訂單表做定期分錶，關鍵看你怎麼實現。
糾正一下我上面說的，其實我在開發中很少用到外鍵，外鍵這個東西是一個雙刃劍，建議看一下為什麼在開發中盡量避免用外鍵