java - 数据库设计决策

Question

我将设计一个商家应用程序。商家在系统注册后，他们将能够添加他们的产品、折扣、价格等。并且有智能移动应用程序可以访问每个商家及其产品。

所以关于数据库(希望使用MySQL)设计我有三个选择。

1. 使用一个数据库并使用单一表结构来维护名为merchant_id 的列的目录。
2. 使用一个数据库并为每个商家创建相同的表结构，并在表名称中使用唯一的前缀。
3. 每个商户在系统注册时使用具有表结构的单独数据库。在这种情况下将维护一个主数据库来保存商家的数据库信息。

我们正在开发一个应用程序来满足所有商家和客户的请求，并且将会有很多商家和客户与该系统进行交互。

目前我们计划使用 Spring MVC 和 Spring Data JPA。

因此，我很难在可扩展性和可维护性等方面做出正确的决定。非常感谢您的专业建议/推荐。

Answer 1

1) Use one database and use single table structure to maintain catalog with column called merchant_id.

这是最容易采取的路线。

优点

• 维护成本低。对数据库的任何更改都会影响一个架构/数据库。

缺点

• 数据库的扩展规模不会超过 X 个商家和每秒 N 个交易。

2) Use one database and create same table structure per each merchant with unique prefix in table name.

这是一种混合模型，如果处理不当，编写 SQL 并尝试跟踪哪个前缀属于哪个应用程序可能会很困惑。

优点

• 可以更好地扩展

缺点

• 每个表的维护开销；例如向表user添加一个名为created的新列需要您修改user_111和user_121等<
• 您可能会尝试将 user_111 与 access_121 连接起来，从而混淆查询。

Use separate database with table structure for each merchant when they registers with the system. In this case will maintain a master DB to keep merchant's db information.

这提供了最大的规模，但也给您带来了最大的维护开销。

优点

• 可以根据您拥有的客户类型及其提供的流量单独扩展每个数据库。

缺点

• 每个数据库的维护工作量很大，因为各个参数也在数据库级别进行了调整(SSD/共享缓冲区/与磁盘的 fsync 时间/写入缓存等)。

如果您一开始设计的系统不知道第一天会吸引什么样的流量，请选择#1。如果流量出乎意料地大，您始终可以垂直扩展，然后将高流量客户放在另一个数据库上(通过哈希机制将客户放入数据库存储桶中)

如果您预计站点流量足够大并且已经为客户规划了容量，请选择#3。您必须承担维护开销的重担，但至少您可以根据访问数据库的流量来扩展每个数据库。

我不喜欢#2，因为我看到这种方法让一些实现它的产品失望了。