Желательно ли хранить некоторую информацию (метаданные) о контенте в идентификаторе (или ключе) этого контента?

Question

Желательно хранить некоторую информацию (метаданные) о контенте в Id (или ключе) этого контента?

Другими словами, я использую UUID на основе времени в качестве идентификаторов (или ключей) для некоторого контента, хранящегося в базе данных. Мое приложение сначала обращается к списку всех таких идентификаторов (или ключей) содержимого (из базы данных), а затем обращается к соответствующему содержимому (из базы данных). Эти идентификаторы на самом деле являются UUID (основанными на времени). Моя идея состоит в том, чтобы хранить некоторую дополнительную информацию о контенте в самих идентификаторах, чтобы мое программное обеспечение могло получить доступ к этому мета-контенту без повторного доступа ко всему контенту из базы данных.

Мой контекст приложения - это веб-сайт, использующий технологию Java и базу данных Cassandra. Итак, мой вопрос,

1. должен ли я это сделать? Я обеспокоен тем, что может потребоваться много обработки (во время представления данных пользователю), чтобы извлечь метаданные из идентификаторов содержимого !! Таким образом, вместо этого может быть лучше извлечь его из базы данных, чем получать его путем обработки идентификатора этого содержимого.

2. Если предложено тогда, как мне реализовать это эффективным образом? Я думал о следующем пути: -

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

где, 'timebasedUUID' - сгенерированный идентификатор, основанный на отметке времени, когда этот контент был добавлен пользователем, и 'userId' - идентификатор пользователя, который поместил этот контент.

поэтому мой пример Id будет выглядеть примерно так: - e4c0b9c0-a633-15a0-ac78-001b38952a49 (TimeUUID) -- ff7405dacd2b (UserId)

Как мне извлечь это userId из вышеуказанного идентификатора содержимого наиболее эффективным способом?

Есть ли лучший способ хранения метаданных в идентификаторах?

Answer 1

Мне неприятно это говорить, поскольку вы, кажется, много об этом думаете, но я бы сказал, что это не рекомендуется. Вначале сохранение таких данных звучит как хорошая идея, но в итоге вызывает проблемы, потому что у вас будет много неожиданных проблем при чтении и сохранении данных. Лучше хранить отдельные данные в виде отдельных переменных и столбцов.

Если вы действительно заинтересованы в доступе к мета-контенту без основного контента, я бы сделал два семейства столбцов. Одна семья имеет мета-контент, а другая - более крупный основной контент, и оба имеют один и тот же ключ ID. Я не знаю много о Кассандре, но это, кажется, рекомендуемый способ сделать подобные вещи.

Я должен отметить, что я не думаю, что все это будет необходимо. Если пользователи не хранят очень большие объемы информации, их размер должен быть тривиальным, а поиск их должен оставаться быстрым

Answer 2

Я согласен с AmaDaden. Смешивание идентификаторов и данных - это первый шаг на пути к миру страданий. В частности, вы в конечном итоге найдете ситуацию, когда бизнес-логика требует изменения части данных, а логика базы данных требует, чтобы идентификатор не менялся. В вашем примере, неожиданно для пользователя может возникнуть необходимость объединить две учетные записи в один идентификатор пользователя. Если идентификатор пользователя - это просто данные, это должно быть тривиальным обновлением. Если это часть идентификатора, вам нужно найти и обновить все ссылки на этот идентификатор.