Czy złą praktyką jest tworzenie własnych tabel dla wtyczek?


11

Jeśli chcę zapisać ustawienia mojej wtyczki, jest to dość łatwe i proste.

Teraz chciałbym jeszcze trochę zapisać w bazie danych.

Nazwa pliku i 3 inne wartości, które dotyczą tylko tego pliku. I istnieje wiele plików z tymi wartościami. Czy możliwe jest zapisanie pewnego rodzaju podrzędnych przy użyciu wbudowanych metod baz danych? Jak mogę je usunąć i posortować itp?

Odpowiedzi:


13

Rzadko nie zgadzam się z użytkownikami posiadającymi wiedzę, ale w tym przypadku nie mogę nic na to poradzić. Moim zdaniem nazywanie korzystania z nie-podstawowych tabel bazy danych złą praktyką per se jest po prostu błędne.

Wybór, czy przejść z tabelami podstawowymi, czy dodać własne, zależy od kilku czynników.

Czas wykonania zapytania zależy od wielkości tabeli. Dlatego jeśli planujesz przechowywanie znacznych ilości danych, oddzielne tabele odpowiadające tylko temu rodzajowi określonego zestawu danych będą nieuchronnie bardziej wydajnym rozwiązaniem.

Jeśli przechowujesz wiele zwykłych postów lub CPT obok tych konkretnych zestawów danych, wp_postsa także wp_postmetamożesz szybko rosnąć.

Dla mnie ten wybór ostatecznie zależy od tego, jak „posty” to dane. Czy powinien wspierać autora, komentarze, poprawki, fragmenty itp.? Jeśli tak, skorzystam z CPT i / lub podstawowych funkcji. Jeśli nie, wybiorę osobne tabele ze względu na zużycie zasobów i wydajność.

Gdyby pojęcie Eugene'a było prawidłowe, żadna z dobrze napisanych wtyczek nie dodałaby własnych tabel, co na szczęście nie ma miejsca.


Nie mogę głosować za tym. „ To, z czym czujesz się najlepiej ”, nie jest absolutnie uzasadnione. Istnieją uzasadnione przypadki użycia oddzielnych tabel, ale w zdecydowanej większości wtyczek najlepsze praktyki wymagają użycia podstawowych tabel WP DB.
Chip Bennett

2
Fair enuff @ChipBennett - nie powinno to być częścią rozumowania, ani w ogóle „rozumowania”. Edytowane i usunięte (wciąż nie oczekuję pozytywnej opinii - przedstawiciel nie jest jedyną motywacją).
Johannes Pille

1
+1. Myślę, że to rozsądna, przemyślana odpowiedź. :)
Chip Bennett

5

Korzystanie z podstawowych tabel DB DB jest najlepszą praktyką

  1. Korzystanie z podstawowych tabel DB sprawia, że ​​dane są bardziej przenośne i łatwiejsze do tworzenia kopii zapasowych, ponieważ będą one obsługiwane przez głównego eksportera / importera, a także przez niezliczone wtyczki do tworzenia kopii zapasowych
  2. Korzystanie z podstawowych tabel DB sprawia, że ​​manipulowanie danymi jest łatwiejsze i bezpieczniejsze , ponieważ będziesz mieć bardziej intuicyjny dostęp do różnych podstawowych funkcji WordPress związanych z zapytaniami, dodawaniem, modyfikowaniem, usuwaniem i oczyszczaniem danych DB, szczególnie za pośrednictwem bardzo potężnej $wpdbklasy .
  3. Korzystanie z podstawowych tabel DB zachęca / ułatwia stosowanie najlepszych praktyk w zakresie klasyfikacji i przechowywania danych , takich jak przechowywanie opcji wtyczek jako tablicy w jednym rzędzie wp_options, i zmuszanie dewelopera wtyczek do uważnego rozważenia rodzaju tworzonych / przechowywanych danych - czy jest to CPT? czy to taksonomia? czy to jest post meta?
  4. Twoja wtyczka rzadziej zostawia za sobą cruft, gdy używasz podstawowych tabel DB.

WordPress umożliwia wtyczkom dodawanie tabel do bazy danych

Jednak w przypadkach, w których potrzebna jest osobna tabela DB, należy użyć metody przewidzianej przez WordPress w celu dodania niestandardowej tabeli do bazy danych WordPress , szczególnie abyś mógł skorzystać z potężnej $wpdbklasy. Zwróć uwagę na informacje / zastrzeżenia zawarte w tej liście Kodeksu:

  • Informacje o konfiguracji - wybory użytkownika, które są wprowadzane, gdy użytkownik po raz pierwszy konfiguruje wtyczkę, i nie wykraczają znacznie poza to (na przykład we wtyczce związanej z tagami wybory użytkownika dotyczące formatu chmury tagów w pasek boczny). Informacje o instalacji będą zazwyczaj przechowywane przy użyciu mechanizmu opcji WordPress.

  • Dane - informacje, które są dodawane, gdy użytkownik nadal korzysta z wtyczki, która jest ogólnie rozszerzoną informacją związaną z postami, kategoriami, przesyłaniem i innymi komponentami WordPress (na przykład we wtyczce związanej ze statystykami, różnych odsłonach stron, stron odsyłających oraz inne statystyki związane z każdym postem w Twojej witrynie). Dane mogą być przechowywane w osobnej tabeli MySQL, którą trzeba będzie utworzyć. Zanim jednak przejdziesz do nowej tabeli, zastanów się, czy przechowywanie danych wtyczki w WordPress 'Post Meta (inaczej Custom Fields) będzie działać. Post Meta jest preferowaną metodą; używaj go, gdy jest to możliwe / praktyczne.

Możemy zatem wyciągnąć następujące wnioski:

  1. Przechowywanie danych (ustawień lub wygenerowanych przez użytkowników) w podstawowych tabelach WP jest najlepszą praktyką
  2. Istnieją prawidłowe przypadki użycia do tworzenia niestandardowych tabel DB; dlatego tworzenie niestandardowych tabel DB nie może być uważane za nieodłączną złą praktykę
  3. Podczas tworzenia niestandardowych tabel DB WordPress zapewnia implementację najlepszych praktyk

Mogę to zagłosować. ;-) +1 za wyraźne wzmianki $wpdb(korzystanie z niego w przypadku tabel nie-rdzeniowych zostało zasugerowane w mojej odpowiedzi, nie chciałbym przegapić tej klasy)
Johannes Pille

2
Początkowo zakładałem, że „własne tabele DB” sugerują tabele poza bazą danych WP ; kiedy minąłem impas tego błędnego założenia, pytanie (i odpowiedzi / komentarze) stało się bardziej jasne. :)
Chip Bennett

1

Nie-podstawowe tabele bazy danych są koniecznością, jeśli Twoje dane są bardziej złożone niż model pocztowy WordPress, będzie ogromny i będzie zawierał wiele meta szczegółów, które będą przeszukiwane.

Format EAV, którego WordPress używa do tworzenia post meta, nie nadaje się dobrze do wyszukiwania według wielu kryteriów.

Jeśli podzielisz swoją metę na wiele wpisów, będziesz mieć wiele wpisów na post w tabeli meta postów, a wyszukiwanie dowolnego postu przez meta będzie znacznie wolniejsze.

Jeśli przechowujesz wszystkie meta zserializowane w tablicy i masz je tylko jako jeden wpis w meta post, tym razem będziesz zmuszony do wyszukiwania tylko tekstu wewnątrz tej meta i nie będziesz mógł używać operatorów porównania bezpośrednio w zapytaniu sql.

Nie jest to duży problem, jeśli Twoja wtyczka nie będzie miała tysięcy wpisów i powiązanych meta.

Ale poważny problem, jeśli Twoja wtyczka zrobi coś dużego.


Twoja sytuacja, nazwa pliku jako niezależny wpis i 3 wpisy metadanych dołączone do tego wpisu nie wydają się tak duże. Możesz do tego użyć tabeli postów i meta-tabel Wordpress.

ALE, jeśli ludzie będą często wyszukiwać te 3 meta, zwłaszcza w połączeniu, zalecam utworzenie osobnych tabel.

W tym formacie tylko jedna tabela z jednym wpisem, która zawiera również wszystkie metas, byłaby odpowiednia i szybko sprawdzałaby błyskawicę.

Nawiasem mówiąc, jeśli korzystasz z tabel WordPress, a także korzystasz z buforowania zapytań, użytkownik wyszukujący twoje dane zostanie z czasem zbuforowany i spowoduje mniejsze obciążenie. Ale nie byłoby to tak rozsądne, jak robienie oddzielnych tabel.


0

Możesz przesłać swoje pliki do biblioteki multimediów. Każdy element w bibliotece multimediów jest przechowywany w wp_poststabeli. Oznacza to, że każdy plik może zawierać metadane. Za wp_postmetapomocą interfejsu API metadanych możesz zapisać tyle informacji, ile potrzebujesz dla każdego pliku w tabeli .

Czy złą praktyką jest tworzenie własnych tabel dla wtyczek?

Tak, złą praktyką jest tworzenie własnych tabel, jeśli zamiast tego można użyć podstawowych funkcji.


3
Nie, to nie jest zła praktyka. Chyba że uważasz wolniejsze zapytania i ściśle powiązany kod za dobrą praktykę.
onetrickpony

0
class TMM {

    public static $options;

    public static function register() {
        self::$options = get_option(TMM_THEME_PREFIX . 'theme_options');
    }

    public static function get_option($option) {
        return @self::$options[$option];
    }

    public static function update_option($option, $data) {
        self::$options[$option] = $data;
        update_option($prefix . 'theme_options', self::$options);
    }

    //ajax
    public static function change_options() {

        $action_type = $_REQUEST['type'];
        $data = array();
        parse_str($_REQUEST['values'], $data);
        $data = self::db_quotes_shield($data);

        if (!empty($data)) {
            foreach ($data as $option => $newvalue) {
                if (is_array($newvalue)) {
                    self::update_option($option, $newvalue);
                } else {
                    $newvalue = stripcslashes($newvalue);
                    $newvalue = str_replace('\"', '"', $newvalue);
                    $newvalue = str_replace("\'", "'", $newvalue);
                    self::update_option($option, $newvalue);
                }
            }
        }
        _e('Options have been updated.', TMM_THEME_FOLDER_NAME);
        exit;
    }

    public static function db_quotes_shield($data) {
        if (is_array($data)) {
            foreach ($data as $key => $value) {
                if (is_array($value)) {
                    $data[$key] = self::db_quotes_shield($value);
                } else {
                    $value = stripslashes($value);
                    $value = str_replace('\"', '"', $value);
                    $value = str_replace("\'", "'", $value);
                    $data[$key] = $value;
                }
            }
        }

        return $data;
    }

}

  • Nazwa klasy jest oryginalna, zmień jej nazwę według własnego uznania.
  • W funkcjach php add: add_action ('init', array ('TMM', 'register'), 1);
  • I dodaj dla ajax: add_action ('wp_ajax_change_options', array ('TMM', 'change_options'));
  • Aby uzyskać opcję, w której potrzebujesz, użyj tego (na przykład): $ logo_img = TMM :: get_option ('logo_img');
  • Użyj go, aby zapisać opcje przy użyciu rodzimych metod wordpress
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.