În prima parte a acestei serii cu privire la datele din WordPress, am dat o imagine de ansamblu asupra tabelelor de baze de date WordPress și care tabele sunt folosite pentru a stoca ce fel de date. În această a doua parte, voi sublinia modul în care WordPress gestionează relațiile dintre aceste date.
După cum veți vedea, WordPress folosește trei tipuri de relații de date - unul la unul, unul la mulți și mulți la mulți. Mă voi uita la fiecare dintre acestea și ce înseamnă acestea pentru site-ul dvs. WordPress.
O relație one-to-one este cea mai simplă relație dintre toate - înseamnă pur și simplu că o înregistrare este legată doar de una singură. Datele de acest gen sunt în general stocate într-un singur tabel (deși nu întotdeauna, așa cum vom vedea mai târziu în acest tutorial).
Exemple de relații one-to-one în WordPress includ:
Lista ar putea continua, însă punctul principal este că orice două înregistrări stocate în diferite câmpuri într-un rând dintr-un tabel au o relație unu-la-unu.
Relațiile one-to-one sunt totuși cele mai puțin interesante tipuri de relații de bază de date. Așadar, fără a mai fi nevoie să trecem la un tip de relație folosit foarte mult de WordPress - unul-la-mulți.
Relațiile One-to-many sunt foarte frecvente în bazele de date și sunt ceea ce face ca o bază de date să fie mai puternică decât o masă "plat", cum ar fi o foaie de calcul. Acestea apar atunci când o înregistrare are o relație cu mai mult de o altă înregistrare.
În WordPress, cele mai multe relații una-la-multe sunt create de o legătură între două tabele de baze de date, folosind un identificator unic pentru a se alătura celor două. De exemplu, POST_ID
înregistrarea va fi unică pentru fiecare post stocat în wp_posts
tabel, dar va fi, de asemenea, utilizat în wp_comments
tabel pentru a identifica la care post a fost trimis fiecare comentariu. Asta înseamnă că fiecare POST_ID
valoarea va apărea o singură dată în wp_posts
dar ar putea apărea de mai multe ori - sau deloc - în wp_comments
masa.
Alte exemple în WordPress includ:
Din nou, lista continuă. Deoarece acesta este un subiect important în WordPress, să aruncăm o privire asupra relațiilor unu-la-multe în detaliu.
Tabelul care este conectat la cele mai multe alte tabele este wp_posts
tabelul și majoritatea relațiilor pe care aceste conexiuni le creează sunt relații una-la-multe.
După cum puteți vedea în diagrama de mai jos, wp_posts
tabelul este legat de alte patru tabele:
În plus, postările pot avea și o relație unu-cu-alte cu alte postări, sub formă de atașamente sau pagini părinte.
Să aruncăm o privire la aceste relații în detaliu.
Așa cum sa explicat mai sus, datele stocate în wp_posts
tabela poate avea o relație una cu mai multe cu alte date din același tabel; totuși, această relație nu este între ceea ce ați putea considera ca fiind postări, ci este între postări și atașamente sau pagini și alte pagini. La urma urmei, atașamentele și paginile sunt tipuri de posturi.
Un atașament stocat în wp_posts
tabel va avea o înregistrare în post_parent
câmp, care va fi identitatea postului la care este atașat atașamentul (cu scuze pentru repetare!). Aceasta este o relație una-la-multe, deoarece fiecare atașament va avea doar un părinte, în timp ce fiecare post ar putea avea mai multe atașamente. Acest lucru se va aplica chiar dacă ați utilizat Media Manager pentru a adăuga un atașament la un alt post - numai postul la care a fost adăugat inițial va fi stocat în bază de date ca părinte.
Postările pot avea, de asemenea, o relație unu-cu-multe cu alte postări atunci când o pagină este specificată ca părinte a altui post. Înregistrarea este stocată în pagina copil, în post_parent
câmp - din nou, acesta va fi POST_ID
din pagina părinte. Aceasta este o relație una-la-multe, deoarece paginile părinte pot avea multe pagini copil, dar paginile copil vor avea doar o pagină părinte.
Când vă gândiți la relațiile dintre postări de genul acesta, este important să rețineți că, atunci când se ia în considerare manipularea datelor de la WordPress, postările nu sunt cele despre care s-ar putea numi în mod normal postări. Acestea includ pagini, atașamente și alte tipuri de posturi, toate acestea fiind stocate în wp_posts
masa.
Mesajele postate sunt stocate în tabelul propriu wp_postmeta
. Acest tabel include doar patru câmpuri - pentru POST_ID
, meta_id
, cheia și valoarea. O postare poate fi asociată cu multe elemente de metadate postate, dar fiecare înregistrare a metadatelor post va fi legată doar de o postare.
Comentariile au și propriul tabel, wp_comments
. Fiecare comentariu se va referi la un singur post în timp ce fiecare postare poate avea mai multe comentarii stocate împotriva sa. Ca și în cazul celorlalte tabele legate de wp_posts
, POST_ID
câmpul este utilizat pentru legătura (în comment_post_id
domeniu în wp_comments
).
wp_comments
tabelul are în mod implicit 15 câmpuri, pentru a stoca date despre autor, adresa de e-mail a autorului, comentariul însuși și starea de aprobare a acestuia. De asemenea, este legat de wp_users
tabel, așa cum vom vedea în secțiunea următoare.
Comentariile au, de asemenea, propriile lor metadate, stocate într-un alt tabel, pe care o voi veni în curând.
Fiecare post este atașat la wp_users
tabel prin numele de utilizator
înregistrare, care este stocată în post_author
domeniu în wp_posts
. Aceasta este o relație una-la-multe, deoarece fiecare post are un singur autor, dar fiecare utilizator poate fi autorul mai multor postări.
Relația dintre posturi și utilizatori este diferită de aceea dintre postări și comentarii sau metadate, deoarece natura lor este de un singur utilizator, mai multe postări, nu unul trimite mai multe comentarii sau înregistrări de date de măsurare. Acesta este motivul pentru care numele de utilizator
câmpul oferă linkul în loc de POST_ID
camp.
Există, de asemenea, trei relații care sunt unu-la-multe și nu implică posturi. Două dintre acestea implică metadate - relația dintre comentarii și metadatele acestora, precum și utilizatorii și metadatele acestora.
WordPress stochează metadate suplimentare despre utilizatorii din wp_usermeta
masa. Acest lucru este utilizat, în general, pentru date non-standard despre utilizatori, cum ar fi metadatele despre superadminuri într-o instalare multisite și metadate despre culorile de administrare pe care un utilizator le-a selectat dacă acestea nu sunt implicite.
Cele mai multe date despre utilizatori vor fi în wp_users
masa. Cele două tabele sunt legate prin numele de utilizator
câmp și o înregistrare de utilizator vor avea mai multe elemente de metadate asociate cu acesta, în timp ce fiecare element de metadate se va aplica numai unui singur utilizator.
Din nou, majoritatea datelor despre comentarii sunt stocate în wp_comments
tabel împreună cu comentariul în sine, dar wp_commentmeta
tabel este utilizat pentru a stoca metadate suplimentare, cum ar fi datele create de plugin-uri cum ar fi Akismet. Relația este aceeași ca și între utilizatori și usermeta.
Ultima relație unu-la-multe este între comentarii și utilizatori. wp_comments
tabel include numele de utilizator
, care poate fi utilizat pentru a stoca ID-ul de utilizator atunci când un utilizator înregistrat a postat un comentariu. Rețineți că acest câmp nu este obligatoriu pentru site-urile în care utilizatorii nu trebuie să fie conectați pentru a comenta.
Ultimul tip de relație de bază de date este relația "unu-la-mulți", în care multitudinea de legături merge în ambele sensuri. Acest lucru este folosit doar o dată în WordPress, pentru termeni de taxonomie (inclusiv categorii și etichete, deoarece acestea sunt pur și simplu taxonomii). Un post poate avea numeroși termeni și un termen poate fi atribuit mai multor postări.
WordPress creează această relație în același mod ca orice altă bază de date cu o bază de date manay-to-many: utilizând o tabelă intermediară care leagă cele două tabele de datele cheie. Acesta este wp_term_relationships
tabel, care leagă wp_posts
tabel la wp_term_taxonomy
masa.
Notă: Acest tabel leagă de asemenea wp_links
tabel la wp_term_taxonomy
tabel, deoarece link-urile se comportă în același mod ca posturile - voi ajunge la linkuri în scurt timp.
Acest lucru este cel mai ușor de explicat prin căutarea mai întâi la cele două tabele periferice. wp_posts
tabel conține date despre fiecare post, în timp ce wp_term_taxonomy
tabelul conține date despre fiecare termen, inclusiv taxonomia în care se află și codul său de identificare.
Pentru a crea o legătură între un termen în wp_term_taxonomy
tabel și un post în wp_posts
tabel, WordPress creează o înregistrare în wp_term_relationships
tabel, care include POST_ID
si term_id
(stocate ca object_id
și term_taxonomy_id
respectiv în wp_term_relationships
masa). Aceasta înseamnă că wp_term_relationships
tabela poate include mai multe înregistrări pentru fiecare post și mai multe înregistrări pentru fiecare termen, creând relația multi-la-multe.
Diagrama de mai jos arată cum funcționează aceasta:
În exemplul de mai sus, posturile au următorii termeni:De asemenea, ați putea să vă uitați la aceasta în altă direcție - de exemplu, termenul 3 se referă la posturile 1 și 4.
Totuși lucrurile nu se opresc aici. Există un al patrulea tabel wp_terms
masa. Aceasta conține date despre fiecare termen, și anume numele, conținutul și descrierea pentru fiecare termen. Fiecare termen are o singură înregistrare în wp_terms
tabel, astfel încât relația dintre aceasta și wp_term_taxonomy
tabelul este de fapt unul la unul. Din punct de vedere teoretic, nu există nici un motiv ca aceste date să nu poată fi păstrate în wp_term_taxonomy
tabel, dar nu este.
Link-urile, sau blogroll-ul, este o caracteristică a WordPress, care este mult mai puțin proeminent decât a fost odată. De fapt, din moment ce link-urile versiunii 3.5 au fost dezactivate în mod implicit în admin; cu toate acestea, ei au propriul lor tabel: wp_links
masa.
Acest lucru este foarte similar cu wp_posts
masa. La urma urmei, link-urile sunt un tip de conținut foarte asemănător cu mesajele) și au aceleași relații multe-cu-multe cu termenii de taxonomie.
După cum am văzut, WordPress folosește o varietate de relații pentru a lega date în 10 din cele 11 tabele de baze de date. Singurul tabel pe care nu l-am menționat aici este wp_options
, deoarece nu este legată de alte tabele, deoarece stochează pur și simplu date despre site, nu despre conținut. Voi acoperi acest lucru în detaliu mai târziu în această serie.
Prin intelegerea relatiilor one-to-one, multi-multi si multe in WordPress, care va pot ajuta sa identificati modalitatile de a manipula datele si de a scrie intrebari personalizate in tema si / sau pluginurile.
În următoarea parte a acestei serii, voi detalia tipurile de conținut în detaliu, privind tipurile de conținut stocate în baza de date WordPress și asemănările și diferențele dintre ele.