MySQL 数据库结构决策

我试图在以下两个表之间做出决定：为有关用户的所有可能数据提供 1 个巨大的表，其中很多数据不适用于每个用户，然后为用户可以拥有多个实例的数据（例如，以前的作业）使用单独的表，还是将每个用户的数据分布在多个表之间。

第一种方法更加简化，但我觉得它会使用大量不必要的开销，而第二种方式的结果更容易使用，但会导致大量额外的数据库查询。

某些关联事物的多个实例总是进入另一个表。此过程称为规范化。

虽然乍一看似乎更复杂，但从长远来看，它会让你的生活更轻松。如果需要，像MySQL这样的数据库系统可以简单地将表重新组合在一起（非规范化）（前提是您的关键字段已正确索引）。

由于多种原因，使用您描述的非规范化表要困难得多。假设一个Person有多个地址。你会如何把它放到主表中？ Address1、Address2、Address3？如果此人有四个不同的地址怎么办？

使用这样的表会困难得多，因为您现在必须在编写的每个查询中处理表中的三列而不是一列。

如果相关品质取决于用户类型，并且特定类型的所有用户都具有所有这些品质，则可以为每种类型提供一个表。

创建表Type1_Qualities （ id int 不为空auto_increment主键， user_id int 引用（用户），质量1 ...，质量2 ...， ...)

对于类型 2 和类型 3 也是如此。这避免了为每个用户提供所有这些无关的字段，但比使用通用属性表（如 xception 的答案）进行大量连接更简单。

根据数据的存储方式，您可能会选择多关系数据结构，这只是一个例子：

CREATE TABLE user (
   id int not null auto_increment primary key,
   name varchar[60] not null
);
CREATE TABLE attributes (
   id smallint not null auto_increment primary key,
   name varchar[20] not null,
   order smallint --optional
);
CREATE TABLE userattributes (
   user int not null references user (id),
   attribute smallint not null references attributes(id),
   value varchar[100] not null,
   order tinyint --optional
);
INSERT INTO textattributes(name) VALUES ('alias'), ('address'), ('hobby')

我将订单字段标记为可选，因为您可能不关心这些字段

SELECT a.name, ua.value
FROM userattributes AS ua
JOIN attributes AS a
    ON ua.attribute = a.id
WHERE user = :user
ORDER BY a.order, ua.order

如果需要，也可以加入用户，但每一行的数据都会重复，或者您可以使用单独的查询从用户那里获取数据。我个人会为此使用第二个查询。

相关内容

最新更新

热门标签：