如何更好地建立数据库答案

【问题标题】：How to better build a database如何更好地建立数据库
【发布时间】：2016-05-06 14:24:20
【问题描述】：

我们有一个 SQL 数据库，其中有一个用于用户的表 (1) 和一个用于用户保存信息的表 (2)。每条信息是表（2）中的一行。所以我的问题如下 - 如果我们打算将用户数量增加到超过 1.000.000 并且每个用户可以拥有超过 10 条信息，那么以下哪个是构建我们的数据库的更好方法：

a) 有 2 个表 - 1 个用于用户，1 个用于来自所有用户的信息，与具有 ID 的用户相关

b) 每个用户都有一个单独的表。

提前致谢。

【问题讨论】：

另一种选择！（b太可怕了。）
100%为什么要为每个用户提供 1.000.000 个表？
(b) 太可怕了。它永远无法扩展。如果索引正确，MySQL 可以处理具有 100 条子行的一百万用户。您在这里犯了过早的优化。
嗨，jarlh，非常感谢。仅拥有 1.000.000 个用户，每个用户有 10 行，这意味着 DB 中有 10.000.000 行。它不会影响速度，而不是为每个用户的信息单独提供一个表吗？
您对表 2 的设计很糟糕。它被称为 EAV 表，它是性能的杀手。正确完成您的工作，并将您需要的用户属性定义为此表中的单独列。如果您需要在属性中增加一些灵活性，请在之后添加一个 EAV 表，但是您需要的 99% 的属性应该可以预先定义，这将使您的数据库工作得更好。如果您真的无法弄清楚属性应该是什么，那么关系数据库就是错误的工具。

标签： mysql sql database database-design relational-database

【解决方案1】：

当然，它应该为用户提供一个单独的表要好得多。从数据库的角度思考。您正在考虑排序 ID 的 1.000.000 行中的搜索时间。在第二种情况下，您必须搜索 1.000.000 表才能进入正确的表。所以最好选择 A 选项。

【讨论】：

【解决方案2】：

我同意选项 A 是所提出的两个选项中更好的一个。

话虽如此，我个人也会将用户的信息分解为更多表格。这将全部使用外键连接，并允许对信息进行更具体的查询。

SQL 并不是真正水平可扩展的，因此如果您最终得到的用户信息比其他用户少或多，那么您将拥有 NULL 列，这需要以各种方式处理。

通过使用单独的表格，您仍然可以包含所有信息，但不必担心一个用户有家庭和手机号码，而另一个用户只有手机号码。

如果确实需要一次访问大量信息，SQL 非常擅长通过连接等方式处理此问题。

选项 B 还不错，只是不适合 SQL。如果有问题的数据库是基于文档的而不是基于表格的，我会工作。在这种情况下，为每个用户创建一个文档是一个好主意，并且可能是首选。

【讨论】：

【解决方案3】：

选项 C) 具有唯一 UserID 作为聚集索引（主键）的用户表具有唯一 InformationID 作为聚集索引（主键）的已保存信息类型表具有唯一 UserInformationID 作为聚集索引（主键）的 UserInformation 表，UserID 列（非聚集索引，用户表的外键）和 InformationID 列（非聚集索引，信息表的外键）。有一个“值”或类似的列来保存与信息类型相关的数据。

示例：用户表

UserID UserName
1     | UserName1
2     | UserName2

信息表

InfoID InfoName
1     | FavoriteColor
2     | FavoriteNumber
3     | Birthday

用户信息表

ID    UserID  InfoID  Value
1     | 1     | 1     | Blue
2     | 1     | 2     | 7
3     | 1     | 3     | '11/01/1999'
4     | 2     | 3     | '05/16/1960'

此方法允许您为任何用户保存任何值的组合，而无需记录任何未提供的用户信息。它使信息表保持“干净”，因为您无需为要跟踪的每条新信息不断添加列。只需在 Info 表中添加一条新记录，然后只记录提交到 UserInformation 表的值即可。

【讨论】：