Tworzenie niestandardowych tabel bazy danych dla wtyczek WordPress

W większości przypadków wtyczki modyfikują opcje, metadane lub wykorzystują już istniejące tabele (najczęściej tabelę postów), aby stworzyć nową funkcjonalność.

Niestandardowe typy postów, niestandardowe taksonomie, manipulacja obrazami, galerie, krótkie kody-żadne z nich zwykle nie potrzebują własnej tabeli bazy danych.

To dlatego, że schemat bazy danych WordPress (jak baza danych jest zorganizowana) nadaje się dobrze do rozwoju. Tabelę posts można wykorzystać do przechowywania obiektów, a tabelę postmeta do przechowywania dodatkowych informacji o tych obiektach. W niektórych sytuacjach staje się to jednak uciążliwe i/lub marnotrawne.

W dzisiejszym poście przyjrzymy się zaletom i wadom nowych tabel bazy danych, jak określić ich strukturę i jak je utworzyć w WordPress.

Rozważania dotyczące niestandardowych tabel?

To, czy powinieneś używać niestandardowej tabeli dla swojej wtyczki, sprowadza się do dwóch czynników: struktury i ilości danych. Twierdzę, że potrzebujesz tylko niestandardowej tabeli, jeśli struktura danych radykalnie różni się od standardowego modelu post oraz masz ich duże ilości.

Aby udowodnić mój punkt zacznijmy myśleć o wtyczce, która używa Google analytics do tworzenia i przechowywania raportów tygodniowych, które składają się z wielu punktów danych. Można do tego podejść na trzy sposoby:

Niestandardowy Stół

Możemy stworzyć prostą tabelę niestandardową, która przechowuje tygodniową analizę w jednej linii. Wiersz w bazie danych zawierałby identyfikator, datę analizy, liczbę przeczytanych postów, kliknięte linki, który kraj przyciągnął najwięcej odwiedzających i tak dalej.

Poczta i Postmeta

Możemy utworzyć niestandardowy typ postu “analytics” i użyć go do przechowywania identyfikatora i daty analizy. Następnie możemy użyć post meta do przechowywania poszczególnych punktów danych.

Prosta Tablica

Zamiast używać postów lub niestandardowej tabeli, możemy po prostu użyć jednej opcji w tabeli opcji. Byłaby to tablica, której członkami byłyby poszczególne tygodniowe numery.

Ponieważ zbieramy dane co tydzień, to naprawdę nie jest duży zbiór danych. Oczywiście wygodnie byłoby mieć tabelę, która dokładnie pasuje do naszych potrzeb, ale ponieważ nie mamy, czy warto zanieczyszczać naszą ładną bazę danych WordPress tabelą, która będzie używana tylko raz w tygodniu? Powiedziałbym, że nie, zwłaszcza, że nasze dane dobrze wpisują się w podejście klucz-wartość tabel postmeta.

Wybór pomiędzy tabelą posts a tablicą simple nie jest taki prosty. Jeśli nasz przykład przechowuje tylko Dane historyczne o wartości rocznej, tablica może być całkowicie poprawnym podejściem. Na początku będzie ona zawierać 52 członków, którymi można łatwo manipulować.

Jeśli gromadzenie danych będzie trwało i trwało, rozważyłbym podejście post i postmeta, po prostu dlatego, że nie chcemy ładować i manipulować tablicą 260 po piątym roku.

“W realnym świecie linie są czasami rozmyte, nie jest tak łatwo zdecydować, którą ścieżkę wybrać.”

Teraz, zmieńmy tylko jeden parametr przykładu i zobaczmy, czy coś się zmieni. Zbierajmy dane co minutę, a nie co tydzień. W ciągu roku jest 525 948 minut, co oznacza, że jeśli użyjemy prostej tablicy, pod koniec pierwszego roku liczba ta zwiększy się do ponad pół miliona członków. Oczywiście nie jest to efektywne wykorzystanie naszej bazy danych, ponieważ kompu zajęłoby wiekicokolwiek.

Rozwiązanie post i postmeta wpadłoby na ten sam problem. Podczas gdy WordPress jest zoptymalizowany, przy takich liczbach, jeśli popełnisz najmniejszy błąd optymalizacji, Twoja strona może się zatrzymać, nie wspominając o tym, jak wyszukiwania Użytkowników mogą cierpieć z powodu problemów z prędkością na Twoim blogu (ponieważ posty i wszystkie analizy będą przechowywane w tej samej tabeli). Należy pamiętać, że tabela postmeta prawdopodobnie zawiera 10 + punktów danych dla każdej analizy, więc tabela meta otrzyma 5,259,480 wierszy rocznie.

Jest to sytuacja, w której odpowiednia może być tabela niestandardowa. Chociaż ta tabela byłaby również wypełniona pół milionem wierszy rocznie, byłaby oddzielona od innych treści. Ponieważ punkty danych mogą być dodawane jako kolumny (lub mogą korzystać z dedykowanej tabeli meta), możesz wykonywać operacje znacznie szybciej.

W prawdziwym świecie linie są czasami zamazane, nie jest tak łatwo zdecydować, którą ścieżkę wybrać. Aby ci pomóc, oto kilka bardziej zwięzłych zalet i wad tworzenia niestandardowych tabel:

Zawodowcy

  • Schematy można dokładnie dopasować do struktury danych
  • Nie musisz używać dwóch tabel bazy danych do przechowywania danych
  • Masz kontrolę nad typami pól i limitami
  • Twoje dane są dobrze oddzielone od innych aspektów WordPress
  • Eksportowanie danych może być w niektórych przypadkach łatwiejsze
  • Twoja aplikacja może lepiej skalować
  • W przeciwnym razie złożone zapytania mogą być prostsze
  • Twoje dane mogą być o wiele jaśniejsze

Wady

  • Możesz zaśmiecać bazę danych WordPress
  • Manipulowanie danymi z tabeli jest trudniejsze
  • Będziesz musiał stworzyć własny interfejs użytkownika
  • Możesz być bardziej podatny na błędy i ataki SQL
  • Nie będziesz miał dostępu do Nr serii funkcji
  • Musisz utrzymywać swoją bazę danych, być może w wielu wersjach
  • Musisz zrobić więcej na temat aktywacji, dezaktywacji i deinstalacji wtyczek

Mając to na uwadze, mam nadzieję, że możesz zdecydować, czy Niestandardowy stół jest tym, czego potrzebujesz. Jeśli tak, czytaj dalej, pokażę Ci, jak stworzyć taki sposób WordPress.

Tworzenie Tabeli Bazy Danych

Tabele bazy danych powinny być tworzone po aktywacji. Można to zrobić za pomocą wtyczki i funkcji do hooków aktywacyjnych za pomocą następującej metody:

Ta funkcja zostanie uruchomiona, gdy wtyczka jest aktywowana przez użytkownika. Jeśli chcesz dowiedzieć się więcej na ten temat, zapoznaj się z naszym samouczkiem na temat aktywacji, dezaktywacji i deinstalacji wtyczek WordPress.

Użyjemy funkcji, którą właśnie podłączyliśmy, aby dodać naszą tabelę bazy danych za pomocą funkcji dbDelta (). Aby skorzystać z tej funkcji będziemy potrzebować nazwy bazy danych (która używa prefiksu tabeli WordPress), sortowania bazy danych i zapytania SQL. Poniższy przykład pokazuje, jak powstaje baza danych, czerpiąc inspirację z naszej wtyczki do analizy strony internetowej:

Początkowo pobieramy nasze zestawienie z tego ustawionego w pliku konfiguracyjnym WordPress-jest ono przechowywane w zmiennej $wpdb – i stamtąd pobieramy prefiks. Używamy prefiksu do utworzenia ostatecznej nazwy bazy danych. Korzystając z jakiegoś SQL sformatowanego zgodnie z określonymi regułami tworzymy tabelę bazy danych. Następnie dołączamy plik, który zawiera funkcję dbDelta (), a następnie uruchamiamy go, który utworzy naszą bazę danych.

Formatowanie naszego zapytania SQL

Istnieje wiele reguł, których musimy przestrzegać podczas formatowania naszego zapytania SQL. Są to następujące, zaczerpnięte z artykułu Kodeksu.

  • Musisz umieścić każdy field na własnej linii w instrukcji SQL.
  • Musisz mieć dwie spacje między słowami klucz podstawowy a definicją klucza podstawowego.
  • Musisz użyć słowa kluczowego klucz zamiast jego synonimu indeks i musisz podać co najmniej jeden klucz.
  • Nie wolno używać żadnych apostrofów ani backticks wokół nazw pól.
  • Wszystkie typy pól muszą być małymi literami.
  • Słowa kluczowe SQL, takie jak CREATE TABLE i UPDATE, muszą być pisane wielkimi literami.

Są one narzucane przez funkcję dbDelta (), nie oczywiście przez sam SQL. Ta funkcja musi obliczyć różnice między schematami baz danych w celu wydajnego i bezpiecznego aktualizowania tabel w razie potrzeby. Jako taki, SQL musi być sformatowany w taki sposób, aby funkcja mogła go łatwo “przetrawić”.

Aktualizacja Tabel Bazy Danych

Z biegiem czasu może być konieczne dodanie dodatkowych funkcji do wtyczki. Dodałem tylko widoki i kliknięcia powyżej, co powiesz na dodanie średniego czasu wyświetlania strony w minutach? To wymagałoby nowej kolumny i właśnie tutaj przydaje się dbDelta ().

Zanim cokolwiek zrobimy, powinniśmy upewnić się, że dodaliśmy nasz numer wersji do naszej wtyczki. Pomoże nam to określić, kiedy konieczne są zmiany w bazie danych.

Załóżmy, że przez 1.x wersje nic się nie zmieniło w schemacie bazy danych. W wersji 2.0 dodajemy kolumnę. Oto jak to może działać:

Dodałem jedną kolumnę, blog_id, który pomoże nam sprawić, że ta wtyczka będzie działać dla instalacji wielostanowiskowych. Jak widać wykryłem, czy obecnie używana wersja bazy danych jest niższa niż wersja wtyczki. Jeśli tak, używamy tego samego formatu, aby po prostu dodać kolumnę. Funkcja dbDelta() zajmuje się wszystkimi zmianami za nas, musimy tylko dostarczyć jej odpowiedni schemat bazy danych.

Wniosek

Tworzenie własnych tabel zwykle nie jest wymagane. Gdy jednak tak jest, funkcja dbDelta pozwala nam tworzyć modułowe, elastyczne i łatwe do utrzymania tabele.

Jeśli kiedykolwiek znajdziesz się w potrzebie tabeli, zawsze powinieneś uważać, aby użyć tego podejścia, ponieważ jest to jedyny sposób na wykonanie niestandardowych tabel w sposób przyjazny dla WordPressa.

Jeśli znasz wtyczkę, która dodaje własne tabele bazy danych, daj nam znać w komentarzach poniżej, a być może możemy to sprawdzić, aby sprawdzić, czy robi to poprawnie!

Tagi: