Когда дело доходит до работы с проектами на основе WordPress, возможно, один из самых разочаровывающих или утомительных аспектов развертывания — это синхронизация баз данных во всех средах.
Конечно, есть что сказать об использовании тестовых данных при разработке, пользовательских данных при подготовке и реальных данных при производстве, но не существует такой вещи, как серебряная пуля, верно? Это означает, что иногда тестовые данные будут работать; в других случаях это не так.
Например, предположим, что вы наследуете проект, для которого вам нужно свернуть базу данных, а затем начать работать с существующими данными. Или, скажем, вам нужно перенести весь сайт или приложение с одного сервера на другой.
В таких случаях тестовые данные не очень помогают. Вместо этого вам нужен инструмент для этого. И, конечно же, WordPress Importer — хороший инструмент для базовых миграций, и запуск экспорта и импорта SQL — это нормально, если вы знакомы с интерфейсами базы данных и работаете с самим SQL.
Но как насчет тех, кто где-то посередине?
Упрощение миграции
Правда в том, что когда дело доходит до работы с миграциями баз данных WordPress, это смешанный пакет, потому что у многих из нас уровни квалификации варьируются в зависимости от того, с какой частью стека мы работаем больше всего.
Под этим я подразумеваю:
- Те, кому гораздо удобнее работать с интерфейсом, скорее всего, будут менее знакомы с уровнем приложений и / или уровнем базы данных.
- Те, кто привык работать с прикладным уровнем, могут также хорошо работать с внешним интерфейсом, но не с базой данных (или наоборот)
- Те, кто живет в базе данных, могут не чувствовать себя комфортно с уровнями выше
Это не значит, что нет разработчиков полного стека. Очевидно, что есть; однако не все находятся в таком положении.
Поэтому, когда дело доходит до работы по переносу баз данных WordPress, некоторым из них гораздо труднее, чем другим. В качестве альтернативы, несмотря на уровень комфорта с SQL, некоторые могут искать инструмент, который бы облегчил весь процесс.
В этой серии мы рассмотрим утилиту, которая делает именно это, но прежде чем мы это сделаем, давайте быстро ознакомимся с базой данных WordPress, чтобы убедиться, что мы все на одной странице.
База данных WordPress
Когда дело доходит до обсуждения базы данных WordPress, можно написать целый ряд статей о каждой таблице, каждом столбце, схеме, о том, как писать оптимальные запросы и так далее.
Это не серия для этого.
Вместо этого мы собираемся сделать две вещи в этой статье:
- Мы собираемся сделать так, чтобы у всех нас было четкое, концептуальное понимание того, что такое база данных, чтобы мы знали, как представить ее себе в уме
- Мы рассмотрим каждую таблицу в базе данных WordPress, чтобы понять, какие данные содержит каждая таблица.
В конечном счете, это должно помочь объяснить или демистифицировать некоторые из базовых работ для тех, кто проводит больше времени во внешнем интерфейсе, и это может помочь тем, кто проводит больше времени на прикладном уровне, работающем с API WordPress, понять, какие функции соответствуют какой таблице. (что в конечном итоге может привести к написанию лучшего кода).
Что такое база данных?
Вообще говоря, я думаю, что большинство читателей Wptuts + знают, что такое база данных.
Прямо из Википедии :
База данных представляет собой организованный сбор данных. Данные, как правило, организованы для моделирования соответствующих аспектов реальности (например, наличия номеров в отелях) таким образом, чтобы поддерживать процессы, требующие этой информации (например, поиск отеля с вакансиями).
Это справедливое определение, но я не думаю, что оно так хорошо иллюстрирует базу данных WordPress или аналогичные веб-приложения — это слишком общее понятие. Итак, давайте создадим наше собственное рабочее определение, которое мы сможем использовать в оставшейся части серии.
Давайте попробуем это:
База данных состоит как минимум из одной таблицы. Таблица состоит из строк и столбцов, в каждом из которых хранятся уникальные фрагменты информации. Каждый ряд называется записью. В базе данных может существовать несколько таблиц, и иногда таблицы могут быть связаны друг с другом.
Возможно, самая запутанная часть того, что я поделился выше, это то, что таблицы могут быть связаны друг с другом. Мы вернемся к этой идее до конца статьи — но сначала давайте обсудим базу данных WordPress.
Схема базы данных WordPress
Короче говоря, база данных WordPress состоит из одиннадцати таблиц (если вы не используете мультисайт, но это выходит за рамки этой серии).
Теперь каждая таблица также имеет свой собственный набор столбцов, которые представляют различную информацию, хранящуюся в таблице. Например, в таблице wp_posts есть столбец с именем post_content , представляющий фактическое содержимое, которое хранится в записи.
Таблицы и их описания следующие:
- wp_users содержит список пользователей, которые зарегистрированы с установкой WordPress. Это включает в себя такие вещи, как адрес электронной почты, пароль, отображаемое имя и так далее.
- wp_usermeta содержит информацию, связанную с каждым пользователем. Здесь вы можете хранить дополнительную информацию о каждом пользователе.
- В wp_posts хранится вся информация постов. По правде говоря, не имеет значения, является ли это сообщение, страница или пользовательский тип сообщения — вся информация, такая как заголовок, содержание и многое другое, хранится здесь.
- В wp_postmeta хранятся метаданные для каждого сообщения. Эта таблица позволяет сохранять и получать дополнительную информацию о каждом сообщении.
- В wp_comments хранятся комментарии к каждому сообщению (опять же, независимо от типа).
- wp_commentmeta, как и другие «мета» таблицы, позволяет хранить больше информации о каждом комментарии, чем то, что уже сохранено в таблице комментариев.
- В wp_terms хранятся категории и теги. Поскольку отношения между публикациями, страницами, пользовательскими типами записей, категориями и тегами могут стать немного более сложными, существует несколько дополнительных таблиц.
- wp_term_taxonomy предоставляет описание категории или тега (или даже ссылки, если вы все еще используете их) в таблице wp_terms .
- wp_term_relationship хранит отношения из данного поста к его категории (или категориям) и / или тегу (или тегам).
- В wp_options хранятся все настройки — в том числе те, которые поставляются и настроены с помощью WordPress, и те, которые созданы с помощью API настроек .
- wp_links — это таблица, которая все еще существует в базе данных WordPress, несмотря на то, что для данных больше нет опции пользовательского интерфейса. Если вы когда-либо использовали эту функцию, то вы знакомы со ссылками и с тем, как они работают, и это таблица, в которой они хранятся.
И это все, что есть в базе данных WordPress. Это относительно просто и понятно, правда?
Сообщения хранятся в таблице сообщений, Комментарии в таблице комментариев, Пользователи в таблице пользователей и т. Д. Конечно, есть некоторые тонкие нюансы (например, тот факт, что страницы хранятся в таблице сообщений); тем не менее, это относительно простая схема для подражания.
Это хорошая вещь.
Кроме того, помните, как мы упоминали ранее, что некоторые таблицы могут ссылаться друг на друга? Хороший пример этого — таблица комментариев и таблица сообщений. Так как комментарии к конкретному сообщению оставляются, тогда для комментария необходимо знать, с каким идентификатором записи он связан, чтобы при загрузке публикации можно было получить комментарии, связанные с идентификатором этой записи.
В любом случае, это более детально, чем мы рассмотрим в этой серии, но, надеюсь, этого достаточно, чтобы дать вам идею. Если вам нужна дополнительная техническая информация, взаимосвязи между таблицами, столбцами и т. Д., Тогда обязательно ознакомьтесь со статьей WordPress Codex в описании базы данных .
Вывод
К этому моменту мы рассмотрели все, что нам нужно, в нашем учебнике по базе данных WordPress. Надеемся, что это помогает отодвинуть занавес в будущее, когда вы сохраняете информацию в WordPress, но теперь, когда мы рассмотрели этот вопрос, пришло время взглянуть на инструмент, который делает работу с миграциями данных чрезвычайно простой.
И, учитывая, что у нас теперь есть понимание того, как организована база данных, мы также должны понимать, как работают миграции.