数据库设计决策

Question

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

关于数据库（希望使用MySQL）设计我有三个选择。

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

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

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

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

Answer 1

  

1）使用一个数据库并使用单表结构来维护目录   使用名为merchant_id的列。

这是最简单的路线。

<强>赞成

• 维护费用低。对数据库的任何更改都会使其成为一个模式/数据库。

<强>缺点

• 不会在数据库上超过X商家和每秒N笔交易。

  

2）使用一个数据库并为每个商家创建相同的表结构   表名中带有唯一前缀。

这是一种混合模型，如果你没有正确处理它，编写SQL并试图跟踪哪个前缀属于哪个应用程序可能会很乱。

<强>赞成

• 可以更好地扩展

<强>缺点

• 每张桌子的维护费用;例如向表created添加名为user的新列，需要您修改user_111和user_121等
• 您可以尝试通过user_111加入access_121来混淆查询。

  

为每个商家使用具有表格结构的单独数据库   向系统注册。在这种情况下将维护一个主DB   保留商家的数据库信息。

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

<强>赞成

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

<强>缺点

• 每个数据库的高维护，因为个别参数也在数据库级别调整（SSD /共享缓冲区/ fsync时间与磁盘/写入缓存等）。

如果你是通过设计一个你不知道它将在第1天吸引什么样的流量的系统开始的，那就选择＃1。如果流量意外地大，您可以始终垂直扩展并将高流量客户放在另一个数据库上（通过将客户放入数据库存储桶的散列机制）

如果您希望网站流量足够大并且已经为客户规划了容量，请转到＃3。您必须首当其冲地承担维护费用，但至少您可以根据达到的流量来扩展每个数据库。

我不是＃2的粉丝，因为我已经看到这种做法让一些产品失效了。

Answer 2

在我看来，选项1是要走的路。我看到的好处是，您可以使用聚合查询来处理此表，以对每个商家执行计算，例如：您的管理员视图希望查看上传产品数量最多的前20位商家。

您可能在选项1中看到的缺点是此表将是巨大的。这可以通过分区技术和正确选择的索引来解决。

选项2和3并不好，因为它们会在架构中引入冗余。

此外，您可以考虑使用JPA，您的实体类自然地映射到表，但我认为每个商家的表前缀对于破解JPA会很痛苦。对于选项1，这也是+1。

您在选项2和3中看到了哪些好处？我没有看到任何优势，只有缺点。