W części 1 tej serii pokazałem, jak zainstalować WordPress lokalnie i jak zaimportować bazę danych WordPress do Vertabelo. W tym artykule przyjrzymy się bliżej tabelom w bazie danych WordPress.
Szybkie spojrzenie na model bazy danych WordPress i pulpit nawigacyjny
W poprzedniej części zaimportowałem bazę danych WordPress do naszego internetowego narzędzia do modelowania baz danych. Dla porządku struktura bazy danych jest następująca:
Jest kilka ważnych faktów na temat modelu bazy danych WordPress, które powinieneś zrozumieć, zanim zaczniemy:
- Każda witryna WordPress używa dokładnie tej samej struktury bazy danych. Zawiera 11 tabel i każda witryna WordPress używa ich w tle. Większość wtyczek do WordPressa korzysta również z bazy danych bez zmian w modelu bazy danych. Model musi być wystarczająco elastyczny, aby pomieścić wszystkie różne wtyczki. Oczywiście twórcy wtyczek mogą dodawać niestandardowe tabele dla określonych wtyczek, jeśli struktura danych znacznie się różni lub jeśli ich wtyczka przechowuje duże ilości danych.
- Baza danych WordPress nie ma ograniczeń dotyczących kluczy obcych . Wynika to z faktu, że WordPress korzysta z silnika pamięci MyISAM, który nie obsługuje kluczy obcych. Tabele obchodzą ten problem, posiadając atrybuty, które przechowują niepowiązane wartości podobne do „klucza obcego”, więc ograniczenie klucza obcego nie zostanie sprawdzone przez bazę danych. Na przykład
post_authoratrybut wwp_poststabela jest „odniesieniem” do atrybutu „ID” wwp_usersstół. - Większość tabel używa klucza podstawowego z pojedynczą kolumną. Nazywają się po prostu „ID” (w
wp_usersiwp_poststable) lubmeta_id/umeta_id(w metatabeli:wp_postmeta,wp_commentmetaiwp_usermeta) lub kombinacją nazwy tabeli i przyrostka „_id” (wszystkie pozostałe tabele). Jedynym wyjątkiem od tych zasad jestwp_term_relationshipstabela, w której klucz podstawowy składa się z dwóch atrybutów:object_iditerm_taxonomy_id. Atrybuty, które są kluczem podstawowym lub częścią klucza podstawowego, są typu bigint(20). Klucze podstawowe z jednym atrybutem mają również właściwość automatycznego przyrostu ustawioną na „Tak”.
Wpisy i strony
Głównym powodem korzystania z WordPressa jest tworzenie i manipulowanie treścią oraz prezentowanie jej publicznie. W tym celu WordPress udostępnia nam dwa rodzaje treści:Strony i posty .
Strony służą do wyświetlania treści statycznej . Nie używają tagów ani kategorii i nie są uporządkowane według dat. Nie pozwalają też na komentarze ani udostępnianie w mediach społecznościowych. Strony mogą mieć podstrony. O nas strony są dobrymi przykładami tego typu.
Z drugiej strony posty są wymienione według dat i można je uporządkować za pomocą kategorii i tagi . Posty mogą być wykorzystywane w kanałach RSS dzięki ich kolejności chronologicznej. Posty nie mogą zawierać „podpostów”, ale możliwe są komentarze i udostępnianie w mediach społecznościowych. Posty to zasadniczo posty na blogu. Jest to zrozumiałe, ponieważ WordPress wyewoluował z platformy blogowej.
Podstawowa tabela za treścią na dowolnej stronie WordPress nosi nazwę wp_posts :
WordPress używa wp_posts tabela do przechowywania stron, postów i załączników. Możemy spojrzeć na tę tabelę jako rdzeń naszej strony, miejsce, w którym przechowywana jest większość treści. Należy podkreślić, że załączniki są faktycznie przechowywane na dysku, a rekord w wp_posts tabela zawiera więcej informacji na jego temat (kto ją przesłał i kiedy, itp.).
Pola w wp_posts tabela to:
post_author– odniesienie dowp_userstabela, oznaczająca autora posta.post_date– data i godzina wstawienia rekordu do tabeli.post_date_gmt– data i godzina GMT/UTC, kiedy rekord został wstawiony do tabeli.post_content– rzeczywista treść posta.post_title– tytuł posta.post_excerpt– podsumowanie treści.post_status– aktualny status poczty. WordPress używa 8 domyślnych statusów:„Publikuj”, „Przyszłość”, „Szkic”, „Oczekuje”, „Prywatny”, „Kosz”, „Automatyczny szkic” i „Odziedzicz”.comment_status– włącza i wyłącza komentarze w pojedynczym poście lub na całej stronie. Możliwe są dwie wartości:„otwarte” i „zamknięte”.ping_status– określa, czy post zezwala na pingbacki i trackbacki. Jakcomment_status, może zawierać tylko wartości „otwarte” i „zamknięte”.post_password– hasło używane do przeglądania wpisu (opcjonalnie).post_name– czytelny dla człowieka adres URLpost_title.to_ping– lista adresów URL, do których WordPress powinien wysyłać pingbacki, oddzielonych „\n”.pinged– lista adresów URL, do których WordPress wysłał pingbacki, oddzielonych „\n”.post_modified– najnowsza data i godzina modyfikacji wpisu.post_modified_gmt– data GMT/UTC dlapost_modified.post_content_filtered– używane przez wtyczki do buforowania kosztownych przekształceń treści postów.post_parent– odwołuje się do wpisu nadrzędnego.guid– Unikatowy identyfikator globalny dla stanowiska; jego stały adres URL.menu_order– używane do zamawiania treści.post_type– rodzaj rekordu. Może zawierać wartości „post”, „strona”, „załącznik” lub niestandardowe typy zdefiniowane przez użytkownika.post_mime_type– typ wgrywanych plików zdefiniowany tylko dla postów zpost_type = attachment. Może zawierać wartości takie jak „obraz”, „aplikacja/pdf” i „aplikacja/msword”.comment_count– liczba komentarzy, pingbacków i trackbacków do posta.
Oto migawka wp_posts tabela po dodaniu strony „O Nikoli Tesli”:
Kiedy spojrzymy na wp_posts tabeli, możemy zobaczyć kilka wersji naszej strony. Rekord z ID = 1 ma post_status = publish , co oznacza, że wpis jest widoczny dla wszystkich. comment_status = closed i ping_status = closed oznacza, że komentarze i pingi są wyłączone dla tego posta.
Wszelkie dodatkowe informacje o postach i stronach są przechowywane w wp_postmeta tabela:
Kolumny w tej tabeli są następujące:
meta_id– klucz podstawowy tabeli.post_id– odniesienie dowp_postsstół.meta_key– opismeta_valueatrybut.meta_value– rzeczywista przechowywana wartość.
wp_postmeta tabela zawiera wszystkie informacje, których nie można zapisać w wp_posts tabela jest przechowywana. Jest przechowywany jako pary klucz-wartość, technika często nazywana element-atrybut-wartość (EAV). Tabela może być używana przez wtyczki do niestandardowych potrzeb.
Taksonomie WordPressa
Taksonomia to fantazyjne słowo, które zasadniczo odnosi się do grupowania rzeczy. WordPress ma kilka wbudowanych taksonomii do grupowania postów. Na przykład kategorie i tagi są wbudowanymi taksonomiami WordPress. Możesz także dodać do WordPressa własne, niestandardowe taksonomie.
Taksonomie i ich terminy są przechowywane w tabelach o nazwie wp_terms , wp_term_taxonomy i wp_term_relationships .
wp_terms tabela przechowuje listę terminów używanych do klasyfikowania obiektów w witrynie WordPress:
Ta tabela zawiera wszystkie nazwy tagów i kategorii, a także terminy z naszych niestandardowych taksonomii. Atrybuty są następujące:
term_id– klucz podstawowy tabeli.name– nazwa terminu.slug– adres URLname.term_group– używane do grupowania terminów.
Oto zawartość wp_terms tabela:
Terminy są przypisywane do taksonomii za pomocą wp_term_taxonomy tabela:
Atrybuty w tabeli to:
term_taxonomy_id– klucz podstawowy tabeli.term_id– odniesienie dowp_termsstół.taxonomy– nazwa taksonomii.description– opis terminu w tej konkretnej taksonomii.parent– odniesienie do terminu nadrzędnego wwp_termsstół.count– liczba obiektów wwp_poststabeli, która używa tego terminu w tej taksonomii.
wp_term_taxonomy Tabela umożliwia nam ponowne użycie tego samego terminu w różnych taksonomii. Zwróć uwagę, że rekord, w którym term_id = 1 ma taxonomy = category , podczas gdy pozostałe rekordy mają taxonomy = post_tag .
Aby powiązać obiekty zapisane w wp_posts i wp_term_taxonomy tabele, WordPress używa wp_term_relationships tabela:
Zauważ, że jest to jedyna tabela w modelu, która ma klucz złożony z więcej niż jednego atrybutu.
wp_term_relationships tabela ma następujące atrybuty:
object_id– odniesienie dowp_postsstół.term_taxonomy_id– odniesienie dowp_term_taxonomystół.term_order– termin zamówienie dla konkretnego obiektu.
Mamy tu sześć rekordów, które łączą sześć rekordów z wp_term_taxonomy tabela z wpisem (object_id = 6 ).
Komentarze i modelowanie danych WordPress
Udało nam się umieścić trochę treści na naszej stronie WordPress. To miłe, ale w większości przypadków chcemy uzyskać informację zwrotną od opinii publicznej. I to jest rola funkcji komentarzy.
Aby wyświetlić komentarze do postów, możemy po prostu użyć opcji „Zostaw komentarz” lub kliknąć „Komentarz X” (gdzie X oznacza liczbę komentarzy do posta).
Nasz pierwszy post ma już jeden komentarz. Kiedy go klikniemy, zobaczymy, że jest to automatyczny komentarz spowodowany pingbackiem. Dodamy jeszcze jeden komentarz do tego posta:
Widzimy teraz dwa komentarze do naszego posta, ale co kryje się za tym wszystkim w bazie danych?
Z nazwy tabeli można się domyślić, że wp_comments tabela służy do przechowywania komentarzy na naszej stronie WordPress:
Atrybuty są w większości oczywiste, ale nadal przyjrzymy się niektórym z nich bliżej.
comment_post_ID jest odniesieniem do wp_posts stół; wskazuje, który post otrzymał komentarze. W przypadku pierwszego komentarza widzimy, że faktycznie był to pingback, a „autor” to kolejny post. W przypadku drugiego komentarza widzimy, że jestem autorem. Zwróć także uwagę na comment_agent zawiera podstawowe informacje o systemie i komputerze używanym do publikowania komentarza.
Główną ideą stojącą za wszystkimi trzema metatablicami w modelu jest przechowywanie danych, których nie chcemy przechowywać w naszej tabeli podstawowej. Meta wp_commentmeta jest powiązany z wp_comments tabeli w taki sam sposób, jak wp_postmeta tabela jest powiązana z wp_posts tabela.
Widzimy użytkowników WordPressa
Gdy nasza strona jest już online, każdy może ją zobaczyć. Użytkownicy WordPressa to ci, którzy zgodnie ze statusem uprawnień mogą dokonywać zmian w naszej witrynie i jej zawartości.
Teraz zajrzymy do wp_users i wp_usermeta tabele w bazie danych MySQL.
Zgodnie z oczekiwaniami wp_users Powyższa tabela przechowuje podstawowe dane dla wszystkich użytkowników zarejestrowanych w naszym serwisie WordPress. Zwróć uwagę, że user_pass jest zaszyfrowany, a NewUser ma user_activation_key atrybut wypełniony, podczas gdy edrkusic ma to pole puste.
Chociaż atrybuty wymienione w wp_users tabela jest tym, czego oczekiwalibyśmy w dowolnej witrynie WordPress, wp_usermeta tabela służy do przechowywania wartości, które mogą być specyficzne dla określonego projektu:
Na przykład zwróć uwagę, że rekord z umeta_id = 25 zawiera wartość „niektóre informacje biograficzne” , ten sam tekst, który wpisaliśmy w dashboardzie podczas edycji NewUser. user_id atrybut w tym rekordzie ma wartość 2 , który odpowiada identyfikatorowi NewUser w wp_users stół. Oczywiście user_id jest odniesieniem do wp_users tabela.
Linki i opcje w WordPress
Idea wp_links tabela służy do przechowywania linków do innych witryn:
Posiadanie linków do innych stron było bardzo popularne na początku ery blogów; obecnie jest coraz rzadziej używany. Od wersji 3.5 WordPressa administracja linkami została nawet usunięta z interfejsu administratora. Mimo to tabela ta jest zachowana, aby zapewnić zgodność ze starszymi wersjami.
wp_options tabela przechowuje dane o instalacji WordPress, konfiguracji witryny, motywie, wtyczkach i widżetach:
Służy również do przechowywania tymczasowych danych w pamięci podręcznej. Logika EAV jest również obecna w tej tabeli, tak jak w wp_usermeta , wp_postmeta i wp_commentmeta . Atrybut option_name pełni rolę klucza, natomiast atrybut option_value jest jego odpowiednią wartością. Pozostałe dwa atrybuty w tabeli to atrybut klucza podstawowego option_id i autoload , który kontroluje, czy opcja jest automatycznie ładowana z bazy danych.
Ocena modelu bazy danych WordPress
Model bazy danych stojący za WordPressem nie jest zgodny z kilkoma dobrymi zasadami i konwencjami projektowania baz danych. Kiedy projektujemy bazę danych w określonym celu, znając z góry wszystkie jej pożądane funkcjonalności, możemy przestrzegać wszystkich tych zasad. Ale WordPress musi obejmować wszystko, co każdy może mieć na myśli, więc poświęcenie kluczy obcych i użycie EAV to coś, co należy zrobić. Nazwałbym atrybut ID tak samo we wszystkich tabelach i zrobiłbym to samo z „kluczami obcymi”. Na przykład nie użyłbym post_author w wp_posts tabela, ale zostanę przy users_id . Poza tym muszę zgodzić się, że baza danych WordPress jest naprawdę świetnym modelem do swoich celów.
Co myślisz? Daj nam znać w sekcji komentarzy.
