Дизайн для системы маркировки в GAE-J

Question

Мне нужна простая система тегов в GAE-J.

На мой взгляд, у тегируемого объекта должен быть набор ключей, относящихся к тегам, с которыми он связан.

Объект тега должен просто содержать саму строку тега и набор ключей, указывающих на объекты, связанные с тегом.

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

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

Answer 1

Зачем хранить таблицу Tags вообще? Это похоже на реляционную базу данных и не будет масштабируемым или особенно полезным для хранилища данных.

Вместо этого просто сохраните список строк для каждого тегируемого объекта.

@Persistent
private List<String> tags;

Получение тегов сущности будет простым поиском (вместо вызова хранилища данных), поиск других элементов с этим тегом будет простым вызовом хранилища данных:

Query query = pm.newQuery("select from Entities " +
                          "where tagNameParam in tags" +
                          "parameters String tagNameParam");

Это также сделает запись быстрее, так как вам не нужно проверять, существует ли тег, возможно создать новую строку в Tags и т. Д.

Однако не все так просто - найти все уникальные теги для всех сущностей.

Answer 2

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

В частности, нет способа использовать транзакции для обеспечения согласованности. Вы должны попытаться подготовить свой код для несовместимого хранилища данных. Другими словами, ключи в обоих объектах могут не ссылаться друг на друга, и ваш код не должен рушиться / падать / взрываться, если это так.