在 MySQL 中有很多表代表一个对象是不好的设计吗？答案

【问题标题】：Is it bad design to have many tables representing one object in MySQL?在 MySQL 中有很多表代表一个对象是不好的设计吗？
【发布时间】：2013-09-16 02:45:59
【问题描述】：

我有很多这种结构的对象：

~ PlaceID
  = Upvotes
  = Downvotes
  = Names
    - Title 
      + Upvotes
      + Downvotes
    - Other names[]
      + Upvotes 
      + Downvotes
  = Location
    - Lat
    - Long
    - Address
  = Images
    - Top 
      + id/url
      + Upvotes
      + Downvotes
    - Others[]
      + Upvotes
      + Downvotes
  = Comments[]
    - id
    - Text
    - Upvotes
    - Downvotes
    - ReplyTo

为了保持井井有条，我制定了一个包含大量链接的架构。这是一个示例表：

7741（地点 ID）

______________________________________________________________________________
names      | location      | upvotes | downvotes | images      | Comments
_______________________________________________________________________________
7741_names | 7741_location |    20   |     3     | 7741_images |  7741_comments

然后在 7741_images 中（按分数排序，因此“顶部”项目很容易检索）：

 imgID   | score | upvotes | downvotes | url              |
________________________________________________________
 7741_21 | 98    |    44   |     1     | /img/7741_21.png |
 7741_14 | 94    |    40   |     2     | /img/7741_14.png |

这种每个对象有很多表的向下钻取样式是否会使查询变得非常缓慢或非常具体的查询过于冗长？（对于 100k 地点？）

我从未负责架构设计，如果我遗漏了显而易见的内容，请原谅。

【问题讨论】：

我认为使用标准化设计会更好。如果你不知道这意味着什么，我听说过这本书的好东西，数据库设计为凡人。
我相信我对规范化很熟悉，但是我概述的架构不是很规范化吗？或者您是否建议将其更加规范化，例如，每个 imgID 是它自己的表？

标签： mysql sql database-schema schema-design

【解决方案1】：

它的好坏是一种主观的品质——基于您提出的问题（和架构）。为了更好地回答这个问题，您必须解释您的架构设计决策。您应该始终为您的决定提供充分的理由，如果在您的开发中证明它不正确，则进行迭代以改进。 :)

假设您正在预先尝试设计架构以支持您的应用程序，我将从 Neil 指出的方法开始。对于您的示例模式，在某些情况下，性能将是一个问题。

再次，从简单开始，如果您需要修改，请确保您对选择设计的正当理由感到“良好”。

【讨论】：