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

Question

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

现在第一眼（内部）可见。 我看了看ans后面的数据库结构（我认为）有些奇怪。

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

当我有一个用户时：

• 用户身份
• 电子邮件
• 密码
• 名称
• 姓
• 地址
• 电话

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

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

---

额外的信息：

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

---

问题：

• 这是为大型系统或类似系统创建数据库的正常方法，因为我从未在研究中或生活中的其他项目中看到过这种方法。
• 这是最佳还是不良做法？
• 我认为这对性能不利。 特别是当用户数量增加时，这是真的吗？ 还是可以这样做以提高性能（因为不需要选择整个记录？（在我们的情况下，我们预计到2017年底至少有100.000个用户，随着我们的项目通过，该用户将越来越快。）几年内我们增长到远超过1.000.000用户的重大机会）
• 我认为他们这样做的原因是可以很容易地更改“对象”，但我认为始终可以向表中添加字段，并且您永远都不应删除字段（也不能删除字段）数据库的结构），我对此有何看法？

抱歉，当问题是“新手问题”时，对我来说，这是我人生中的第一个大项目，因此我想念一些经验，但尝试专业地管理该项目。 我们将在星期三的会议上进行讨论。 通过这种方式，我想为此主题做一些自我准备。

Answer 1

我认为这对性能不利。 特别是当用户数量增加时，这是真的吗？

没有。

插入/更新成本上的差异很小，这将不取决于先前累积的数据量。 完整记录的检索成本会更高，但部分记录的检索成本会有所降低。 归根结底，只要记录仍然可以在一次单次往返数据库中解决的情况下，性能差异就可以忽略不计（与许多琐碎的ORM实现不同）。

影响最大的是功能。 例如，它没有努力为EAV表添加标题属性，但是在对表进行技术改造以适应更宽的记录（或迁移行）时，可以将规范化表脱机。 OTOH，您不能像每个客户都必须有一个电子邮件地址那样在数据库层实施约束。

这是最佳还是不良做法

就其本身而言。 尽管没有记录设计决策是一个坏习惯。

几年内远远超过1.000.000用户

一百万条记录并不多（除非数据库设计确实很糟糕）。