大型和可扩展应用程序的数据库表结构

Question

我是一名软件工程师（因为我的学习已经准备了几个月），为了我的工作，我开发了一个大型可扩展的Web应用程序。另一家公司负责编程工作并将数据库置于其后。我们定义了数据和它们之间的关系，但没有给出应该使用的硬数据库结构。

现在第一个（内部）事物是可见的。我查看了ans后面的数据库结构（在我看来）有些奇怪的东西。

对于用户，他们创建了一个表用户，其中包含id，email和password等内容。在此附近，他们创建了一个user_meta表，其中包含id，key和value。

当我有一个用户：

• 用户ID
• 电子邮件
• 密码
• 名称
• 名字
• 地址
• 手机

id，email和密码存储在用户表中。对于其他信息，是在user_meta表中创建的行。这意味着在这种情况下，为1个用户创建了4行（在我们的例子中，每个用户超过20行）此结构是每个对象的用户，应该保存在数据库中。

我学会了创建一个包含用户所需的所有数据的表。所以在我的逻辑中它应该是一个包含7个字段的表...

额外信息：

• 我们的软件基于Laravel框架（根据我的建议）
• 我们的软件使用MySQL数据库

问题：

• 这是为大型系统或类似的东西创建数据库的正常方式，因为我在我的研究或我现场的其他项目中从未见过这一点。
• 这是最好还是坏的做法？
• 在我看来，这对性能不利。特别是当用户数量增长时，这是真的吗？或者可以这样做以获得高性能（因为不需要选择整个记录？（在我们的情况下，我们预计2017年底至少有100,000个用户，当我们的项目通过时，它们会越来越快地增长。）我们在几年内远远超过1.000.000用户的重要机会）
• 我认为他们这样做的原因是“对象”可以很容易地改变，但在我看来，总是可以将字段添加到表中，你不应该删除字段（也不应该删除字段）可以通过数据库的结构来看，这是对我的看法吗？

抱歉，当问题是“noob问题”时，但对我而言，这是我现场的第一个大项目，所以我想念一些经验，但尝试专业地管理项目。我们将在周三的会议上讨论这个问题。通过这种方式，我想在这个主题中做好准备。

Answer 1

  

在我看来，这对性能不利。特别是当用户数量增长时，这是真的吗？

没有

插入/更新成本存在微小差异，这与先前累积的数据量无关。 完整记录的检索成本会更高，但对于部分记录会略微降低。在一天结束时，只要记录仍然在DB的单次往返中得到解决，性能差异可以忽略不计（与许多简单的ORM实现不同）。

最大的影响是功能性的。它没有努力为EAV表添加标题的属性，但是规范化的表可能会被淘汰，同时表被压缩以容纳更宽的记录（或者行被迁移）。 OTOH您无法在数据库层强制执行约束，因为每个客户都必须拥有电子邮件地址。

  

这是最好还是坏的做法

本身也不是。虽然不记录设计决策是不好的做法。

  

远远超过1.000.000用户几年

百万条记录不是很多（除非数据库设计非常糟糕）。