我正在为网站开发用户配置文件系统,并且正在考虑采取什么更好(可扩展)的方法。我提出了两种解决方案,正在寻找输入或可能是我可能错过的东西的指针。
下面的 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 表中以控制它们对其他用户的可见性是否有利,或者这可能被视为额外开销?