组织数据库表 - 大量属性

发布于 2024-11-16 06:35:04 字数 362 浏览 6 评论 0原文

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

到目前为止，我曾经将其保存在“UserInfo”表中，其中 User 和 UserInfo 作为一对多相关（保留所有更改的日志）。将其放在单个“UserInfo”表中听起来不太好，而且至少在数据库模型中，它看起来会很混乱。解决办法是什么？

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

╄→承喏 2024-11-23 06:35:04

如果只有 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';

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

If it's only 30 properties, I'd recommend just creating 30 columns. That's not too much for a modern database to handle.

But I would guess that if you ahve 30 properties today, you will continue to invent new properties as time goes on, and the number of columns will keep growing. Restructuring your table to add columns every day may become time-consuming as you get lots of rows.

For an alternative solution check out this blog for a nifty solution for storing lots of dynamic attributes in a "schemaless" way: How FriendFeed Uses MySQL.

Basically, collect all the properties into some format and store it in a single TEXT column. The format is semi-structured, that is your application can separate the properties if needed but you can also add more at any time, or even have different properties per row. XML or YAML or JSON are example formats, or some object serialization format supported by your application code language.

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

This makes it hard to search for a given value in a given property. So in addition to the TEXT column, create an auxiliary table for each property you want to be searchable, with two columns: values of the given property, and a foreign key back to the main table where that particular value is found. Now you have can index the column so lookups are quick.

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';

This means as you insert or update a row in Users, you also need to insert or update into each of your auxiliary tables, to keep it in sync with your data. This could grow into a complex chore as you add more auxiliary tables.

回复收藏 0 原文

~没有更多了~