Lista wartości: Stałe kodowe lub baza danych?

Question

Chciałem wiedzieć, czy istnieje dobra praktyka w zakresie zarządzania wartościami. Na przykład mam logi tabeli bazy danych w następujący sposób:

 
--------------- 
| logs  | 
|-------------| 
| id   | 
| idLogType | 
| message  | 
| date  | 
--------------- 

Moje pytanie jest o polu „idLogType”. Wiem, że wyliczenie nie jest dobrym sposobem na obsługę tego rodzaju pola, ponieważ jeśli chcę dodać nowe wartości, muszę ZMIENIĆ tabelę. Więc zamierzam stworzyć listę wartości.

Jakie jest Twoje zalecenie dotyczące obsługi listy wartości?

1. Tylko ze stałymi PHP?

class LogTypeValues { 
    const LOGTYPE_CREATION = 1; 
    const LOGTYPE_EDITION = 2; 
    const LOGTYPE_DELETION = 3; 

    private $_logTypes = array(); 

    public function __construct() { 
    $this->_logTypes[self::LOGTYPE_CREATION] = "Creation"; 
    $this->_logTypes[self::LOGTYPE_EDITION] = "Edition"; 
    $this->_logTypes[self::LOGTYPE_DELETION] = "Deletion"; 
    } 

    public function getId($logType) { ... } 
    public function getLogType($id) { ... } 
} 

$request = $pdo->prepare('INSERT INTO logs SET idLogType = :idLogType, ...'); 
$request->execute(array('idLogType' => LogTypeValues::LOGTYPE_CREATION)); 

2. Tylko z bazą danych?

 
------------ 
| logTypes | 
------------ 
| id  | 
| logType | 
------------ 

<?php 
$request = $pdo->prepare('INSERT INTO logs SET idLogType = 1, ...'); 
$request->execute(array()); 

3. W bazie danych, ale także ze stałych PHP?

 
------------ 
| logTypes | 
------------ 
| id  | 
| logType | 
------------ 

class LogTypeValues { 
    const LOGTYPE_CREATION = 1; 
    const LOGTYPE_EDITION = 2; 
    const LOGTYPE_DELETION = 3; 
} 

Co prawda o tych 3 metod?

Answer 1

Moim ulubionym rozwiązaniem byłoby:

Stores typy logowania w bazie:

CREATE TABLE logTypes (
    id (SMALLINT, PK) 
    code VARCHAR(32) UNIQUE  
) 

Tworzenie stałe w kodzie

class logTypes { 
    const CREATE_USER = 1; 
    const EDIT_USER = 2; 
    ... 
} 

i wybrać synchronizacji polityki:

• Utwórz klasę logTypes f rom DB => kod to "pamięć podręczna db", jeśli pamięć podręczna nie jest generowana projekt nie będzie działał
• Utwórz DB z kodu => DB jest przydatna tylko dla raportów sql i stosowania funkcji SQL do logtypes wyszukiwania, itp ...

Przykład:

SELECT * FROM logs JOIN logTypes USING logtype_id WHERE logType LIKE "% CREATION" 

Answer 2

Więcej czy mniej niestrukturalnych myśli:

• Nie należy używać magicznych liczb, ani w kodzie ani bazy danych. W związku z tym należy unikać typów logów "1", "2" itp.
• Powinieneś używać stałych w swoim kodzie PHP, a ja dawałbym te stałe znaczące wartości ciągów, a nie wartości numeryczne.
• Te wartości ciągów mogą być bezpośrednio używane w bazie danych jako logType.
• Używanie kolumny dla kolumny logType ma zatem sens. Jeśli chcesz dodać typy dzienników, musisz zmienić tabelę ... i co z tego? To nie jest coś, co powinno się zdarzać bardzo często, musisz mimo to zmodyfikować swój kod, aby dodać nową stałą, a mimo to powinieneś mieć kod migracji schematu, który sprawia, że ​​dodanie nowej wartości wyliczenia SQL również jest banalne.

Tak, to wydaje się najlepszym rozwiązaniem dla mnie jest:

• stałych jak LogTypeValues::CREATION = 'creation'
• logType kolumny typu ENUM('creation', ...)
• migracje schematu obsłużyć dodawanie typów dziennika

Answer 3

To jest świetne pytanie - rozsądni ludzie będą mieli różne opinie, w zależności od twojego d Efincja "dobra".

Opcja 1 sprawia, że ​​PHP działa ładnie, ale oznacza, że ​​gdy chcesz wysłać zapytanie do dziennika, musisz mieć stałe w dwóch miejscach - zazwyczaj przeglądarka dziennika nie jest tą samą aplikacją, co program zapisujący dzienniki. I musisz napisać jakąś niestandardową logikę, by przetłumaczyć twoje liczby całkowite w bazie danych na ciągi czytelne dla człowieka.Jeśli masz więcej niż jedną aplikację do zapisania w bazie danych dziennika, utrzymanie stałych w synchronizacji między nimi staje się ważne - jeśli aplikacja 1 myśli LogType 1 = "Błąd użytkownika" i aplikacja 2 myśli, że jest to "błąd systemowy", to wszystko się rozpada .

Opcja 2 napotyka na przeciwny problem - w jaki sposób twój kod PHP "wie", że baza danych uważa, że ​​LogType 1 to "błąd użytkownika"? Na pewno nie chcesz mieć magicznych liczb w kodzie PHP.

Opcja 3 zakłada, że ​​oba systemy są zsynchronizowane - ale teraz musisz znaleźć sposób synchronizacji bazy danych ze swoim plikiem PHP. Istnieje wiele logicznych sposobów, aby to zrobić - ale żadne nie są trywialne.

Ponieważ jestem leniwy i paranoikiem na temat błędów wkradających się, zwykle nie używam do tego liczb całkowitych - zamiast tego, kod PHP zapisuje ciąg znaków reprezentujący typ dziennika do bazy danych, z pliku stałych.

Answer 4

ja też w obliczu podobnej sytuacji kilka razy. Oczywiście, są plusy i minusy wszystkich wymienionych wyżej opcji, ale też nie myślałem. Właśnie dlatego znalazłem ten wątek.

Do tej pory moim preferowanym sposobem jest użycie opcji 1, tj. Przechowywanie stałych tylko w kodzie źródłowym aplikacji (PHP/Java itp.). Jego główną zaletą jest ograniczenie niepotrzebnych trafień bazy danych. Chociaż niektórzy z was mogą powiedzieć, że jest bardzo mały, ale połączenie DB jest często wąskim gardłem wielu aplikacji internetowych. Inną zaletą jest to, że zmniejszyło to złożoność programowania.

Jedyną rzeczą, którą zrobiłem oprócz tego, co zostało wspomniane w tym wątku, jest dodanie uwagi do komentarzy zarówno w kodzie źródłowym aplikacji, jak i pokrewnych kolumnach tabeli DB, aby się wzajemnie odwoływały. W ten sposób starałem się jak najlepiej przypomnieć przyszłym programistom o synchronizacji tych dwóch miejsc, jeśli zaistnieją jakiekolwiek zmiany.