Best practice per le tabelle di ricerca nell'applicazione - per ID o valore

1

Ho un'applicazione di database complessa. Esistono molte tabelle di ricerca contenenti alcuni valori, in particolare una contiene pass / fail / waiting / unknown.

Nell'applicazione trovo che molte delle query dipendono dallo stato pass / fail di un modello. Quindi voglio mostrare tutto con un passaggio. O tutto ciò che non è un fallimento.

Sto usando Django (anche se sono certo che la domanda è pertinente al di fuori di Django).

Quindi quando sto interrogando tramite l'ORM, posso unirmi alla tabella extra e dire ad esempio.

Model.objects.filter(passfail__status='pass')

In alternativa, posso usare l'ID.

Model.objects.filter(passfail_id=1)

Il primo esempio si unirà alla tabella dei passaggi e alla query in base al campo "stato": il testo effettivo "pass" / "fail" / "waiting" text.

L'una o l'altra è considerata pratica buona / cattiva?

L'utilizzo dell'ID dovrebbe essere leggermente migliore, in quanto vi è un join in meno. E eviterà il problema dello stato dei passfail che cambia (non dovrebbe, ma non so mai cosa faranno gli utenti).

L'uso del campo di stato dovrebbe rendere il codice più leggibile e più ovvio di ciò che stiamo cercando di ottenere. Anche se non mi aspetto che la tabella dei passaggi di sicurezza cambi.

    
posta wobbily_col 11.02.2015 - 12:33
fonte

1 risposta

4

Utilizza enum . Un buon framework ORM può facilmente gestire la mappatura delle enumerazioni con gli ID. Allora ne traggono due vantaggi:

  1. Uso semplice nel codice e logica aziendale chiara : gestisci (confronta ecc.) nomi descrittivi, quindi la logica aziendale è chiara.
  2. Efficienza delle prestazioni : nessun join per nomi descrittivi nelle query db (ORM funzionerà solo su ID)

Se non puoi, puoi eseguire il fallback su costanti denominate solo per rendere chiaro il tuo codice. Sfortunatamente non trarrai alcun vantaggio in ORM.

    
risposta data 11.02.2015 - 13:54
fonte

Leggi altre domande sui tag