Jestem fanem krótkich cykli wydawniczych. W zależności od projektu długość cyklu będzie się różnić, ale w przypadku wielu typów projektów, nad którymi pracuję, staram się mieć dwutygodniowe cykle wydawnicze.
Co więcej, są chwile, w których pracuję nad projektem dla kogoś, w którym zmienne środowiskowe są niezbędne, aby kod wiedział, czy działa w fazie rozwoju, postoju czy produkcji.
I można to osiągnąć w różny sposób w zależności od potrzeb projektu. Czasami plik konfiguracyjny będzie działał, czasami zmienne ciągu zapytania mogą działać, a innym razem myślę, że rozsądne jest przechowywanie ustawienia w bazie danych.
Ale jeśli chodzi o WordPress, myślę, że skracamy lepsze decyzje projektowe i umieszczamy informacje w bazie danych, szczególnie w tabeli opcji, kiedy alternatywy mogą być lepiej dopasowane.
Tabela opcji WordPress
Chcę powiedzieć jasno: nie sądzę, że tabela opcji powinna służyć jako wysypisko dla ustawień, gdy nie masz gdzie umieścić informacji. I to jest sedno tego całego postu.
Zamiast tego możesz użyć:
- plik konfiguracyjny,
- dane sesji (jeśli dotyczy),
- niestandardowa tabela bazy danych,
- albo coś innego.
Dlaczego więc widzimy to tak często? Nie chodzi o to, że nie ma czasu, w którym warto z niego korzystać. Po prostu myślę, że go nadużywamy. Ale są powody.
Kodeks WordPress definiuje opcje takie jak:
Opcje to fragmenty danych, których WordPress używa do przechowywania różnych preferencji i ustawień konfiguracyjnych.
Z taką definicją łatwo zrozumieć, dlaczego tak wielu używa jej jako miejsca do przechowywania wszystkiego, co nie pasuje nigdzie indziej.
Zamiast tego myślę, że ważne jest, aby zadać pytanie:
Do jakiego rodzaju przechowywania [te dane] są najbardziej odpowiednie?
Oznacza to, że jeśli jest powiązany z postami, dlaczego nie przechowywać go w metatabeli postu? To samo dotyczy metadanych terminów, komentarzy lub czegokolwiek innego.
Chodzi o to:
Znajdź najbardziej logiczne miejsce do przechowywania danych i umieść je tam.
Innymi słowy, nie wrzucaj danych do tabeli opcji WordPress, ponieważ nie mieszczą się one nigdzie indziej. To go zanieczyszcza. Zamiast tego znajdź – lub stwórz – dla niego najbardziej logiczne miejsce. Jest to prawdopodobnie dowód na zapach kodu i byłby dobrym powodem do ponownej oceny architektury kodu i sposobu reprezentowania informacji.
Ale jak to może wyglądać? To znaczy, jak wzięlibyśmy dany fragment kodu i zmienili jego reprezentację w bazie danych.
Niestety, trudno jest podać nakazowe rozwiązanie tego pytania, gdy istnieje tak wiele wariantów realizacji problemu. Może więc potrzebna jest prosta wskazówka:
Jeśli dane są powiązane z istniejącymi wcześniej typami danych (lub tabelami), użyj ich; w przeciwnym razie rozważ plik konfiguracyjny lub niestandardową tabelę bazy danych, która jest mapowana na twoją pracę.
Jestem pewien, że istnieją inne czynniki przewodnie, ale jest to lepsze miejsce na rozpoczęcie niż zwykłe zanieczyszczanie tabeli opcji WordPressa.