電子商務網站的數據庫結構

Question

我的任務是設計一個電子商務解決方案。 引起我最多問題的方面是數據庫。

目前，該站點由10多個國家/地區的商店組成，每個商店都有自己的數據庫（都位於同一個mysql實例上）。

對於新站點，我希望將所有這些shop數據庫合並到一個數據庫中，以便所有表（產品，訂單，客戶等）都具有shop_id字段。 從編程的角度來看，這似乎是最有意義的，因為我們不必跨多個數據庫管理數據。

目前，整個站點每年產生約12萬個訂單，但是正經歷相當大的增長，我們需要設計一個可擴展的解決方案。 在5年內，每年可能有超過一百萬個訂單，而一個包含5年訂單歷史的數據庫（在此處存檔可能是一個解決方案）。 問題是-我們使用單個數據庫，還是保留“每店數據庫”結構？

我目前正在嘗試尋找這兩種途徑的佐證。 我正在設計解決方案的公司偏向於按商店數據庫結構，因為他們認為這將允許站點擴展。 但是我的觀點是，在未來幾年中，商店的數據庫可能不會變得忙碌，因為它們超過了mysql數據庫的容量以及“無余開支”的硬件設置。

我想知道是否有人有任何建議？ 有沒有人對具有包含數百萬條記錄的表的網站/電子商務站點有經驗？ 我知道這里可能沒有明確的答案，但是在哪個階段，我們的記錄太多或表文件太大而無法快速加載站點？

另外，如果有人對我可以做進一步研究的信息源（書，網站等）有任何建議，將不勝感激！

Answer 1

我已經實現了劇院門票銷售解決方案，該解決方案的表具有數十萬條記錄，並且沒有性能問題可言（硬件沒什么特別的）。 雖然很難比較負載，但我想說數據量增加10倍不會明顯影響性能。 如果是相同的應用程序和相同的架構，我很可能傾向於單個中央數據庫（可能具有故障轉移），因為：

• 維護效率更高，更不易出錯
• 您可以進行跨商店報告
• 如果性能確實受到影響，您始終可以將歷史數據卸載到歷史表/數據庫中

以及其他一些原因。 具有多個實例的明顯優勢是您可以獲得窮人的高可用性：如果一台服務器宕機，則只有一間商店無法正常工作，而您可以立即解決此問題。

Answer 2

我認為保留單獨的數據庫比較容易。 將這些沒有直接關系的實體進行邏輯分離只是更有意義。 FAR也將更易於擴展，這樣，如果時間允許的話，每個站點都可以在單獨的硬件上運行。 在單獨的實例上，備份/還原和常規維護程序也將更加容易，因為它允許每個車間進行自定義的程序。 任何災難情況也只會影響一個邏輯數據庫，而不可能破壞每家商店。

您當前的建議將意味着幾乎每個表都需要一個“商店ID”列，該列也已進行索引以防止沖突。 以后在需要擴大規模時分離這些數據不會有太大問題，但是重新編程很可能會非常耗時。