我正在为一个网站开发用户配置文件系统,并在思考什么是更好(可扩展)的方法.我想出了两个解决方案,我正在寻找任何输入或指向我可能错过的东西.
以下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表以控制其对其他用户的可见性或者可能被视为额外开销是否有利?