5

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

我见过其他实现，例如 Wordpress 的实现，它将用户的这些信息存储在一个名为usermetalayout的表中( 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吗？
我有时认为，如果性能在我的环境中是一个问题，那么这种布局可能不太合适，因为我会VARCHAR为我想要存储的每一种数据使用一个。

对于第二个问题：存储和选择/插入效率真的可以在我正在考虑的两种解决方案之间产生影响吗？
哪个解决方案应该比另一个解决方案更少（或更多）占用空间和/或更少（或更多）选择/插入效率，为什么？

4

3 回答 3

2

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

显然，更改日志对您来说是必不可少的，因此每个用户只有一行的原始结构不是您的解决方案。因此，我们正在讨论以下选择：

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

解决方案 1 对应于您的

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

解决方案 2 对应于 Wordpress 之一：

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 解决方案的缺点大于优点。缺点是：

  • 您必须开发一段数据透视代码来将一个用户的用户信息透视到
    一行。您必须在每个要获取一行用户信息的地方调用此代码。相反，Solution1 只需要

    SELECT userID,[all user info] 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 表（Email、Email、Email、Email、Email）中多次保存 meta_key 值，否则您需要一个额外的 Meta_Key_Lookup 表。

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

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

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

在这个问题上，我认为 Solution1 仍然获胜。在插入时，解决方案 1 获胜：即使用户更改了他们信息中的每个字段，也只插入一行。在 SELECTS 上，解决方案 1 再次获胜：您只需要查看每个用户的最新信息（上面的代码），这是 SQL 优化的对象。相反，Solution2 需要一个支点：SQL 不擅长的东西。

于 2012-11-19T18:25:15.980 回答
0

我同意@sebt 关于标准 SQL 解决方案的看法。

如果您需要 PostgreSQL 中的灵活解决方案，我会为您推荐 hstore 类型（postgresql 9.1 文档）。这种类型可以在一列中存储许多 key => value 对。
有许多可能的方法可以插入、搜索和索引此列。文档是开始查找的好方法。

于 2012-11-19T19:22:55.670 回答
0

最佳选择很大程度上取决于您想要做什么，因此您将运行哪些查询（与许多事情一样）。

我不太了解 WordPress（我知道您将单个字段存储为行，但我不知道它适合哪里），所以我将列出所有选项：

  1. 让用户和历史表每行存储单独的字段
  2. 只有历史表每行存储单个字段
  3. 每行只有用户表存储单个字段
  4. 没有每行存储单独的字段
  5. 有 1 个用于用户和历史记录的组合表
  6. 有 1 个组合表，用于存储每行的单个字段

(5) 和 (6) 在大多数情况下似乎并不是真正的选项，因为我怀疑您希望获取用户（或一群用户）的详细信息比获取历史记录更频繁（除非您的大多数查询是同时获取两者）。

不建议使用 (1) 和 (3)，除非许多细节没有填写（因此在其他情况下您最终会得到非常稀疏的表格）。

(4) 当用户倾向于一次更改所有详细信息时，这可能不会经常发生，我怀疑人们一次只更改 1 或 2 个字段。因此，(2) 可能是一个更好的选择，特别是如果用户表有很多字段（并且人们一次只更改 1 或 2 个字段）。

通常，每行存储单个字段是为了减少存储空间而不是性能（假设有一些空字段，否则每行存储单个字段会更糟），您基本上可以通过查看您的要求和预期数据来确定哪个是最好的. 请注意，我们在这里主要讨论的是选择，这通常是缓慢的操作，除非您有一些奇怪的事情发生，或者一次插入大量。对于历史，减少存储通常比性能更受青睐，因此 (2)。

无论如何，添加字段通常有点费力，所以只是说“更新用户添加列列”并不是什么大不了的事，它甚至可以自动化。这将是另一个（小）理由更喜欢（2）而不是（4）。

于 2012-11-23T14:03:29.643 回答