mysql数据库结构 - 数据仅与每个用户相关，因此用户表？答案

【问题标题】：mysql database structure - data only relevant per user thus user tables?mysql数据库结构 - 数据仅与每个用户相关，因此用户表？
【发布时间】：2011-07-11 15:36:04
【问题描述】：

我想为卡车司机建立一个在线日志。目标是在卡车司机登录后，他/她立即看到他/她今年/月/日的驾驶总数的快照，以及每年/月/日的其他一些总数。 因此，存储在数据库中的信息仅与每个用户（卡车司机）相关。我个人不需要整个数据库中的任何统计数据（仅针对每个用户）。

假设有 10,000 个用户。

我的问题与 mySQL 数据库的设计有关。

由于存储的信息仅与每个用户相关，而不是大量相关，因此将数据存储在每个用户的表中是否有意义...导致 10,000 个表？这会导致最有效/最快的数据库吗？或我是否应该将所有行转储到一个大的“日志”表中，并将其与另一个表“用户”相关联......即使只针对每个用户进行分析？

以下是每个用户需要存储的一些信息（最多大约 30 列）：日期 - 卡车品牌/型号 - 卡车 ID - 路线编号 - 从 - 到 - 总时间 - 停靠点 - 耗油量 - 夜间 - 船员（第二名司机） - ......

【问题讨论】：

我会选择“一个表来统治所有人”，并有一个用户表，使您能够识别卡车司机及其日志。使用明确定义的架构和良好的查询，您不应该有任何性能问题:) --- 编辑您可能还希望有一个卡车表。否则，您的“日志”表中会出现大量重复的卡车数据
看我的回答，或许能帮到你更多。
经验法则：就关系数据库而言，“每个用户一个表”几乎从来都不是一个好主意。我写“几乎”是因为可能会有一些极端情况，但我还没有听说过。
我也读过这个。谢谢输入！

标签： php mysql database-design multi-tenant

【解决方案1】：

这里是简化的例子

User
user_id
first_name
last_name

Truck
truck_id
truck_make
truck_model

Route
route_id
user_id
truck_id
route_from
route_to
gas_consumption

没有更多细节可以继续，这就是我将如何滚动它。

【讨论】：

维度方法。我很欣赏这个例子。谢谢。
别担心，很高兴我能提供帮助。
不要忘记使用外键将表连接在一起。
@Dirk 我倾向于使用维度方法：1 通过 InnoDB 表中的外键与其他维度相关的日志表。感谢您的意见！

【解决方案2】：

我建议使用单独的桌子，但在你的情况下，一张大桌子可能是一个不错的计划。

假设您编写高效的 MySQL 来访问数据，您应该不会对您所描述的大型数据集有问题。

我会查看MySQL / Rails Performance: One table, many rows vs. many tables, less rows? 以获取有关为什么使用表根目录可能是个好主意的更多信息。 Which is more efficient: Multiple MySQL tables or one large table? 还包含有关该主题的一些有用信息。

【讨论】：

没问题，我知道这是您的第一个问题 - 欢迎来到 SO！您是否考虑过接受最能回答您的问题的答案？
@Tom 我倾向于使用维度方法：1 通过 InnoDB 表中的外键与其他维度相关的日志表。我从来不需要建立一个海量数据与分析无关的数据库......我个人不喜欢数据库中有太多表的想法。
我完全同意，在阅读了效率之后 - 太多的表格看起来很混乱。

【解决方案3】：

您正在描述一个多租户数据库。 SO有一个标签；我给你加了。

MSDN 有一篇不错的文章给你一个overview of the issues involved in multi-tenant databases。结构范围从什么都不共享到共享一切。请注意，在“共享一切”结构中，数据库所有者（可能是您）很容易编写一个打破用户隔离并将一个用户的数据暴露给其他用户的查询。

【讨论】：

Catcall 非常感谢您。我会读文章！与日志表的增长一起，用户隔离当然是我的担忧之一。很好的帮助，再次感谢！
不要忽视从备份中恢复。使用“共享一切”结构，从备份中恢复一个用户的数据意味着在每个表中恢复几行。实际上，这可能意味着您不支持从备份恢复。
有趣的想法。谢谢。似乎非共享结构可能会导致更多的硬件要求......在初步阅读了这个概念之后。