选择存储用户配置文件的方法？

Question

我正在为网站开发用户配置文件系统，并且正在考虑采取什么更好（可扩展）的方法。我提出了两种解决方案，正在寻找输入或可能是我可能错过的东西的指针。

以下 create table 语句并不意味着可执行，而只是为了让您了解所涉及的表的布局。

我最初的想法是这样的：

CREATE TABLE user(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,

    user_email VARCHAR(320),

    user_joined DATATIME,
    user_last_seen DATATIME,

    user_name_first VARCHAR,
    user_name_last VARCHAR,

    user_name_alias VARCHAR,

    user_location_country VARCHAR,
    user_location_region VARCHAR,
    user_location_city VARCHAR

    # ...
);

显然，这根本不是非常可扩展的，并且添加额外的属性很烦人。一个优点是我可以快速搜索与一组特定属性匹配的用户。我环顾四周，这是一种非常常见的方法（例如 Wordpress）。

我的第二种方法（我目前正在使用的方法）更具可扩展性，但我有点担心性能：

CREATE TABLE user(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,

    user_email VARCHAR(320)
);

CREATE TABLE user_profile(
    user_id INT UNSIGNED NOT NULL,

    visibility ENUM('PRIVATE', 'PUBLIC'),

    name VARCHAR,
    value VARCHAR
);

使用这种方法，每次使用都有一组与之关联的键值对，这使得添加其他属性以及在用户登录时加载用户配置文件变得微不足道。但是，我丢失了在第一种方法中拥有的所有类型信息（例如，DATETIME 现在存储为格式化字符串），因此一些搜索变得烦人。这确实让我可以更好地控制选择用户希望公开显示的属性。

混合方法会更好，让我平衡两种方法的优缺点吗？ SO使用什么方法？还有其他我没有想到或错过的方法吗？

扩展：使用混合方法是否也可以将用户表中的属性插入到 user_profile 表中以控制它们对其他用户的可见性，或者这可能被视为额外开销？

Answer 1

我会使用混合方法。一些基本属性，如用户名、电子邮件、lastlogindate 等应该添加到您的用户表中。次要的项目可以作为键/值对添加。

通过这种方式，您仍然可以轻松搜索最重要的信息并继续添加配置文件项，而无需更改架构。

Answer 2

混合解决方案不是一个好的解决方案。本质上，您将其他属性存储到属性包表中。从长远来看，这将使报告和查询变得复杂。此外，将日期、int、decimal、ntext 等存储为 varchar 不会成为可伸缩性的可接受的性能交换。如果需要，您将如何在该表之外创建关系？

更好的方法是为用户信息创建一个用户表。然后随着您的需求扩展，创建代表新功能的新类。这些新类可能会有相应的表。这样，当与用户关联的属性属于他们自己的空间时，您的“用户”类就不会呈指数增长。是的，将来您可能真的拥有属于用户表的新属性。那时您需要返回并调整您的架构和 DBAL，但这是易于理解的代码价格。

在您的示例中，您在第一个用户表中有用户的地址信息。我要做的一件事是我知道我不仅需要为用户存储地址。所以我将有一个单独的 Address 表，然后在 User 表中包含一个可为空的 AddressId。这样，当我有一个 Stores 表、一个 Events 表时，我也可以在其中包含 AddressId 关系。这种方法的一个副作用是，当我返回并将 lat/long 添加到 Address 对象时，我的数据模型中的每个人也会获得这些新属性。

Answer 3

出于性能和设计可扩展性的原因，我也会使用混合解决方案。

我倾向于认为像users 这样的表（我也喜欢表名的复数形式）需要分解成一组核心数据，这些数据通常由其他对象作用，而那些基本上只写数据的扩展位在“region”、“middleinitial”、“shoesize”等规范可以转移到可扩展且更新频率较低的区域。

Answer 4

为什么不使用 XML 字段来存储不必要的附加信息。

这可以在配置文件中进行配置，您甚至可以更进一步，从配置中生成 UI 控件。