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

Question

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

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

他们为用户创建了一个表用户，其中包含诸如 ID、电子邮件和密码之类的内容。在此附近，他们创建了一个包含 id、键和值的 user_meta 表。

当我有一个用户:

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

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

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

---

额外信息:

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

---

问题:

• 这是为大型系统或类似系统创建数据库的正常方法吗，因为我在我的学习或生活中的其他项目中从未见过这种方法。
• 这是最佳做法还是错误做法？
• 在我看来，这对性能不利。特别是当用户数量增长时，这是真的吗？或者这样做可以提高性能(因为不需要选择整个记录？(在我们的例子中，我们预计到 2017 年底至少有 100.000 名用户，当我们的项目通过时，它会增长得越来越快。有一个我们在几年内增长到远超过 1.000.000 用户的物质机会)
• 我认为他们这样做的原因是“对象”可以很容易地改变，但在我看来，向表中添加字段总是可行的，你永远不应该删除字段(也不要在删除字段时删除)由数据库的结构可能)，我的意见是正确的吗？

抱歉，问题是“菜鸟问题”，但对我来说，这是我生活中的第一个大项目，所以我错过了一些经验，但尝试专业地管理项目。我们将在本周三的 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

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