数据库设计决策答案

【问题标题】：Database design decision数据库设计决策
【发布时间】：2015-04-16 20:19:37
【问题描述】：

我要设计一个商家应用程序。商家在系统注册后，可以添加商品、折扣、价格等信息，并有智能手机应用程序访问每个商家及其商品。

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

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

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

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

【问题讨论】：

如果应用程序只有 CRUD 操作和最少的关系层，那么最好使用 NOSQL db 之类的 mongodb，易于与 spring-data 集成，如果移动应用程序是混合的，那么 json 层数据会更多也很有效。
对于多租户系统，我会排除 2) ... 如果 1) 或 3) 是正确的选择，取决于此处未提及的要求：您打算扩展还是允许您的商家拍摄他们的数据的快照？您是否计划允许为演示/测试目的创建沙盒实例？
让我们坚持使用 MySQL，因为问题不在于使用关系或无 sql。
一些预期的数字会有所帮助。有多少商户？ 10k..10M？有多少产品？
产品数量不限。

【解决方案1】：

1) 使用一个数据库，使用单表结构维护目录带有名为 Mercer_id 的列。

这是最简单的路线。

优点

缺点

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

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

优点

缺点

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

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

优点

缺点

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

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

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

【讨论】：

【解决方案2】：

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

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

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

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

您认为选项 2 和 3 有什么好处？我真的没有看到任何优势，只有缺点。

【讨论】：