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

Question

我是一名软件工程师(几个月前就开始学习)，为了我的工作，我开发了一个大型可扩展的 Web 应用程序。另一家公司负责编程工作并制作其背后的数据库。我们定义了数据以及它们之间的关系，但没有给出他们应该使用的硬数据库结构。

现在第一个(内部)事情是可见的。我查看了 ans 背后的数据库结构(在我看来)看到了一些奇怪的东西。

对于用户，他们创建了一个用户表，其中包含 ID、电子邮件和密码等内容。在此附近，他们创建了一个 user_meta 表，其中包含 id、键和值。

当我有一个用户时:

• 用户ID
• 电子邮件
• 密码
• 姓名
• 姓氏
• 地址
• 电话

ID、电子邮件和密码存储在用户表中。其他信息是在 user_meta 表中创建的行。这意味着在本例中为 1 个用户创建了 4 行(在我们的例子中，每个用户超过 20 行)此结构是每个对象的用户应保存在数据库中的内容。

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

<小时/>

额外信息:

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

<小时/>

问题:

• 这是为大型系统或类似系统创建数据库的正常方法吗？因为我在我的研究或生活中的其他项目中从未见过这种方法。
• 这是最好的做法还是不好的做法？
• 我认为这对性能不利。尤其是当用户数量增加时，这是真的吗？或者可以这样做以获得较高的性能(因为不需要选择整个记录？(在我们的例子中，我们预计到 2017 年底至少有 100.000 个用户，当我们的项目通过时，这些用户将增长得越来越快。有一个我们很有可能在几年内将用户数量远远超过 100 万)
• 我认为他们这样做的原因是“对象”可以很容易地更改，但在我看来，向表中添加字段总是可能的，并且您永远不应该删除字段(也不应该删除字段)可能由数据库的结构决定)，我的观点对吗？

很抱歉，这些问题都是“菜鸟问题”，但对我来说，这是我人生中的第一个大项目，所以我错过了一些经验，但尝试专业地管理该项目。我们将在周三的 session 上讨论。通过这种方式，我想为这个主题做好一些准备。

Answer 1

In my opinion this is bad for performance. Especially when the user count grows, is this true?

没有。

插入/更新成本存在微小差异，该差异不依赖于先前积累的数据量。 完整记录的检索成本会更高，但部分记录的检索成本会略有降低。最终，只要记录仍然在到数据库的单次往返中解析(与许多简单的 ORM 实现不同)，性能差异就可以忽略不计。

最大的影响是功能性的。例如，向 EAV 表添加标题属性并不需要付出任何努力，但是当表被拉伸(stretch)以容纳更广泛的记录(或者行被迁移)时，规范化表可能会脱机。 OTOH，您无法在数据库层强制实现约束，就像每个客户都必须有一个电子邮件地址一样。

Is this best or bad practice

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

far above 1.000.000 users in a few years

一百万条记录并不是很多(除非数据库设计真的很糟糕)。