是否建议将有关内容的一些信息（元数据）存储在该内容的 id（或密钥）中？
建议将有关内容的一些信息（元数据）存储在该内容的 Id（或密钥）中？
换句话说，我使用基于时间的 UUID 作为数据库中存储的某些内容的 Id（或键）。我的应用程序首先访问内容的所有此类 ID（或键）的列表（来自数据库），然后访问相应的内容（来自数据库）。这些 Id 实际上是 UUID（基于时间）。我的想法是在 Id 本身中存储一些有关内容的额外信息，以便我的软件可以访问此元内容，而无需再次访问数据库中的整个内容。
我的应用程序上下文是一个使用Java技术和Cassandra数据库的网站。 所以我的问题是，
我是否应该这样做？我很担心，因为可能需要进行大量处理（在向用户呈现数据时）才能从内容的 id 中检索元数据！因此，最好从数据库中检索它，然后通过处理该内容的 ID 来获取它。
如果有建议，我应该如何有效地实施？我正在考虑以下方式：-
Id of a content = 'Timebased UUID' + 'UserId'
其中，'timebasedUUID' 是根据时间戳生成的 ID内容是由用户添加的'userId' 表示放置该内容的用户的 ID。
所以我的示例 ID 看起来像这样：- e4c0b9c0-a633-15a0-ac78-001b38952a49(TimeUUID) -- ff7405dacd2b(UserId)
我应该如何以最有效的方式从上述内容 ID 中提取此 userId ？
是否有更好的方法在 Id 中存储元信息？
It is advisable to store some information(meta-data) about a content in the Id(or key) of that content ?
In other words, I am using a time based UUIDs as the Ids (or key) for some content stored in the database. My application first accesses the list of all such Ids(or keys) of the content (from the database) and then accessed the corresponding content(from the database). These Ids are actually UUIDs(time based). My idea is to store some extra information about the content, in the Ids itself, so that the my software can access this meta-content without accessing the entire content from the database again.
My application context is a website using Java technology and Cassandra database.
So my question is,
whether I should do so ? I am concerned since lots of processing may be required (at the time of presentation of data to user) in order to retrieve the meta data from the ids of the content!! Thus it may be instead better to retrieve it from database then getting it through processing of the Id of that content.
If suggested then , How should I implement that in an efficient manner ? I was thinking of following way :-
Id of a content = 'Timebased UUID' + 'UserId'
where, 'timebasedUUID' is the generated ID based on the timestamp when that content was added by a user & 'userId' represents the Id of the user who put that content.
so my example Id would look something like this:- e4c0b9c0-a633-15a0-ac78-001b38952a49(TimeUUID) -- ff7405dacd2b(UserId)
How should I extract this userId from the above id of the content, in most efficient manner?
Is there a better approach to store meta information in the Ids ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不想这么说，因为你似乎对此花了很多心思，但我想说这是不可取的。像这样存储数据一开始听起来是个好主意，但最终会导致问题，因为读取和保存数据时会遇到许多意想不到的问题。最好将单独的数据保留为单独的变量和列。
如果您真的有兴趣访问没有主要内容的元内容，我会创建两个列族。一个系列拥有元内容，另一个系列拥有较大的主要内容，并且两者共享相同的 ID 密钥。我对 Cassandra 不太了解，但这似乎是执行此类操作的推荐方法。
我应该指出，我认为这一切都是不必要的。除非用户存储大量信息，否则它们的大小应该很小，并且您对它们的检索应该保持快速
I hate to say it since you seem to have put a lot of thought into this but I would say this is not advisable. Storing data like this sounds like a good idea at first but ends up causing problems because you will have many unexpected issues reading and saving the data. It's best to keep separate data as separate variables and columns.
If you are really interested in accessing meta-content with out main content I would make two column families. One family has the meta-content and the other the larger main content and both share the same ID key. I don't know much about Cassandra but this seems to be the recommended way to do this sort of thing.
I should note that I don't think that all this will be necessary. Unless the users are storing very large amounts of information their size should be trivial and your retrievals of them should remain quick
我同意阿玛达登的观点。混合 ID 和数据是通往苦难世界的第一步。特别是，你最终会发现这样一种情况，业务逻辑要求数据部分改变，而数据库逻辑要求ID不改变。在您的示例中，可能会突然要求用户能够将两个帐户合并到一个用户 ID。如果用户 ID 只是数据，那么这应该是一个微不足道的更新。如果它是 ID 的一部分，您需要查找并更新对该 ID 的所有引用。
I agree with AmaDaden. Mixing IDs and data is the first step on a path that leads to a world of suffering. In particular, you will eventually find a situation where the business logic requires the data part to change and the database logic requires the ID not to change. Off the cuff, in your example, there might suddenly be a requirement for a user to be able to merge two accounts to a single user id. If user id is just data, this should be a trivial update. If it's part of the ID, you need to find and update all references to that id.