适用于大型可扩展应用程序的数据库表结构 [英] Database table structure for big and scalable applications

问题描述

我是一名软件工程师(自完成学习以来已有数月)，并且为我的工作开发了一个大型可扩展Web应用程序.另一家公司负责编程工作，并在其后面建立数据库.我们定义了数据及其之间的关系，但没有给出应使用的硬数据库结构.

Iam a software engineer (since a few months ready with my study) and for my work i develop a large scalable web application. Another firm does the programming work and makes the database behind it. We defined the data and the relations between them but didn't give a hard database structure they should use.

现在头(内部)事物可见.我看了看ans后面的数据库结构(在我看来)有些奇怪.

Now the first (internal) things are visable. I looked in the database structure behind ans saw (in my opinion) something weirds.

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

For users they created a table users which contains stuff like id, email and password. Near this they created an user_meta table which contains an id, key and value.

当我有以下用户时:

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

ID，电子邮件和密码存储在用户表中.其他信息是在user_meta表中创建的行.这意味着在这种情况下，为1个用户创建了4行(在我们的示例中，每个用户有20行以上).这种结构是每个对象的用户，应该保存在数据库中.

the id, email and password is stored in the user table. For the other information are rows created in the user_meta table. This means in this case there are 4 rows created for 1 user (in our case are this more than 20 rows for each user) This structure is user for every object what should be saved in the database.

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

I learned to create a table which contains all the data which is necessary for the user. So in my logic it should be one table with 7 fields...

其他信息:

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

问题:

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

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

sorry when the questions are "noob questions" but for me this is the first big project in my live so i miss some experience but try to manage the project professionally. We will discuss this wednesday in an meeting. On this way i want to prepare my self a bit in this theme.

推荐答案

我认为这对性能不利.尤其是当用户数量增加时，这是真的吗?

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

否.

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

There is a small difference in the insert/update cost which will not be dependent on the volume of data previously accumulated. Retrieval cost for a full record will be higher but slightly reduced for a partial record. At the end of the day, the performance differences are negligible as long as the record is still resolved in a single round trip to the DB (unlike a lot of trivial ORM implementations).

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

The biggest impact is functional. Its no effort to add, say, an attribute for title to the EAV table, but the normalized table may be knocked offline while the table is stresteched to accomodate the wider records (or the rows are migrated). OTOH you can't enforce a constraint at the database tier like every customer must have an email address.

这是最好还是不好的做法

Is this best or bad practice

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

Of itself neither. Although not documenting design decisions is bad practice.

几年内远远超过1.000.000用户

far above 1.000.000 users in a few years

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

a million records is not a lot (unless the database design is really bad).

这篇关于适用于大型可扩展应用程序的数据库表结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！