我有 3 个用于会员系统的 MySQL 表。
-
users：成为用户的最低要求，仅与帐户信息相关（电子邮件、密码、is_activated 等）
-
user_profiles：用户提供的个人信息（姓名、地址、电话...）
-
user_member_profiles：管理员严格管理的信息（缴纳的注册费、参加的会议等）
这些可以压缩到一张表中，这样可以减轻我的麻烦并保持代码干净 - 但我觉得最好将它们分开，因为它们的用途略有不同。
选项1：就这样吧，继续做JOIN又乏味UPDATEs （这条数据进入这个表，这条数据进入另一个表，等等）。对我来说更多的工作，但也许这更有意义？
选项2：将所有内容合并到一张表中。
我认为使用一张表会更快，不需要连接表。也许这取决于数据？每个表大约有12-20个字段，因此合并后的表会很大。
每个用户在每个表中拥有不超过 1 个个人资料，但甚至可能根本没有个人资料（或者可能总共只有 1 个）。
添加一点背景信息：这是一个用 PHP 编写的不断发展的 CMS，我需要对每次安装的表进行调整。管理员需要以类似电子表格的方式管理成员，因此我一次最多选择 200 个用户。
从性能、设计或组织的角度来看，正确的方法是什么？
宽表（多列）需要考虑的另一个因素是对 RDBMS 缓存的影响。任何优秀的开发人员都知道，您不会执行“select * from table”，因为它会通过网络从 RDBMS 向客户端传输不必要的数据。但类似的效果也可能发生在磁盘和 RAM 之间，并且还会影响表需要缓存的 RAM 空间量。
大多数 RDBMS 分配给定的内存量来缓存数据，从而减少物理磁盘读取并加快对用户的响应。这是 Oracle 或 SQL Server 中的缓冲区高速缓存
如果您有一个宽表并以“从表中选择 col1、col2、col3”的形式发出查询，RDBMS 会将完整行加载到 RAM 中（不是 col1 到 3）。当它这样做时，旧的缓存数据将会老化。如果您的表很宽并且加载 50 列，那么您当然需要比相同行数 * 窄表更多的 RAM。这会对 RDBMS 性能产生显着影响。
很多宽表，从缓存中老化了其他表，并且可以看到 IO 统计数据彻底达到顶峰，因为常用表从缓存中老化，为宽表腾出空间。
应将此因素添加到标准化数据的其他优点中，并在表设计时予以考虑。实际上，如果您有一个潜在的宽表，其中一些数据将被定期访问，而另一些数据则很少被访问，请考虑具有 1 对 1 关系的多个表。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
