用户数据和更改日志的哪种布局是最有效的,更少的存储消耗？

Question

我的用户可以更新他们的信息,这些信息保存在表格中定义数量的列中,例如:user ( id INT, email VARCHAR, phone VARCHAR, address VARCHAR ).

我见过其他实现,比如Wordpress的实现,它将这些信息存储在一个usermeta用布局调用的表中( umeta_id INT, user_id INT, meta_key VARCHAR, meta_value VARCHAR ).

在我想要实现的更改日志中,我正在评估使用这样的解决方案或制作(我认为会更好),布局如下:userLog ( id INT, date TIMESTAMP, email VARCHAR, phone VARCHAR, address VARCHAR ).
因此,我可以记录任何用户在给定日期所拥有的所有信息.行只会记录更改,在未更改的列上具有NULL.

对于第一个问题:除了能够通过插入适当的方法创建新的信息类型之外,这种布局是否有任何优势meta_key？
我有时认为如果性能在我的环境中是一个问题,这种布局可能不太合适,因为我会使用a VARCHAR来存储我想要存储的每种数据.

对于第二个问题:存储和选择/插入效率真的可以改变我正在考虑的两种解决方案吗？
哪个解决方案应该比其他解决方案更少(或更多)占用空间和/或更少(或更多)选择/插入效率？为什么？

Answer 1

一些想法，如果不一定是答案：

显然，更改日志是您必须具备的，因此每个用户一行的原始结构不适合您。所以我们正在讨论以下之间的选择：

1. 每个用户的整个信息集的每个版本一行；或者
2. 每个用户信息项的每个版本一行

解决方案 1 对应于您的

userLog ( id INT, date TIMESTAMP, email VARCHAR, phone VARCHAR, address VARCHAR )

解决方案 2 对应于 WordPress 方案 1：

umeta_id INT, user_id INT, meta_key VARCHAR, meta_value VARCHAR

您的问题 1：我看不到解决方案 2 的任何优势，除了，如果您随后决定要捕获用户的（例如）网站 URL 或（例如）最喜欢的颜色，您可以通过添加 meta_key 来做到这一点。但是您可以在解决方案 1 下同样轻松地完成此操作，只需执行

ALTER TABLE userlog ADD COLUMN WebSiteURL(etc)

这并不难做到。除非你店里的 DBA 非常像杜宾犬 (;))。因为您持有更改日志，所以所有现有用户（在更改时）现在将有一个空白的 WebsiteURL 列；但这正是您想要的：您不知道他们的 WebsiteURL，因为系统之前没有捕获它。当然，新列必须是 NULLABLE - 但这可能是不可避免的，即使使用“初始”数据也是如此，除非您用于捕获用户信息的方法坚持将电子邮件、电话和地址作为必填列。

对我来说，meta_key 解决方案的缺点大于优点。缺点是：

• 您必须开发一段数据透视代码，将一个用户的用户信息透视到一行
  。您必须在想要获取一行中的用户信息的每个位置调用此代码。相比之下，解决方案1只需要

  SELECT userID,[所有用户信息] FROM userLog INNER JOIN (SELECT userID,MAX(datechanged) AS LatestDAteChanged FROM userlog GROUP BY userID) a ON userlog.userid=a.userID AND userlog.DateChanged=a.LatestDAteChanged

  这比枢轴更有效。通过 UserID,DateChanged 上的索引，这将像风一样运行。

• 除非您确实想在 userinfo 表中多次保存 meta_key 值（电子邮件、电子邮件、电子邮件、电子邮件、电子邮件），否则您需要一个额外的 Meta_Key_Lookup 表。

第二个问题： 为了最终的空间效率，是的，meta_key Solution2 是最好的。特别是如果您不使用 VARCHAR 元键，而是使用元键 ID 值，并且有一个单独的元键查找表（例如 1=电子邮件、2=电话等）。但考虑到存储价格几乎为零以及该解决方案所涉及的困难，我认为这并不是 meta_key Solution2 的决定性论据。

（注释/想法：恕我直言，您在解决方案1中保留 NULL 值的想法，其中值没有改变，是一条错误的道路。尝试获取最新电子邮件的编码，然后是电话，然后是每个地址（单独）用户，将是一场噩梦：几乎与其他解决方案所需的枢轴一样难以编码/测试 - 以及服务器运行 - 并且存储边际的减少。每次发生变化时只需保存整行。除非您只是给出示例，真实的用户信息集有 50 列宽...）

恕我直言，存储问题并不是决定性的。那么让我们转向 SELECT/INSERT 效率：

在这个问题上，我认为Solution1仍然胜出。在插入时，解决方案 1 获胜：即使用户更改其信息中的每个字段，也仅插入一行。在 SELECTS 上，解决方案 1 再次获胜：您只需要查看每个用户的最新信息（上面的代码），这正是 SQL 优化的目的。相反，解决方案 2 需要一个主元：这是 SQL 不擅长的。