I del 1 av den här serien demonstrerade jag hur man installerar WordPress lokalt och hur man importerar en WordPress-databas till Vertabelo. I den här artikeln ska vi titta närmare på tabellerna i WordPress-databasen.
En snabb titt på WordPress-databasmodellen och instrumentpanelen
I föregående del importerade jag WordPress-databasen till vårt onlinedatabasmodelleringsverktyg. Databasens struktur är som följer:
Det finns ett par viktiga fakta om WordPress-databasmodellen som du bör förstå innan vi börjar:
- Varje WordPress-webbplats använder exakt samma databasstruktur. Den innehåller 11 tabeller och varje WordPress-webbplats använder dem i bakgrunden. De flesta WordPress-plugins använder också databasen utan några ändringar i databasmodellen. Modellen måste vara tillräckligt flexibel för att rymma alla olika plugins. Naturligtvis kan pluginskapare lägga till anpassade tabeller för specifika plugins om datastrukturen är väsentligt annorlunda eller om deras plugin lagrar stora mängder data.
- WordPress-databasen saknar begränsningar för främmande nyckel . Detta beror på att WordPress använder MyISAM-lagringsmotorn, som inte stöder främmande nycklar. Tabeller kringgår detta genom att ha attribut som lagrar oanslutna "främmande nyckel"-liknande värden, så att den främmande nyckeln inte kontrolleras av databasen. Till exempel,
post_authorattribut iwp_poststabellen är en "referens" till "ID"-attributet iwp_userstabell. - De flesta av tabellerna använder en primärnyckel för en kolumn. De heter antingen helt enkelt "ID" (i
wp_usersochwp_poststabell), ellermeta_id/umeta_id(i metatabellerna:wp_postmeta,wp_commentmetaochwp_usermeta), eller en kombination av tabellnamnet och suffixet "_id" (alla andra tabeller). Det enda undantaget från dessa regler ärwp_term_relationshipstabell, där primärnyckeln består av de två attributen:object_idochterm_taxonomy_id. Attribut som är primärnyckel eller en del av en primärnyckel är av typen bigint(20). Primärnycklar med enstaka attribut har också egenskapen auto-increment inställd på "Ja".
Inlägg och sidor
Den främsta anledningen till att använda WordPress är att skapa och manipulera innehåll och presentera det för allmänheten. För detta ändamål förser WordPress oss med två innehållstyper:Sidor och Inlägg .
Sidor används för att visa statiskt innehåll . De använder inte taggar eller kategorier och är inte listade efter datum. De tillåter inte heller kommentarer eller delning på sociala medier. Sidor kan ha undersidor. Om oss sidor är bra exempel på denna typ.
Å andra sidan, Inlägg är listade efter datum och kan organiseras med kategorier och taggar . Inlägg kan användas i RSS-flöden, tack vare deras kronologiska ordning. Inlägg kan inte ha "underinlägg", men kommentarer och delningar i sociala medier är möjliga. Inlägg är i huvudsak blogginlägg. Detta är förståeligt, eftersom WordPress har utvecklats från en bloggplattform.
Den primära tabellen bakom innehåll på alla WordPress-sidor kallas wp_posts :
WordPress använder wp_posts tabell för att lagra sidor, inlägg och bilagor. Vi kan se den här tabellen som kärnan på vår sida, platsen där det mesta av innehållet lagras. Det är viktigt att påpeka att bilagor faktiskt lagras på disken och posten i wp_posts Tabellen innehåller mer information om den (vem laddade upp den och när, etc.).
Fälten i wp_posts tabellen är:
post_author– en referens tillwp_userstabell, som anger inläggets författare.post_date– datum och tid när posten infogades i tabellen.post_date_gmt– GMT/UTC datum och tid när en post infogades i tabellen.post_content– det faktiska innehållet i inlägget.post_title– rubriken på inlägget.post_excerpt– en sammanfattning av innehållet.post_status– aktuell poststatus. WordPress använder 8 standardstatusar:"Publicera", "Framtid", "Utkast", "Väntande", "Privat", "Papperskorgen", "Auto-utkast" och "Ärva".comment_status– aktiverar och inaktiverar kommentarer på ett enskilt inlägg eller på en hel sida. Det finns två möjliga värden:"öppen" och "stängd".ping_status– identifierar om ett inlägg tillåter pingbacks och trackbacks. Somcomment_status, den kan bara innehålla värdena "öppen" och "stängd".post_password– lösenordet som används för att se inlägget (valfritt).post_name– den mänskligt läsbara webbadressen till enpost_title.to_ping– en lista över webbadresser som WordPress ska skicka pingbacks till, avgränsad med "\n".pinged– en lista över webbadresser som WordPress har skickat pingbacks till, avgränsad med "\n".post_modified– det senaste datumet och tiden då ett inlägg ändrades.post_modified_gmt– GMT/UTC-datumet förpost_modified.post_content_filtered– används av plugins för att cachelagra dyra omvandlingar av inläggsinnehåll.post_parent– refererar till det överordnade inlägget.guid– Global unik identifierare för ett inlägg; dess permanenta URL.menu_order– används för beställning av innehåll.post_type– typen av post. Den kan innehålla värdena "post", "page", "attachment" eller användardefinierade anpassade typer.post_mime_type– den typ av uppladdade filer som endast definieras för inlägg medpost_type = attachment. Den kan innehålla värden som "image", "application/pdf" och "application/msword".comment_count– inläggets antal kommentarer, pingbacks och trackbacks.
Här är en ögonblicksbild av wp_posts tabell efter att jag lagt till sidan "Om Nikola Tesla":
När vi tittar på wp_posts tabell kan vi se några versioner av vår sida. Posten med ID = 1 har post_status = publish , vilket innebär att inlägget är synligt för alla. comment_status = closed och ping_status = closed anger att kommentarer och pingar är inaktiverade för det här inlägget.
All ytterligare information om inlägg och sidor sparas i wp_postmeta tabell:
Kolumnerna i denna tabell är följande:
meta_id– tabellens primärnyckel.post_id– en referens tillwp_poststabell.meta_key– en beskrivning av ettmeta_valueattribut.meta_value– det faktiska lagrade värdet.
wp_postmeta Tabellen är där all information som inte kan sparas i wp_posts bordet lagras. Det lagras som nyckel-värde-par, en teknik som ofta kallas entitet-attribut-värde (EAV). Tabellen kan användas av plugins för anpassade behov.
WordPress-taxonomier
Taxonomi är ett fint ord som i grund och botten syftar på att gruppera saker tillsammans. WordPress har ett par inbyggda taxonomier för att gruppera inlägg. Till exempel kategorier och taggar är inbyggda WordPress-taxonomier. Du kan också lägga till dina egna anpassade taxonomier till WordPress.
Taxonomierna och deras termer finns i tabeller som kallas wp_terms , wp_term_taxonomy och wp_term_relationships .
wp_terms Tabell lagrar en lista över termer som används för att klassificera objekt på din WordPress-webbplats:
Den här tabellen innehåller alla tagg- och kategorinamn, såväl som termer från våra anpassade taxonomier. Attributen är följande:
term_id– tabellens primärnyckel.name– termens namn.slug– URL:en förname.term_group– används för att gruppera termer.
Här är innehållet i vår exempelsidas wp_terms tabell:
Termerna tilldelas taxonomier med hjälp av wp_term_taxonomy tabell:
Attributen i tabellen är:
term_taxonomy_id– tabellens primärnyckel.term_id– hänvisningen tillwp_termstabell.taxonomy– taxonominamnet.description– en beskrivning av en term i den specifika taxonomin.parent– en referens till den överordnade termen iwp_termstabell.count– antalet objekt iwp_poststabell som använder denna term i denna taxonomi.
wp_term_taxonomy tabell gör det möjligt för oss att återanvända samma term över olika taxonomier. Observera att posten var term_id = 1 har taxonomy = category , medan de andra posterna har taxonomy = post_tag .
Att relatera objekt sparade i wp_posts och wp_term_taxonomy tabeller använder WordPress wp_term_relationships tabell:
Observera att detta är den enda tabellen i modellen som har en nyckel som består av mer än ett attribut.
wp_term_relationships tabellen har följande attribut:
object_id– en referens tillwp_poststabell.term_taxonomy_id– en referens tillwp_term_taxonomytabell.term_order– termen ordning för ett specifikt objekt.
Vi har sex poster här som kopplar samman sex poster från wp_term_taxonomy tabell med inlägget (object_id = 6 ).
Kommentarer och WordPress-datamodellering
Vi lyckades placera lite innehåll på vår WordPress-sida. Det är trevligt, men i de flesta fall vill vi få feedback från allmänheten. Och det är rollen för kommentarsfunktionen.
För att se kommentarer på inlägg kan vi helt enkelt använda "Lämna en kommentar" eller klicka på "X Comment" (där X står för antalet kommentarer för inlägget).
Vårt första inlägg har redan en kommentar. När vi klickar på den ser vi att det är en automatisk kommentar som orsakas av pingback. Vi lägger till ytterligare en kommentar till det inlägget:
Vi ser nu två kommentarer till vårt inlägg, men vad ligger bakom det hela i databasen?
Du kan gissa från tabellnamnet att wp_comments Tabellen används för att lagra kommentarer på vår WordPress-sida:
Attributen är oftast självförklarande, men vi kommer ändå att titta närmare på några av dem.
comment_post_ID är en referens till wp_posts tabell; det anger vilket inlägg som har fått kommentarer. För den första kommentaren kan vi se att det faktiskt var pingback och att "författaren" är ett annat inlägg. För den andra kommentaren kan vi se att jag är författaren. Lägg även märke till comment_agent innehåller lite grundläggande information om systemet och datorn som används för att posta en kommentar.
Huvudidén bakom alla tre metatabellerna i modellen är att lagra data som vi inte vill lagra i vår primära tabell. wp_commentmeta är relaterat till wp_comments tabellen på samma sätt som wp_postmeta tabellen är relaterad till wp_posts bord.
Se WordPress-användare
När vår sida är online kan vem som helst se den. WordPress-användare är de som, enligt deras tillståndsstatus, kan göra ändringar på vår webbplats och dess innehåll.
Nu ska vi kika in i wp_users och wp_usermeta tabeller i MySQL-databasen.
Som förväntat, wp_users Tabellen ovan lagrar grundläggande data för alla användare som är registrerade på vår WordPress-webbplats. Observera att user_pass är krypterad och att NewUser har user_activation_key attribut ifyllt medan edrkusic har det fältet tomt.
Medan-attribut som anges i wp_users tabellen är vad vi kan förvänta oss på alla WordPress-webbplatser, wp_usermeta Tabell används för att lagra värden som kan vara specifika för ett visst projekt:
Observera till exempel att posten med umeta_id = 25 innehåller värdet "viss biografisk information" , samma text som vi skrev i instrumentpanelen när vi redigerade NewUser. user_id attributet i den posten har värde 2 , som motsvarar den Nya Användarens ID i wp_users tabell. Uppenbarligen är user_id är en referens till wp_users bord.
Länkar och alternativ i WordPress
Tanken bakom wp_links Tabellen är för att lagra länkar till andra webbplatser:
Att ha länkar till andra sajter var väldigt populärt i början av bloggartiden; numera används den mindre och mindre. Från och med WordPress version 3.5 togs länkadministrationen till och med bort från administratörsgränssnittet. Ändå hålls den här tabellen för att ge kompatibilitet med äldre versioner.
wp_options Tabell lagrar data om WordPress-installation, webbplatskonfiguration, tema, plugins och widgets:
Den används också för att lagra tillfällig cachad data. EAV-logiken finns också i den här tabellen, som den är i wp_usermeta , wp_postmeta och wp_commentmeta . Attributet option_name spelar rollen som nyckel, medan attributet option_value är dess motsvarande värde. De andra två attributen i tabellen är det primära nyckelattributet option_id och autoload , som styr om ett alternativ automatiskt laddas från databasen.
Utvärdering av WordPresss databasmodell
Databasmodellen bakom WordPress följer inte flera bra databasdesignregler och konventioner. När vi designar en databas för ett specifikt ändamål, och känner till alla dess önskade funktioner i förväg, kan vi följa alla dessa regler. Men WordPress måste täcka allt som vem som helst kan tänka sig, så att offra främmande nycklar och använda EAV är något som måste göras. Jag skulle namnge ID-attributet likadant i alla tabeller och göra detsamma med "främmande nycklar". Jag skulle till exempel inte använda post_author i wp_posts tabell, men jag skulle hålla mig till users_id . Förutom detta måste jag hålla med om att WordPress-databasen verkligen är en bra modell för sitt syfte.
Vad tror du? Låt oss veta i kommentarsfältet.