sql >> Database teknologi >  >> RDS >> Database

WordPress – Bag kulisserne, del 2

I del 1 af denne serie demonstrerede jeg, hvordan man installerer WordPress lokalt, og hvordan man importerer en WordPress-database til Vertabelo. I denne artikel ser vi nærmere på tabellerne i WordPress-databasen.

Et hurtigt kig på WordPress-databasemodellen og dashboardet

I den forrige del importerede jeg WordPress-databasen til vores online-databasemodelleringsværktøj. For en god ordens skyld er strukturen af ​​databasen som følger:




Der er et par vigtige fakta om WordPress-databasemodellen, du bør forstå, før vi går i gang:

  • Hvert WordPress-websted bruger nøjagtig den samme databasestruktur. Den indeholder 11 tabeller, og hver WordPress-side bruger dem i baggrunden. De fleste WordPress-plugins bruger også databasen uden ændringer i databasemodellen. Modellen skal være fleksibel nok til at kunne rumme alle de forskellige plugins. Selvfølgelig kan plugin-skabere tilføje tilpassede tabeller til specifikke plugins, hvis datastrukturen er væsentligt anderledes, eller hvis deres plugin gemmer store mængder data.
  • WordPress-databasen mangler fremmednøglebegrænsninger . Dette skyldes, at WordPress bruger MyISAM-lagringsmotoren, som ikke understøtter fremmednøgler. Tabeller løser dette ved at have attributter, der gemmer ikke-forbundne "fremmednøgle"-lignende værdier, så den fremmede nøgle-begrænsning vil ikke blive kontrolleret af databasen. For eksempel post_author attribut i wp_posts tabel er en "reference" til "ID"-attributten i wp_users tabel.
  • De fleste af tabellerne bruger en enkelt kolonne primær nøgle. De hedder enten blot "ID" (i wp_users og wp_posts tabel), eller meta_id /umeta_id (i metatabellerne:wp_postmeta , wp_commentmeta og wp_usermeta ), eller en kombination af tabelnavnet og suffikset "_id" (alle andre tabeller). Den eneste undtagelse fra disse regler er wp_term_relationships tabel, hvor den primære nøgle består af de to attributter:object_id og term_taxonomy_id . Attributter, der er primærnøgle eller en del af en primærnøgle, er af typen bigint(20). Primære nøgler med enkelt attribut har også egenskaben for automatisk stigning indstillet til "Ja".

Indlæg og sider

Hovedårsagen til at bruge WordPress er at skabe og manipulere indhold og præsentere det for offentligheden. Til det formål giver WordPress os to indholdstyper:Sider og Indlæg .

Sider bruges til at vise statisk indhold . De bruger ikke tags eller kategorier og er ikke opført efter dato. De tillader heller ikke kommentarer eller deling på sociale medier. Sider kan have undersider. Om os sider er gode eksempler på denne type.

På den anden side, Indlæg er opført efter dato og kan organiseres ved hjælp af kategorier og tags . Indlæg kan bruges i RSS-feeds takket være deres kronologiske rækkefølge. Indlæg kan ikke have "underopslag", men kommentarer og delinger på sociale medier er mulige. Indlæg er i bund og grund blogindlæg. Dette er forståeligt, eftersom WordPress er udviklet fra en bloggingplatform.

Den primære tabel bag indhold på enhver WordPress-side kaldes wp_posts :

WordPress bruger wp_posts tabel til at gemme sider, indlæg og vedhæftede filer. Vi kan se på denne tabel som kernen på vores side, det sted hvor det meste af indholdet er gemt. Det er vigtigt at påpege, at vedhæftede filer faktisk er gemt på disken og posten i wp_posts tabel gemmer flere oplysninger om det (hvem uploadede det og hvornår osv.).

Felterne i wp_posts tabellen er:

  • post_author – en reference til wp_users tabel, der angiver forfatteren af ​​indlægget.
  • post_date – dato og klokkeslæt, hvor posten blev indsat i tabellen.
  • post_date_gmt – GMT/UTC-datoen og -klokkeslættet, hvor en post blev indsat i tabellen.
  • post_content – det faktiske indhold af indlægget.
  • post_title – titlen på indlægget.
  • post_excerpt – en oversigt over indholdet.
  • post_status – den aktuelle poststatus. WordPress bruger 8 standardstatusser:"Publicer", "Future", "Kladde", "Afventer", "Privat", "Papirkurv", "Auto-Kladde" og "Arv".
  • comment_status – slår kommentarer til og fra på et enkelt indlæg eller på en hel side. Der er to mulige værdier:"åben" og "lukket".
  • ping_status – identificerer, om et indlæg tillader pingbacks og trackbacks. Ligesom comment_status , kan den kun indeholde værdierne "åben" og "lukket".
  • post_password – adgangskoden, der bruges til at se indlægget (valgfrit).
  • post_name – den menneskelæselige url til en post_title .
  • to_ping – en liste over URL'er, WordPress skal sende pingbacks til, afgrænset af "\n".
  • pinged – en liste over URL'er, WordPress har sendt pingbacks til, afgrænset af "\n".
  • post_modified – den seneste dato og det seneste tidspunkt, hvor et indlæg blev ændret.
  • post_modified_gmt – GMT/UTC-datoen for post_modified .
  • post_content_filtered – bruges af plugins til at cache dyre postindholdstransformationer.
  • post_parent – henviser til det overordnede indlæg.
  • guid – Global Unique Identifier for en stilling; dens permanente URL.
  • menu_order – bruges til indholdsbestilling.
  • post_type – typen af ​​registrering. Det kan indeholde værdierne "post", "side", "vedhæftet fil" eller brugerdefinerede brugerdefinerede typer.
  • post_mime_type – typen af ​​uploadede filer, der kun er defineret for indlæg med post_type = attachment . Det kan indeholde værdier som "image", "application/pdf" og "application/msword".
  • comment_count – indlæggets antal kommentarer, pingbacks og trackbacks.

Her er et øjebliksbillede af wp_posts tabel efter jeg tilføjede siden "Om Nikola Tesla":

Når vi tager et kig på wp_posts tabel, kan vi se et par versioner af vores side. Posten med ID = 1 har post_status = publish , hvilket betyder, at indlægget er synligt for alle. comment_status = closed og ping_status = closed angiver, at kommentarer og ping er deaktiveret for dette indlæg.

Alle yderligere oplysninger om indlæg og sider opbevares i wp_postmeta tabel:

Kolonnerne i denne tabel er som følger:

  • meta_id – tabellens primære nøgle.
  • post_id – en henvisning til wp_posts tabel.
  • meta_key – en beskrivelse af en meta_value attribut.
  • meta_value – den faktisk lagrede værdi.

wp_postmeta tabel er hvor alle oplysninger, der ikke kan gemmes i wp_posts bordet er gemt. Den er gemt som nøgleværdi-par, en teknik, der ofte kaldes entity-attribute-value (EAV). Tabellen kan bruges af plugins til brugerdefinerede behov.

WordPress-taksonomier

Taxonomi er et fancy ord, der dybest set refererer til at gruppere ting sammen. WordPress har et par indbyggede taksonomier til gruppering af indlæg. For eksempel kategorier og tags er indbyggede WordPress-taksonomier. Du kan også tilføje dine egne brugerdefinerede taksonomier til WordPress.

Taksonomierne og deres termer opbevares i tabeller kaldet wp_terms , wp_term_taxonomy , og wp_term_relationships .

wp_terms tabel gemmer en liste over termer, der bruges til at klassificere objekter på dit WordPress-websted:

Denne tabel indeholder alle tag- og kategorinavne samt termer fra vores tilpassede taksonomier. Attributterne er som følger:

  • term_id – tabellens primære nøgle.
  • name – navnet på udtrykket.
  • slug – URL'en til name .
  • term_group – bruges til at gruppere termer sammen.

Her er indholdet af vores eksempelwebsteds wp_terms tabel:

Begreberne tildeles taksonomier ved hjælp af wp_term_taxonomy tabel:

Attributterne i tabellen er:

  • term_taxonomy_id – tabellens primære nøgle.
  • term_id – henvisningen til wp_terms tabel.
  • taxonomy – taksonominavnet.
  • description – en beskrivelse af et udtryk i den pågældende taksonomi.
  • parent – en reference til det overordnede udtryk i wp_terms tabel.
  • count – antallet af objekter i wp_posts tabel, der bruger dette udtryk i denne taksonomi.

wp_term_taxonomy tabel gør det muligt for os at genbruge det samme udtryk på tværs af forskellige taksonomier. Bemærk, at posten var term_id = 1 har taxonomy = category , mens de andre poster har taxonomy = post_tag .

At relatere objekter gemt i wp_posts og wp_term_taxonomy tabeller, bruger WordPress wp_term_relationships tabel:

Bemærk, at dette er den eneste tabel i modellen, der har en nøgle sammensat af mere end én attribut.

wp_term_relationships tabel har følgende attributter:

  • object_id – en henvisning til wp_posts tabel.
  • term_taxonomy_id – en reference til wp_term_taxonomy tabel.
  • term_order – termen rækkefølge for et bestemt objekt.

Vi har seks poster her, der forbinder seks poster fra wp_term_taxonomy tabel med posten (object_id = 6 ).

Kommentarer og WordPress-datamodellering

Det lykkedes os at placere noget indhold på vores WordPress-side. Det er rart, men i de fleste tilfælde vil vi gerne have feedback fra offentligheden. Og det er kommentarfunktionens rolle.

For at se kommentarer til indlæg kan vi blot bruge "Skriv en kommentar" eller klikke på "X Comment" (hvor X står for antallet af kommentarer til indlægget).

Vores første indlæg har allerede en kommentar. Når vi klikker på det, vil vi se, at det er en automatisk kommentar forårsaget af pingback. Vi tilføjer endnu en kommentar til det indlæg:

Vi ser nu to kommentarer til vores indlæg, men hvad ligger bag det hele i databasen?

Du kan gætte ud fra tabelnavnet, at wp_comments tabel bruges til at gemme kommentarer på vores WordPress-side:

Egenskaberne er for det meste selvforklarende, men vi vil stadig se nærmere på nogle af dem.

comment_post_ID er en reference til wp_posts bord; det angiver, hvilket indlæg der har modtaget kommentarer. For den første kommentar kan vi se, at det faktisk var pingback, og at "forfatteren" er et andet indlæg. For den anden kommentar kan vi se, at jeg er forfatteren. Bemærk også comment_agent indeholder nogle grundlæggende oplysninger om systemet og computeren, der bruges til at skrive en kommentar.

Hovedideen bag alle tre metatabeller i modellen er at gemme data, som vi ikke ønsker at gemme i vores primære tabel. wp_commentmeta er relateret til wp_comments tabellen på samme måde som wp_postmeta tabellen er relateret til wp_posts tabel.

Se WordPress-brugere

Når vores side er online, kan alle se den. WordPress-brugere er dem, der i henhold til deres tilladelsesstatus kan foretage ændringer på vores side og dets indhold.

Nu kigger vi ind i wp_users og wp_usermeta tabeller i MySQL-databasen.

Som forventet er wp_users tabel vist ovenfor gemmer grundlæggende data for alle brugere, der er registreret på vores WordPress-side. Bemærk, at user_pass er krypteret, og at NewUser har user_activation_key attribut udfyldt, mens edrkusic har feltet tomt.

Mens attributter er angivet i wp_users tabellen er, hvad vi ville forvente på ethvert WordPress-websted, wp_usermeta tabel bruges til at gemme værdier, der kan være specifikke for et bestemt projekt:

Bemærk f.eks., at posten med umeta_id = 25 indeholder værdien "nogle biografiske oplysninger" , den samme tekst, som vi skrev i dashboardet, mens vi redigerede NewUser. user_id attribut i denne post har værdi 2 , som svarer til den nye brugers ID i wp_users bord. Det er klart, at user_id er en reference til wp_users tabel.

Links og muligheder i WordPress

Ideen bag wp_links tabel er at gemme links til andre websteder:

At have links til andre websteder var meget populært i begyndelsen af ​​blogging-æraen; i dag bruges den mindre og mindre. Fra WordPress version 3.5 og frem blev linkadministration endda fjernet fra admin-grænsefladen. Alligevel opbevares denne tabel for at give kompatibilitet med ældre versioner.

wp_options tabel gemmer data om WordPress-installation, webstedskonfiguration, tema, plugins og widgets:

Det bruges også til at gemme midlertidige cachelagrede data. EAV-logikken er også til stede i denne tabel, som den er i wp_usermeta , wp_postmeta og wp_commentmeta . Attributten option_name spiller rollen som nøglen, mens attributten option_value er dens tilsvarende værdi. De to andre attributter i tabellen er den primære nøgleattribut option_id og autoload , som kontrollerer, om en indstilling automatisk indlæses fra databasen.

Evaluering af WordPress’ databasemodel

Databasemodellen bag WordPress følger ikke flere gode databasedesignregler og -konventioner. Når vi designer en database til et bestemt formål og kender alle dens ønskede funktionaliteter på forhånd, kan vi følge alle disse regler. Men WordPress skal dække alt, som enhver kunne have i tankerne, så at ofre fremmednøgler og bruge EAV er noget, der skal gøres. Jeg ville navngive ID-attributten det samme på tværs af alle tabellerne og gøre det samme med "fremmednøglerne". For eksempel ville jeg ikke bruge post_author i wp_posts tabel, men jeg ville holde mig til users_id . Bortset fra dette må jeg være enig i, at WordPress-databasen virkelig er en fantastisk model til sit formål.

Hvad synes du? Fortæl os det i kommentarfeltet.


  1. Sådan gendannes Galera Cluster- eller MySQL-replikation fra Split Brain Syndrome

  2. Konverter rækker til kolonner ved hjælp af 'Pivot' i SQL Server

  3. Hvilken type JOIN skal bruges

  4. Forstå log buffer skylninger