我有两个MySQL数据库的场景，我不确定选择哪个，而且我遇到了几张桌子的相同困境。
我正在制作只有会员才能访问的网络应用程序。每个成员都有自己的交易，费用，并说“列表”。记录的标准在用户之间是相同的，但每个用户可以具有完全不同的记录数量。
我的2个场景是我是否应该有一个表用于交易，一个表用于列表，一个表用于费用......并且每个表中都有一个字段链接到特定用户的主键。或者...如果最好为每个用户分别设置一个交易表，费用表和清单表..（使用组合字符串，如“user”+ deals，或“user”+ exp）。交易可以在1或2个用户中使用，但费用和列表完全独立。我将有一个主交易表来保存每笔交易的所有信息，但是有一个用户交易表将他们的主键链接到交易主键。
那么，单独的表还是一个表？如果有成千上万的用户拥有数百个交易/费用/列表..我只是不希望在大量交易或费用累积后查询速度极慢...没有用户需要查看任何内容其他用户......严格来说只是他们的数据。
另外，我熟悉数据库如何工作和存储数据，但我并不是100％清楚。我只是希望它能够快速工作，所以我的另一个问题是（虽然它可能是愚蠢的）当用户提交新的交易或费用时...它是插入表格的开头还是结尾？或者它是无关紧要的...因为查询将在返回信息之前以任何方式搜索表中的所有内容？
答案 0 :(得分：3)
始终使用一个表来存储一种实体。
或者更具体地说，你所谈论的是一个讨厌的，复杂的优化，它在一小部分案例中工作，几乎肯定不是你的。
您只想将一个表用于一种条目。对它进行适当的索引，并在不再需要它们时尝试删除旧记录。
此外，很多人对“大数据”的看法实际上并不是特别大。数据库通常需要很少的优化，而他们的数据仍然适合RAM，在现代系统中，这意味着32Gb。
答案 1 :(得分：0)
关于你的第二个问题：
在MySql中，磁盘上记录的顺序由PRIMARY KEY定义。意味着记录不会在结尾或开头插入，而是根据主键在任何位置插入。
在其他数据库中你可以选择使用CLUSTERED KEYS来使用PRIMARY以外的其他密钥来命令磁盘上的记录，但据我所知，这在MySql中不受支持。
关于你的第一个问题：
我发现自己处于这个位置几次，最近我一直回到一篇博文（系列的最后一篇，结论在底部）：
http://weblogs.asp.net/manavi/archive/2011/01/03/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines.aspx
我引用：
在我们开始讨论之前，我 我想强调没有人 单一的“最佳策略适合所有人 场景“存在。如你所见，每一个 这些方法各有所长 优点和缺点。这是 一些经验法则来识别 特定的最佳策略 场景：
如果您不需要多态关联或查询，请倾向于 TPC-换句话说，如果你从来没有或 很少查询BillingDetails和 你没有班级 与BillingDetail基地的关联 类。我建议使用TPC（每种混凝土类型表）（仅） 您的类层次结构的顶级， 多态性通常不在哪里 要求，并在修改时 未来的基类不太可能。
如果您确实需要多态关联或查询，并且 子类声明相对较少 属性（特别是如果主要的 子类之间的差异在于 他们的行为），倾向于TPH（每层次表）。您的 目标是尽量减少数量 可空的列和说服 你自己（和你的DBA）那个 非规范化架构不会创建 从长远来看问题。
- 如果您确实需要多态关联或查询，并且 子类声明了许多属性 （子类主要由数据不同 他们坚持，倾向于TPT（每种类型的表）。要么， 取决于宽度和深度 你的继承层次结构和 加入工会的可能成本， 使用TPC。
默认情况下，仅为简单选择TPH 问题。对于更复杂的情况（或 当你被数据推翻时 建模者坚持认识的重要性 可空性约束和 正常化），你应该考虑 TPT战略。但那时， 问自己是否可能不是 更好地重建继承作为 在对象模型中委托 （代表团是一种制作方式 组合作为重用的强大功能 遗产）。复杂的继承是 通常最好避免各种各样的 与持久性或无关的原因 ORM。 EF充当了它之间的缓冲区 领域和关系模型，但那 并不意味着你可以忽略 设计时持久性问题 你的课程。