目录/订单系统的设计应用程序架构

Question

我必须编写一个允许客户订购产品的系统。现有的应用程序处理创建目录（添加，编辑产品等）。产品使用它来维护有关其产品的数据。现在我想知道如何添加订单功能（我可以访问目录应用程序和目录数据库的源代码）。订单功能可以简称为：

• 客户可以登录新订单，查看旧订单
• 生产者可以登录并查看客户发出的新订单，归档订单
• midleman应该看到所有按生产者分组的订单，以便他可以决定是否发货

我正在考虑几种方法：

使用新数据库创建新应用程序，该数据库仅包含订单。

目录数据库和订单数据库中的
• 产品将通过[producent_id，product_id]对
连接 在订单应用程序中

• 我将连接到目录数据库以显示有关产品的信息

  我能想到的那种方法的缺点是

  • 无法进行统计查询，例如“统计所有由木材制成的物品订单”等。

  优点

  • 明确与现有申请分离

向现有应用添加功能并使用相同的数据库

• producer在“Orders”菜单中有另一个选项
• 为客户和中间人添加新功能

我能想到的那种方法的缺点是

• 无法将订单数据库/应用程序移动到另一台服务器

优点

• 能够运行交叉订单/目录查询

我真的无法理解这一点。我可以看到两种方式的优点和缺点，但无法确定哪种方式更好。你有什么建议吗，也许第三种方式？

P.S技术将成为轨道上的红宝石

Answer 1

就个人而言，我会选择“为现有应用程序添加功能”。

我认为您不想单独销售订单应用程序，因为它完全取决于您的产品目录/产品应用程序的构建方式。

开发将变得更容易，不仅数据库访问，而且现有基础架构的重用将提高您的开发速度。

我认为您想将订单应用程序移动到另一台服务器的唯一原因是性能问题。我会说你永远不应该针对你不确定会发生的情况进行优化。

当您发现一些真实的，可衡量的性能问题时，进行不支持的跨数据库查询会更难以优化应用程序。

所以在我看来，开发速度超出工资假设性能问题。