2015-04-26 3 views
3

Я довольно новичок в использовании Wordpress и не знаю, какое решение выбрать.Лучше ли создавать новые поля в таблице post в Wordpress или создавать новую таблицу

Я должен хранить более 200 000 записей (книг, компакт-дисков, ...) в таблице сообщений Wordpress. Каждая из этих записей содержит около 20 различных полей.

Поэтому я думаю, что мне нужно будет добавить новые поля в таблицу сообщений, чтобы хранить данные.

Я использую плагин пользовательских полей ACF для этого, но я вижу, что пользовательские поля не хранятся в той же таблице, что и столбец. Он хранится в таблице wp_options для категорий и в таблице postmeta для сообщений, и для каждого заполняемого поля будет создаваться 2 строки в этих таблицах.

Так что, если я сохраню 20 полей X 2 строки X 200.000 записей в этой таблице wp_postmeta, он будет делать 8.000.000 строк, чтобы пройти (возможно, не так хорошо для выступлений).

Что было бы лучшим способом достичь этой задачи с помощью Wordpress?

  • Создать новый стол? (Я не буду использовать возможности регулярных сообщений и возможности кеша)

  • Добавить новые поля в стол сообщения? (совместимо ли оно с обновлением WP?)

  • Использовать таблицы послемета/опции? (как насчет выступлений в этом случае?) и продолжить это решение?

Большого спасибо по заранее за вашу помощь

ответ

1

Есть плюсы и минусы каждого из подходов вы перечисляете:


Создать новую таблицу? (Я не буду извлекать выгоду из обычных почтовых функций и возможностей кэша)

Pro: Performance
Con: Гибкость Особенности

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

Характеристики Используя этот подход, вы не сможете использовать встроенные методы для взаимодействия с метаданными (ex get_post_meta). У вас также будет труднее запрашивать сообщения на основе ваших метаданных. Вы все еще можете кэшировать свои данные, но вам придется делать это вручную. Вам не будет иметь возможность продолжать использовать ACF с таким подходом, насколько мне известно.

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


Использование PostMeta/опционные таблицы? (как насчет выступлений в этом случае?) и продолжить это решение?

Con: Гибкость Особенности
Pro: Performance

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

Что касается производительности, вы не сможете создавать индексы, чтобы повысить производительность ваших запросов, как и в отдельной таблице. Это серьезная проблема, если ваши запросы не могут использовать индексы в таблице postmeta.

Отметьте, что wp_postmeta имеет индексы на post_id и meta_key, но не meta_value. Это означает, что если вы просматриваете записи, основанные на метазначении, и у вас много строк, которые используют один и тот же мета-ключ, база данных должна просматривать все строки с определенным мета-ключом, чтобы найти те, у которых есть мета которую вы ищете.

Так что, если я сохранить 20 полей X 2 строки X 200.000 записей в этой таблице wp_postmeta, он будет делать 8.000.000 линии, чтобы пройти через

Это не может быть серьезной проблемой, в зависимости от ваших запросов , Как я упоминал ранее, таблица postmeta имеет индекс на post_id, поэтому, если вы просматриваете мета-записи только post_id, это не является серьезной проблемой.

8 миллионов строк не проблема для MySQL, так как ваши запросы могут использовать индекс.

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


Добавить новые поля в таблице пост? (совместимо ли оно с обновлением WP?)

Этот подход собирается быть в значительной степени так же, как создать отдельную таблицу:

  • Вы будете иметь больше возможностей для повышения производительности за счет индексации ваших сообщений таблицы
  • Вы не будете иметь возможность использовать встроенные функции для взаимодействия с мета-данными
  • Добавление и удаление полей будет сложнее

Я не думаю это вызовет проблему с обновлением WordPress. Даже если обновление включает в себя изменения в таблице wp_posts, наличие дополнительных столбцов не должно вызвать проблемы. Я бы определенно испытал обновления в промежуточной среде перед обновлением в производстве.

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

+0

Очень плохой и неправильный ответ о качестве. Индекс не сохраняет данные, поэтому у вас есть n больше доступа к диску вместо использования таблицы n-column. Но 8 миллионов ячеек данных просто не много и хорошо вписываются в даже небольшую ОЗУ VPS. Если данные не очень разные для большого количества предметов, лучше хранить их в дополнительных таблицах. Или, если дополнительные поля данных не требуются для поиска, используйте объект JSON, чтобы сохранить его в одном метаданных. – Lothar

+0

@ Lothar Что касается создания дополнительных таблиц, разве это не то, что я сказал? Более эффективно создавать дополнительные таблицы в целом, но это не то, как WordPress работает из коробки. В то время, когда это было написано, ACF не предоставила никаких функций для работы с дополнительными таблицами, и насколько я знаю, это не то, что в настоящее время поддерживается. Если вы создадите дополнительные таблицы, вы потеряете все функции ACF, которые будут стоить значительное время разработки. –

Смежные вопросы