Intereting Posts
С точки зрения разработчика, каковы различия между страницами и сообщениями? Новый стиль меню меню wp Super post cleaner, может ли это быть конкретной категорией? Получение ссылок и названий изображений из галереи NextGEN Укажите домен в другой подкаталог веб-хостинга wordpress Как отображать аватар пользователя на странице своего профиля? Таксономические шаблоны … по иерархическому уровню? Выпускает ли плагин под AGPL, чтобы люди открывали исходную версию всей своей установки WordPress? Если расширенные пользовательские поля или / и инструкции Как я могу сделать логин, как на wordpress.org? Как обновить настройку темы после изменения цвета внутри wpColorPicker? Проблемы с CSS в Google Chrome Cron Job Keep Run, несмотря на то, что он отключен Произошла непредвиденная ошибка. Что-то может быть не так с WordPress.org или конфигурацией этого сервера Пользовательский запрос с DECIMAL (5,2)

Где хранить данные пользовательской маркировки, связанные с настраиваемым типом сообщения

Мое приложение позволяет пользователям добавлять теги к изображению (похожие на facebook). Каждый тег может состоять из 8 атрибутов, и в настоящее время нет ограничений на количество тегов, которые пользователь может добавить.

На данный момент информация тега хранится через 3 пары мета-ключ / значение. Каждое значение meta сообщения сериализуется перед сохранением.

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

ИМО существует два подхода:

  1. post meta key / value для каждого тега / атрибута (у этого есть потенциал для создания огромного набора данных – n тегов раз 8 атрибутов)

  2. Новая таблица только для тегов

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

Какой подход лучше?
Возможно ли еще один вариант?

Solutions Collecting From Web of "Где хранить данные пользовательской маркировки, связанные с настраиваемым типом сообщения"

Избегайте сериализации, когда можете. Он медленно читается, и вы не можете его искать.

Используйте пользовательские таблицы – более одного:

  1. Один для отношений между пользователями, тегами и изображениями: user_id , tag_id и image_id .
  2. Один для метаданных тегов, ваших атрибутов, если я понимаю это право: tag_id , meta_1 , meta_2

Теперь вы можете искать каждый идентификатор вложения, если есть запись для пользователя, а затем искать метаданные из мета-таблицы.

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

Вы можете зарегистрировать одну (или более) пользовательскую таксономию в отношении типа сообщения вложения.

Следующие страницы Codex – это хорошее место для начала:

Вы также можете найти вдохновение в существующих плагинах WordPress, которые предоставляют аналогичные функции, такие как http://plugins.trac.wordpress.org/browser/matts-community-tags/trunk