目錄/訂單系統的設計應用架構

Question

我必須編寫一個系統，允許客戶訂購產品。有一個現有的應用程序可以處理創建目錄（添加，編輯產品等）。生產者使用它來維護有關其產品的數據。現在我想知道如何添加訂單功能（我可以訪問目錄應用程序和目錄數據庫的源代碼）。訂單功能可簡短描述爲：

• 客戶可以登錄作出新的訂單，看到舊的
• 生產商可以登錄並看到客戶提出了新的訂單，訂單歸檔
• midleman應該看到分組的所有訂單製片人讓他可以決定是否不把它們運

我正在考慮幾個方面：

創建新的應用程序與新的數據庫，只包含訂單。

• 產品目錄數據庫和訂單數據庫將由在訂單中的應用[producent_id，PRODUCT_ID]對

• 連接我將連接到目錄數據庫，以顯示關於產品的這種方法的

  缺點信息，我能想到的是

  • 不能進行統計查詢，如「統計木材製成的類別中所有項目的訂單」等。
  個

  優勢

  • 明確分工，從現有的應用程序

功能添加到現有的應用程序，並使用同一個數據庫

• 生產者有在菜單其他選項「訂單」
• 爲客戶和中間商這一做法的

缺點添加新的功能，我能想到的是

• 不能夠移動。例如訂單數據庫/ aplication到另一臺服務器

優勢

• 能夠運行交叉訂單/目錄查詢

我真的不能對此做出我的想法。我可以看到兩種方式的優缺點，但無法確定哪個更好。你有什麼建議，也許第三種方式？

P.S技術將在軌道上

Answer 1

紅寶石個人而言，我會去的「功能添加到現有的應用程序」。

我不假設你想單獨銷售訂單應用程序，因爲它完全取決於你的目錄/產品應用程序的構建方式。

開發將會更容易，不僅數據庫訪問，而且現有基礎架構的重用將提高您的開發速度。

我想你想將訂單應用程序移動到另一臺服務器的唯一原因是性能問題。我會說，你永遠不應該爲一個不確定它會發生的情況進行優化。

如果不支持跨數據庫查詢，那麼在您注意到一些真實的，可測量的性能問題時優化應用程序會更困難。

所以在我看來發展速度加快了工資應有的性能問題。