数据库设计 - 一个表或多个表/连接

我有一个结构为现有的数据库如下：数据库设计 - 一个表或多个表/连接

user 
user_profile 
user_permissions 
user_statistics

每个表都有一个用来连接各表一起唯一列如下：

SELECT * 
FROM user 
INNER JOIN user_profile ON user.user_id = user_profile.user_profile_id 
INNER JOIN user_permissions ON user.user_id = user_permissions.user_permissions_id 
INNER JOIN user_statistics ON user.user_id = user_statistics.user_statistics_id 
WHERE user_id = 1

以这种方式做事情有什么问题吗？或者更好的做法是创建一个包含大量列的表，以便不需要连接？

来源

2012-09-04 Reado

这是一个经典的数据库设计;它被称为“normalization”，并且通常被认为是最佳实践。

有理由去规范数据库 - 性能是经典的。但是，这通常会牺牲可维护性和一致性。它通常只在数据大小极端的情况下才有意义 - 您描述的模式应该扩展到大量记录，而不会导致连接成为问题。

我也猜测，链接到“用户”的几个表具有给定用户的多个记录 - “统计”通常对于给定用户具有很多行;每个用户的权限也可能有一行权限。建模在单个大表中将是可怕的。

一些设计人员喜欢为逻辑上独立的数据创建单独的表。因此，您的设计可能会包含一个“user_profile”表，每个用户只有一行，因为设计人员认为这与“用户”逻辑上是分开的数据 - 例如，它会在不同的业务环境下进行更改。在我看来，这主要是风格问题。

在这种情况下，联接不会使数据库变得更慢 - 关系数据库的整个要点在于管理这种场景非常有效（“关系”指的是数据可以相关的事实）。

来源

2012-09-04 14:03:03

OK，所以在最佳实践方面，我需要拆分我的数据的唯一时间是当我有一个单一的用户记录在“用户”和多个记录与其他表中的用户记录相关，如统计和权限？使用连接是否会减慢数据库查询的速度？ – Reado

它*可以*加速;这取决于您正在存储的数据的性质。 –

如果您没有正确编制索引，连接会使您放慢速度。 FK应该有一个索引，并不是所有的数据库都会自动为它创建一个FK。如果您的字段很少填写（或查询）或非常宽的表格，则可能需要一对一的关系。由于记录大小的限制，非常宽的表格可能会导致性能降低或无法添加所需的信息。 – HLGEM

将数据库关系更好地照原样使用。这种结构可以消除数据异常的风险，并且可以根据规模和特定领域的变化做出更改（例如，当您添加新类型的许可时会发生什么？）

JOIN是数据库的自然部分，它们非常高效。

为什么这是一个好习惯的细节都聚集在一起，为我们称之为database normalization

来源

2012-09-04 14:04:22

数据库设计 - 一个表或多个表/连接

回答

相关问题