当前位置:  开发笔记 > 编程语言 > 正文

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

如何解决《选择存储用户配置文件的方法?》经验,为你挑选了0个好方法。

我正在为一个网站开发用户配置文件系统,并在思考什么是更好(可扩展)的方法.我想出了两个解决方案,我正在寻找任何输入或指向我可能错过的东西.

以下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表以控制其对其他用户的可见性或者可能被视为额外开销是否有利?

推荐阅读
保佑欣疼你的芯疼
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有