nomi dei campi booleani positivi o negativi

campi booleani di una tabella possono essere denominati utilizzando il positivo contro il negativo ...nomi dei campi booleani positivi o negativi

ad esempio, chiamare un campo:

"ACTIVE" , 1=on/0=off 
or 
"INACTIVE" , 0=on/1=off

Domanda: Esiste un modo corretto per prendere questo tipo di decisione sul design della tabella o è arbitrario?

Il mio esempio specifico è una tabella di messaggi con un campo bool (privato/pubblico). Questo campo verrà impostato utilizzando una casella di controllo modulo quando un utente inserisce un nuovo messaggio. C'è un vantaggio nel nominare il campo "pubblico" vs "privato"?

grazie.

fonte

2009-09-18 cardflopper

È consigliabile creare un'altra tabella e implementare una relazione di chiave esterna. Vedere la risposta per ulteriori dettagli. –

Preferisco sempre i nomi positivi, per evitare doppi negativi nel codice. "Non è inattivo" è spesso causa di una doppia presa durante la lettura. "È inattivo" può sempre essere scritto come "se (! Attivo)" mentre si avvantaggia della semantica linguistica incorporata.

fonte

2009-09-18 17:22:28

La mia preferenza personale:

Utilizzare i prefissi come "è", "ha", ecc per i campi booleani per rendere il loro scopo chiaro.
Nominare sempre variabili nello affermativo. Per Active/Inactive, lo chiamerei IsActive.
Non rendere nulla campo un valore nullo a meno che non si abbia davvero uno scopo specifico nel farlo.

Nel tuo caso specifico utilizzo, il campo deve essere denominato sia IsPublic o IsPrivate - a seconda di quale nome si tradurrebbe in una risposta vera quando l'utente zecche la casella di controllo.

fonte

2009-09-18 17:24:04 richardtallent

+1 per "checkbox true" che equivale al "vero database" –

... e per quanto riguarda i negativi incorporati del design come "Linea di blocco"? Il dispositivo è inattivo se la linea di blocco è alta. isLockedOut significa praticamente isDeviceInactive. Ma quando provo la linea di blocco, sono interessato a isLockoutActive ... oppure, isWorkingCorrectly o isInFaultMode? –

SF, non sono sicuro di seguire la tua logica qui, ma penso che potresti aver superato lo scopo di un valore booleano e potrebbe essere necessario un campo Stato, con un elenco di possibili valori di stato. La risposta di OMG Ponies è quella giusta in quel caso. – richardtallent

Utilizzare sempre nomi positivi.

Se si utilizzano nomi negativi, si passa rapidamente alla doppia negazione. Non quella doppia negazione è la chirurgia a razzo, ma è un ciclo cerebrale e quelli sono preziosi :)

fonte

2009-09-18 17:29:00 Stefan

Utilizzare sempre positivo.

È più semplice.

Prendere la negazione all'estremo logico: se InActive è migliore di Active, allora perché non InInActive o InInInActive?

Perché sarebbe meno semplice.

fonte

2009-09-18 17:33:21

Il modo corretto per gestire queste situazioni è creare una tabella per ospitare i valori associati alla colonna e creare una relazione di chiave esterna tra le due tabelle.IE:

WIDGETS tabella:

WIDGET_ID
WIDGET_STATUS (fk)

WIDGET_STATUS_CODES tabella:

WIDGET_STATUS_CODE (PK)
DESCRIPTION

Se possibile, WIDGET_STATUS_CODE sarebbe una chiave naturale (IE: ACT per "Attiva", INA per "inattivo"). Ciò renderebbe i record più leggibili dall'uomo, ma non è sempre possibile in modo da utilizzare una chiave artificiale/surrogata (come un numero automatico/sequenza/ecc.).

si vuole fare questo perché:

E 'leggibile quello stato indica (che era la domanda iniziale)
prova di futuro nella necessità di definire/usare più stati
Fornisce integrità referenziale così qualcuno non ha potuto impostare il valore su 2, 3, 4, ecc.
Lo spazio è economico; non c'è nulla efficiente di permettere dati errati

fonte

2009-09-18 17:33:42

Questo è FAR meno efficiente di un campo bit semplice. Qual è la giustificazione per fare questo rispetto ad un semplice campo di bit per una semplice risposta booleana? – richardtallent

(a) La leggibilità umana delle tabelle non è, IMHO, un obiettivo di buona progettazione del database. Altrimenti, non useremmo mai le chiavi surrogate e i nostri database passerebbero la vita intera a fare confronti con le stringhe. – richardtallent

(b) Sono d'accordo in linea di principio w/r/t a prova di futuro per più valori, ma SOLO se c'è uno stato possibile che NON è delle scelte esistenti. Denominazione di un campo qualcosa di generico come "Stato" quando si ha davvero a che fare solo con la modalità * Attivo/Inattivo * invita l'abuso futuro shoehorning attributi ortogonali. Alla fine, questo costringe la progettazione verso una m: n rapporto che assomiglia ad una nuvola di tag loosely-digitato. Non sono contrario ai tag cloud in generale, ma interrompono la normalizzazione e questo ha conseguenze sul design. – richardtallent

io non sarei d'accordo con alcune delle altre risposte, ma sicuramente evitare la risposta sbagliata, che non è quello di mettere in doppie negazioni sempre

fonte

2009-09-18 17:54:59 leora

-1

cercare di evitare i campi booleani in database tutto sommato.

Uno, l'RM ha un modo molto migliore di rappresentare informazioni basate sulla verità che tramite campi booleani: tramite la presenza di una tupla in una tabella.

Due campi booleani sono discriminatori molto cattivi durante l'esecuzione di query. È praticamente una follia completa indicizzarli, quindi quando si esegue una query, la presenza di campi booleani non offre alcun vantaggio.

fonte

2009-09-18 20:49:40

I valori booleani possono essere poveri discriminatori, ma ciò dipende * interamente * dalla distribuzione di valori 0 e 1. Come ogni indice, l'indicizzazione di un campo di bit aggiunge un elemento di tabella di ricerca indirezione se non è la colonna del primo ordine in un indice cluster (che non sto raccomandando), ma l'indicizzazione * non * evitare una scansione di tabella, in modo da ci * è * un vantaggio in termini di prestazioni. Nel frattempo, l'utilizzo di un FK su un'altra tabella con un singolo valore ha esattamente la limitazione delle prestazioni come campo di bit indicizzato, e per lo stesso motivo, ma i join aggiungono un overhead aggiuntivo sostanziale rispetto a una ricerca di indice bit. – richardtallent

nomi dei campi booleani positivi o negativi

risposta

Problemi correlati