0

我有一个数据库，其中存储了一些用户。每个用户都有自己的帐户设置、隐私设置和许多其他要设置的属性。这些房产的数量开始增长，我最终可能会拥有 30 个左右的房产。

到现在为止，我曾经将它保存在“UserInfo”表中，将 User 和 UserInfo 关联为一对多（记录所有更改）。把它放在一个“UserInfo”表中听起来不太好，至少在数据库模型中，它看起来很乱。解决方案是什么？

将隐私设置、帐户设置和其他设置“组”分隔在单独的表中，并且在 UserInfo 和每组设置表之间具有 1-1 关系是一种解决方案，但是在检索数据时会不会太慢（或慢得多）？我想所有数据都不会同时显示在一个页面上。因此，也许与每个表建立一对多关系也是一种解决方案（分别保存每个组的日志）？

4

1 回答 1

1

如果它只有 30 个属性，我建议只创建 30 列。对于现代数据库来说，这并不过分。

但我猜如果你今天拥有 30 个属性，随着时间的推移，你将继续发明新的属性，列的数量将不断增长。当您获得大量行时，重组您的表以每天添加列可能会变得很耗时。

如需替代解决方案，请查看此博客，了解以“无模式”方式存储大量动态属性的绝妙解决方案： FriendFeed 如何使用 MySQL。

基本上，将所有属性收集为某种格式并将其存储在单个 TEXT 列中。格式是半结构化的，即您的应用程序可以根据需要分离属性，但您也可以随时添加更多属性，甚至每行具有不同的属性。XML 或 YAML 或 JSON 是示例格式，或者是您的应用程序代码语言支持的某些对象序列化格式。

CREATE TABLE Users (
  user_id SERIAL PRIMARY KEY, 
  user_proerties TEXT
);

这使得在给定属性中搜索给定值变得困难。因此，除了 TEXT 列之外，为您希望可搜索的每个属性创建一个辅助表，其中包含两列：给定属性的值，以及返回到找到该特定值的主表的外键。现在您可以索引该列，以便快速查找。

CREATE TABLE UserBirthdate (
  user_id BIGINT UNSIGNED PRIMARY KEY,
  birthdate DATE NOT NULL,
  FOREIGN KEY (user_id) REFERENCES Users(user_id),
  KEY (birthdate)
);

SELECT u.* FROM Users AS u INNER JOIN UserBirthdate b USING (user_id)
WHERE b.birthdate = '2001-01-01';

这意味着当您在用户中插入或更新一行时，您还需要在每个辅助表中插入或更新，以使其与您的数据保持同步。当您添加更多辅助表时，这可能会变得复杂。

于 2011-06-20T23:57:16.577 回答