В част 1 от тази серия демонстрирах как да инсталирате WordPress локално и как да импортирате база данни на WordPress във Vertabelo. В тази статия ще разгледаме по-отблизо таблиците в базата данни на WordPress.
Бърз поглед към модела на базата данни на WordPress и таблото за управление
В предишната част импортирах базата данни WordPress в нашия онлайн инструмент за моделиране на база данни. За протокола структурата на базата данни е както следва:
Има няколко важни факта за модела на база данни на WordPress, които трябва да разберете, преди да започнем:
- Всеки сайт на WordPress използва точно същата структура на базата данни. Той съдържа 11 таблици и всеки сайт на WordPress ги използва във фонов режим. Повечето плъгини на WordPress също използват базата данни без никакви промени в модела на базата данни. Моделът трябва да бъде достатъчно гъвкав, за да побере всички различни плъгини. Разбира се, създателите на плъгини могат да добавят персонализирани таблици за конкретни плъгини, ако структурата на данните е значително различна или ако техният плъгин съхранява големи количества данни.
- В базата данни на WordPress липсват ограничения за външни ключове . Това се дължи на факта, че WordPress използва механизма за съхранение MyISAM, който не поддържа външни ключове. Таблиците заобикалят това, като имат атрибути, които съхраняват несвързани стойности, подобни на „външен ключ“, така че ограничението на външния ключ няма да се проверява от базата данни. Например
post_authorатрибут вwp_postsтаблицата е „препратка“ към атрибута „ID“ вwp_usersмаса. - Повечето от таблиците използват първичен ключ от една колона. Те се наричат или просто „ID“ (в
wp_usersиwp_postsтаблица) илиmeta_id/umeta_id(в мета таблиците:wp_postmeta,wp_commentmetaиwp_usermeta), или комбинация от името на таблицата и наставката „_id“ (всички други таблици). Единственото изключение от тези правила еwp_term_relationshipsтаблица, където първичният ключ се състои от двата атрибута:object_idиterm_taxonomy_id. Атрибутите, които са първичен ключ или част от първичен ключ, са от типа bigint(20). Първичните ключове с един атрибут също имат свойството за автоматично увеличение, зададено на „Да“.
Публикации и страници
Основната причина да използвате WordPress е да създавате и манипулирате съдържание и да го представяте на обществеността. За тази цел WordPress ни предоставя два типа съдържание:Страници и Публикации .
Страници се използват за показване на статично съдържание . Те не използват тагове или категории и не са изброени по дата. Освен това те не позволяват коментари или споделяне в социалните медии. Страниците могат да имат подстраници. За нас страниците са добри примери от този тип.
От друга страна, Публикации са изброени по дата и могат да бъдат организирани с помощта на категории и маркери . Публикациите могат да се използват в RSS емисии, благодарение на техния хронологичен ред. Публикациите не могат да имат „подпубликации“, но са възможни коментари и споделяния в социалните мрежи. Публикациите по същество са публикации в блогове. Това е разбираемо, тъй като WordPress еволюира от платформа за блогове.
Основната таблица зад съдържанието на всяка страница на WordPress се нарича wp_posts :
WordPress използва wp_posts таблица за съхраняване на страници, публикации и прикачени файлове. Можем да гледаме на тази таблица като на ядрото на нашата страница, мястото, където се съхранява по-голямата част от съдържанието. Важно е да се отбележи, че прикачените файлове всъщност се съхраняват на диска и записът в wp_posts таблицата съхранява повече информация за нея (кой я е качил и кога и т.н.).
Полетата в wp_posts таблицата са:
post_author– препратка къмwp_usersтаблица, обозначаваща автора на публикацията.post_date– датата и часа, когато записът е бил вмъкнат в таблицата.post_date_gmt– GMT/UTC дата и час, когато записът е бил вмъкнат в таблицата.post_content– действителното съдържание на публикацията.post_title– заглавието на публикацията.post_excerpt– резюме на съдържанието.post_status– текущото състояние на публикацията. WordPress използва 8 състояния по подразбиране:„Публикуване“, „Бъдеще“, „Чернова“, „Предстоящо“, „Частно“, „Кошче“, „Автоматично чернова“ и „Наследяване“.comment_status– включва и изключва коментарите на отделна публикация или на цяла страница. Има две възможни стойности:„отворено“ и „затворено“.ping_status– идентифицира дали публикацията позволява pingback и trackbacks. Харесайтеcomment_status, може да съдържа само стойностите „отворено“ и „затворено“.post_password– паролата, използвана за преглед на публикацията (по избор).post_name– четим от човека URL адрес наpost_title.to_ping– списък с URL адреси, на които WordPress трябва да изпраща pingbacks, разделен с „\n“.pinged– списък с URL адреси, на които WordPress е изпратил pingbacks, разделен с „\n“.post_modified– последната дата и час на промяна на публикацията.post_modified_gmt– датата по GMT/UTC заpost_modified.post_content_filtered– използва се от плъгини за кеширане на скъпи трансформации на съдържанието на публикациите.post_parent– препраща към родителската публикация.guid– Глобален уникален идентификатор за публикация; неговия постоянен URL.menu_order– използва се за подреждане на съдържание.post_type– вида на записа. Може да съдържа стойностите „публикация“, „страница“, „прикачен файл“ или потребителски дефинирани типове.post_mime_type– типът на качените файлове, дефинирани само за публикации сpost_type = attachment. Може да съдържа стойности като „image“, „application/pdf“ и „application/msword“.comment_count– броят на коментарите, pingbacks и trackbacks на публикацията.
Ето моментна снимка на wp_posts таблица, след като добавих страницата „За Никола Тесла“:
Когато разгледаме wp_posts таблица, можем да видим няколко версии на нашата страница. Записът с ID = 1 има post_status = publish , което означава, че публикацията е видима за всички. comment_status = closed и ping_status = closed обозначава, че коментарите и пинговете са забранени за тази публикация.
Всяка допълнителна информация за публикации и страници се съхранява в wp_postmeta таблица:
Колоните в тази таблица са както следва:
meta_id– първичният ключ на таблицата.post_id– препратка къмwp_postsмаса.meta_key– описание наmeta_valueатрибут.meta_value– действителната съхранена стойност.
wp_postmeta таблицата е мястото, където цялата информация, която не може да бъде запазена в wp_posts таблицата се съхранява. Съхранява се като двойки ключ-стойност, техника, която често се нарича обект-атрибут-стойност (EAV). Таблицата може да се използва от плъгини за персонализирани нужди.
Таксономии на WordPress
Таксономия е фантастична дума, която основно се отнася до групирането на нещата заедно. WordPress има няколко вградени таксономии за групиране на публикации. Например, категории и тагове са вградени таксономии на WordPress. Можете също да добавите свои собствени персонализирани таксономии към WordPress.
Таксономиите и техните термини се съхраняват в таблици, наречени wp_terms , wp_term_taxonomy и wp_term_relationships .
wp_terms таблицата съхранява списък с термини, използвани за класифициране на обекти във вашия WordPress сайт:
Тази таблица съдържа всички имена на етикети и категории, както и термини от нашите персонализирани таксономии. Атрибутите са както следва:
term_id– първичният ключ на таблицата.name– името на термина.slug– URL адресът наname.term_group– използва се за групиране на термини.
Ето съдържанието на wp_terms таблица:
Термините се присвояват на таксономии с помощта на wp_term_taxonomy таблица:
Атрибутите в таблицата са:
term_taxonomy_id– първичният ключ на таблицата.term_id– препратката къмwp_termsмаса.taxonomy– името на таксономията.description– описание на термин в тази конкретна таксономия.parent– препратка към родителския термин вwp_termsмаса.count– броят на обектите вwp_postsтаблица, които използват този термин в тази таксономия.
wp_term_taxonomy таблица ни позволява да използваме повторно един и същ термин в различни таксономии. Забележете, че записът, където term_id = 1 има taxonomy = category , докато другите записи имат taxonomy = post_tag .
За да свържете обекти, запазени в wp_posts и wp_term_taxonomy таблици, WordPress използва wp_term_relationships таблица:
Имайте предвид, че това е единствената таблица в модела, която има ключ, съставен от повече от един атрибут.
wp_term_relationships таблицата има следните атрибути:
object_id– препратка къмwp_postsмаса.term_taxonomy_id– препратка къмwp_term_taxonomyмаса.term_order– терминът поръчка за конкретен обект.
Тук имаме шест записа, които свързват шест записа от wp_term_taxonomy таблица с публикацията (object_id = 6 ).
Коментари и моделиране на данни в WordPress
Успяхме да поставим малко съдържание на нашата WordPress страница. Това е хубаво, но в повечето случаи искаме да получим обратна връзка от обществеността. И това е ролята на функцията за коментар.
За да видите коментари към публикации, можем просто да използваме „Оставете коментар“ или да щракнете върху „X Comment“ (където X означава броя на коментарите за публикацията).
Първата ни публикация вече има един коментар. Когато щракнем върху него, ще видим, че това е автоматичен коментар, причинен от pingback. Ще добавим още един коментар към тази публикация:
Сега виждаме два коментара за нашата публикация, но какво се крие зад всичко това в базата данни?
Можете да познаете от името на таблицата, че wp_comments таблицата се използва за съхраняване на коментари на нашата WordPress страница:
Атрибутите обикновено се обясняват сами, но все пак ще разгледаме някои от тях по-отблизо.
comment_post_ID е препратка към wp_posts маса; обозначава коя публикация е получила коментари. За първия коментар можем да видим, че всъщност е pingback и че „авторът“ е друга публикация. За втория коментар можем да видим, че аз съм авторът. Забележете също comment_agent съдържа основна информация за системата и компютъра, използвани за публикуване на коментар.
Основната идея зад трите мета таблици в модела е да съхраняваме данни, които не искаме да съхраняваме в основната си таблица. wp_commentmeta е свързан с wp_comments таблицата по същия начин като wp_postmeta таблицата е свързана с wp_posts таблица.
Виждане на потребители на WordPress
След като страницата ни е онлайн, всеки може да я види. Потребителите на WordPress са тези, които според статуса си на разрешение могат да правят промени в нашия сайт и неговото съдържание.
Сега ще надникнем в wp_users и wp_usermeta таблици в базата данни MySQL.
Както се очакваше, wp_users Таблицата, показана по-горе, съхранява основни данни за всички потребители, регистрирани на нашия WordPress сайт. Имайте предвид, че user_pass е криптиран и този NewUser има user_activation_key атрибутът е попълнен, докато edrkusic има това поле празно.
Докато атрибутите, изброени в wp_users таблицата са това, което бихме очаквали във всеки сайт на WordPress, wp_usermeta таблицата се използва за съхраняване на стойности, които може да са специфични за определен проект:
Например, забележете, че записът с umeta_id = 25 съдържа стойността „някои биографични данни“ , същият текст, който въведохме в таблото, докато редактирахме NewUser. user_id атрибутът в този запис има стойност 2 , което съответства на идентификатора на NewUser в wp_users маса. Очевидно user_id е препратка към wp_users таблица.
Връзки и опции в WordPress
Идеята зад wp_links таблица е за съхраняване на връзки към други сайтове:
Наличието на връзки към други сайтове беше много популярно в началото на ерата на блоговете; в днешно време се използва все по-рядко. От версия на WordPress 3.5 нататък администрацията на връзките дори беше премахната от администраторския интерфейс. Все пак тази таблица се запазва, за да осигури съвместимост с по-стари версии.
wp_options таблицата съхранява данни за инсталиране на WordPress, конфигурация на сайта, тема, плъгини и джаджи:
Използва се и за съхраняване на временни кеширани данни. Логиката на EAV също присъства в тази таблица, както е в wp_usermeta , wp_postmeta и wp_commentmeta . Атрибутът option_name играе ролята на ключа, докато атрибутът option_value е съответната му стойност. Другите два атрибута в таблицата са атрибутът на първичния ключ option_id и autoload , който контролира дали дадена опция се зарежда автоматично от базата данни.
Оценяване на модела на базата данни на WordPress
Моделът на база данни зад WordPress не следва няколко добри правила и конвенции за проектиране на база данни. Когато проектираме база данни за конкретна цел, знаейки предварително всичките й желани функционалности, можем да следваме всички тези правила. Но WordPress трябва да покрие всичко, което някой може да има предвид, така че жертването на външни ключове и използването на EAV е нещо, което трябва да се направи. Бих назовал атрибута ID еднакво във всички таблици и бих направил същото с „външните ключове“. Например, не бих използвал post_author в wp_posts таблица, но бих се придържал към users_id . Освен това трябва да се съглася, че базата данни на WordPress е наистина страхотен модел за целта си.
Какво мислиш? Уведомете ни в секцията за коментари.
