2014-06-20 10 views
11

Volevo sapere se esisteva una buona pratica per la gestione dell'elenco dei valori. Per esempio ho un registri della tabella di database come segue:Elenco dei valori: costanti di codice o database?

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

La mia domanda riguarda il campo "idLogType". So che un enum non è il modo migliore per gestire questo tipo di campo, perché se voglio aggiungere nuovi valori devo ALTERARE il tavolo. Quindi creerò un elenco di valori.

Qual è la vostra raccomandazione per gestire l'elenco dei valori?

1. Solo con costanti 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. Solo con database?

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

3. Nella banca dati, ma anche con le costanti PHP?

 
------------ 
| logTypes | 
------------ 
| id  | 
| logType | 
------------ 
class LogTypeValues { 
    const LOGTYPE_CREATION = 1; 
    const LOGTYPE_EDITION = 2; 
    const LOGTYPE_DELETION = 3; 
} 

Cosa ti cosa su questi 3 metodi?

risposta

4

La mia soluzione preferita sarebbe:

Negozi log tipi di database:

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

Crea costanti nel codice

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

e scegliere una politica di sincronizzazione:

  • Crea la classe logTypes f rom => il codice è una "cache del db", se la cache non viene generata il progetto non funzionerà
  • Crea il DB dal codice => Il DB è utile solo per i rapporti SQL e l'applicazione di funzioni SQL per logtypes di ricerca, ecc ...

Esempio:

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

più o meno pensieri non strutturati:

  • Non si deve usare numeri magici, né nel codice né database. Di conseguenza, è necessario evitare i tipi di registro "1", "2", ecc.
  • Dovresti usare le costanti nel tuo codice PHP, e darei a queste costanti valori di stringa significativi, non valori numerici.
  • Questi valori di stringa possono essere utilizzati direttamente come logType nel database.
  • L'utilizzo di un ENUM per la colonna logType ha quindi perfettamente senso. Se si desidera aggiungere tipi di registro, è necessario modificare la tabella ... quindi cosa? Non è qualcosa che dovrebbe accadere molto spesso, devi comunque modificare il tuo codice per aggiungere una nuova costante, e dovresti avere comunque un codice di migrazione dello schema che rende banale l'aggiunta di un nuovo valore enum SQL.

Quindi, questa sembra la soluzione migliore per me:

  • costanti come LogTypeValues::CREATION = 'creation'
  • logType colonna di tipo ENUM('creation', ...)
  • schema migrazioni per gestire l'aggiunta di tipi di registro
+0

Grazie per la risposta, ma attenzione, una tabella contenente i log potrebbe essere una delle più grandi tabelle del database e la memorizzazione di un varchar (1 byte + 1 byte/char) invece di tinyint (solo 1 byte) può essere un problema –

2

Questa è una grande domanda - e le persone ragionevoli avranno opinioni diverse, a seconda del tuo d definizione di "bene".

L'opzione 1 fa funzionare correttamente il PHP, ma significa che quando si vuole interrogare il log, è necessario avere le costanti in due punti: in genere, il log viewer non è la stessa applicazione del log writer. E devi scrivere qualche logica personalizzata per tradurre i tuoi numeri interi nel database in stringhe leggibili dall'uomo.Se hai più di un'applicazione che scrive nel database di log, mantenere le costanti sincronizzate tra di esse diventa importante - se l'applicazione 1 pensa a logType 1 = "Errore utente" e l'applicazione 2 pensa che sia "errore di sistema", l'intera faccenda cade a pezzi .

L'opzione 2 affronta il problema opposto: in che modo il codice PHP "sa" che il database ritiene che logType 1 sia "errore utente"? Sicuramente non vuoi avere numeri magici nella base di codice PHP.

L'opzione 3 mantiene in modo sincronizzato entrambi i sistemi, ma ora è necessario trovare un modo per sincronizzare il database con il file di costanti PHP. Ci sono una varietà di percorsi logici per farlo - ma nessuno è banale.

Dato che sono pigro e paranoico sui bug che si insinuano, di solito non uso interi per questo - invece, il codice PHP scrive una stringa che rappresenta il tipo di registro nel database, da un file di costanti.

1

ho anche affrontato le situazioni simili un paio di volte. Ovviamente, ci sono pro e contro di tutte quelle opzioni sopra menzionate, e non ho nemmeno pensato. Ecco perché ho trovato questo thread.

Finora il mio metodo preferito è l'uso dell'opzione 1, ovvero la sola memorizzazione di costanti nel codice sorgente dell'applicazione (PHP/Java ecc.). Il suo principale vantaggio è di ridurre gli accessi al DB non necessari. Anche se alcuni di voi potrebbero dire che è molto piccolo, ma la connessione DB è spesso il collo di bottiglia di molte applicazioni web. L'altro vantaggio è che ha ridotto la complessità della programmazione.

L'unica cosa che ho fatto in aggiunta a ciò che è stato menzionato in questa discussione è di aggiungere una nota ai commenti sia nel codice sorgente dell'applicazione che nelle relative colonne della tabella DB per incrociarsi tra loro. In questo modo, ho fatto del mio meglio per ricordare ai futuri sviluppatori di sincronizzare questi due posti se dovessero verificarsi dei cambiamenti.

Problemi correlati