Wes*_*rch 6 mysql database database-design relational-database
我有一个会员系统的3个MySQL表.
users:成为用户的最低要求,仅与帐户信息(电子邮件,密码,is_activated等)相关user_profiles:用户提供的个人信息(姓名,地址,电话......)user_member_profiles:由管理员严格管理的信息(已支付注册费,参加会议等)这些可以压缩到一个表格中,这样可以避免头痛并保持我的代码清洁 - 但我觉得最好将它们分开,因为它们的用途略有不同.
选项1:保持这种方式并继续做JOINs和乏味UPDATE的(这个数据转到这个表,这个数据转到另一个,等等).为我做更多的工作,但也许它更有意义？
选项2:将所有内容合并到一个表中.
我假设使用一个表会更快,不需要连接表.也许这取决于数据？每个表有大约12-20个字段,因此组合表将很大.
每个用户每个表中的配置文件不超过1个,但可能根本没有配置文件(或者可能只有1个配置文件).
为此添加一些上下文:它是用于用PHP编写的不断发展的CMS,我需要对每个安装的表进行调整.管理员需要以类似speadsheet的方式管理成员,因此我一次最多可以选择200个用户.
从绩效,设计或组织的角度来看,正确的方法是什么？
宽表(许多列)要考虑的另一个因素是对RDBMS缓存的影响.任何优秀的开发人员都知道你没有"从表中选择*",因为它会通过网络从RDBMS向客户端传输不必要的数据.但是在磁盘和RAM之间也会发生类似的影响,并且还会影响表缓存所需的RAM空间量.
大多数RDBMS分配给定量的内存来缓存数据,从而减少物理磁盘读取并加快对用户的响应.这是Oracle或SQL Server中的缓冲区缓存
如果你有一个宽表并以'select col1,col2,col3 from table'的形式发出查询,那么RDBMS会将完整的行加载到RAM中(而不是col1到3).因为它会这样老化缓存数据.如果你的表很宽并且你加载50列你当然需要更多的RAM而不是相同的行数*一个窄表.这可能会对RDBMS性能产生显着影响.
很多宽表,从缓存中老化其他表,并且可以看到IO统计数据彻底改变,因为常用表从缓存中老化以为宽表腾出空间.
应将此因素添加到标准化数据的其他优点中,并在表格设计时考虑.实际上,如果您有一个可能很宽的表,其中一些数据将定期访问,而另一些数据很少,请考虑具有1对1关系的多个表.