建议在内容的id（或key）中存储一些关于内容的信息（元数据）？

Question

建议在内容的Id（或密钥）中存储关于内容的一些信息（元数据）？

换句话说，我使用基于时间的UUID作为存储在数据库中的某些内容的ID（或键）。我的应用程序首先访问内容（来自数据库）的所有这些ID（或密钥）的列表，然后访问相应的内容（来自数据库）。这些ID实际上是UUID（基于时间）。我的想法是在Ids本身中存储一些关于内容的额外信息，以便我的软件可以访问此元数据内容，而无需再次访问数据库中的全部内容。

我的应用程序上下文是一个使用Java技术和Cassandra数据库的网站。 所以我的问题是，

1. 我是否应该这样做？我担心，因为可能需要大量处理（在向用户呈现数据时）以从内容的ID中检索元数据！因此，最好从数据库中检索它，然后通过处理该内容的Id来获取它。

2. 如果建议那么，我应该如何以有效的方式实施？我在想的方式如下： -

Id of a content = 'Timebased UUID' + 'UserId'

其中，'timebasedUUID'是基于当被用户& 'userId'加入该内容的时间戳生成的ID代表谁把用户的Id内容。

所以我的例子中的ID会是这个样子： - e4c0b9c0-a633-15a0-ac78-001b38952a49（TimeUUID）--ff7405dacd2b（用户ID）

我应该如何提取此userId从内容上面的编号，最有效的方式？

有没有更好的方法来将元信息存储在ID中？

Answer 1

我讨厌这么说，因为你似乎对此有过很多想法，但我会说这不可取。起初存储这样的数据听起来像是一个好主意，但最终会导致问题，因为读取和保存数据时会出现许多意想不到的问题。最好将单独的数据保存为单独的变量和列。

如果您真的有兴趣访问带有主要内容的元内容，我会创建两个列族。一个家庭拥有元内容，另一家拥有较大的主要内容，并且都拥有相同的ID密钥。我对卡桑德拉了解不多，但这似乎是推荐这种方式的方法。

我应该注意到，我不认为所有这些都是必要的。除非用户存储了大量的信息，否则他们的大小应该是微不足道的，并且您的检索应该保持快速。

Answer 2

我同意AmaDaden。混合身份证和数据是导致痛苦世界的第一步。特别是，您最终会发现业务逻辑需要更改数据部分并且数据库逻辑要求ID不会更改的情况。在你的例子中，关闭袖口，可能突然要求用户能够将两个帐户合并到单个用户ID。如果用户标识只是数据，这应该是一个微不足道的更新。如果它是ID的一部分，则需要查找并更新对该ID的所有引用。