Perché l'ID negativo o lo zero sono considerati una cattiva pratica?

Perché l'ID negativo o lo zero è considerato una cattiva pratica quando si inserisce una chiave primaria in una tabella di database?Perché l'ID negativo o lo zero sono considerati una cattiva pratica?

Penso che potrebbe essere utile in alcuni casi, ma la gente dice che non è raccomandato, nonostante il fatto che non dicono mai/sanno perché.

Quindi, mi chiedevo se c'è, per definizione, qualche restrizione o se non dovrebbe avere alcun problema o se è solo una convenzione e se davvero c'è qualche restrizione a riguardo, perché non è quella caratteristica bloccato?

fonte

2012-01-19 falsarella

Avete qualcosa per documentare questa "cattiva pratica"? Immagino che i numeri negativi siano più sgradevoli da leggere e leggermente più difficili da scrivere. Non riesco davvero a vedere alcun motivo tecnico per evitarli. In effetti è un ottimo modo per estendere la portata di un tipo di dati firmato. – Yuck

Sul lato, questo è utile quando si creano record sul lato client che in seguito devono essere inseriti sul server: http://msdn.microsoft.com/en-us/library/ms971502.aspx – Niklas

Immagino sia popolare che i numeri negativi sono "considerati" una "cattiva pratica", qualcosa di "brutto" da "evitare". Non è vero? Ma davvero non riesco a capire perché ... Quindi, @Yuck, pensi che sia dovuto alla leggibilità? – falsarella

Per essere chiari, questa domanda e risposta riguardano l'utilizzo di numeri negativi per chiavi surrogate, non per chiavi naturali.

Per quanto ne so, ci sono tre motivi per ritenerlo una cattiva pratica.

viola lo principle of least surprise.
Alcune persone assumono che tutti i numeri ID siano non negativi.
Alcune persone utilizzano numeri negativi per indicare errori.

Il primo ha una certa validità. Non vedi mai esempi SQL o risposte su SO che utilizzano numeri ID negativi. (Lo cambierò, a partire da oggi.)

Il secondo e il terzo sono corollari al primo, in quanto i programmatori spesso assumono comportamenti privi di sorprese. (Questo mi ricorda di scoprire che VBA mi permetterebbe di moltiplicare due date, restituendo un numero che sarebbe espresso, credo, in date quadrate.)

Per il numero 2, i programmatori di applicazioni potrebbero introdurre errori sottili non consentendo spazio per il codice UI di accesso, che potrebbe rendere -123456 come 123456.

Il terzo ha a che fare con la scrittura del codice che restituisce i numeri di identificazione. Il codice che restituisce un singolo numero ID potrebbe restituire -1 come codice di errore. Ma -1 è un numero ID valido nella maggior parte dei casi. (La maggior parte dei database non limita i numeri di identificazione all'intervallo di numeri interi non negativi.)

fonte

2012-01-21 19:14:04

Considerate questi motivi lo stesso per zero, o c'è qualcosa di diverso? – falsarella

Lo stesso per zero, penso. Alcuni posti usano 0 come una sorta di sostituto non nullo per NULL. –

Nessuna restrizione quindi, grazie! Il problema sarà il codice di implementazione. Ma ... Che ne dici di usare -1 per gli utenti admin o alcune costanti come questa? Come gestisci? – falsarella

La risposta di @Mike Sherrill 'Cat Recall' è IMHO errata.

Negativi: il motivo per cui non si utilizzano i negativi per gli ID è che i numeri negativi non sono portatili. La rappresentazione binaria di un valore decimale dipende dall'architettura numerica sottostante, e questo influenza il modo in cui un valore decimale negativo sarà presentato in formato non negativo, in streaming (ad esempio esadecimale, base36, ecc.). Allo stesso modo non si usano i valori in virgola mobile come identificatori, anche se all'interno dei vincoli di una singola architettura è teoricamente possibile.

Zero: Zero può fungere da ID. Non è consigliato perché spesso denota un campo vuoto/valore NULL.

fonte

2015-12-29 18:08:39 avnr

Bel punto. +1. Hai qualche fonte a riguardo? Mai pensato all'architettura di rappresentazione, ma avrebbe comunque un problema di portabilità per il resto dei tipi di campo, comunque ... Quindi, il principio di minima sorpresa sembra ancora una ragione più rilevante. – falsarella

Formalmente, un identificatore è un token (c'è una buona panoramica in https://en.wikipedia.org/wiki/Identifier), quindi un numero negativo può essere considerato un token solo se lo si considera come una sequenza di caratteri, che tipo di sfida alla sua natura come "negativo". Quindi nel contesto della tua domanda, dove l'ID è un * numero * e non una stringa, questo numero * non dovrebbe * servire da ID se negativo. Questa non è solo una raccomandazione come nel caso del "principio di minima sorpresa", è IMHO un errore usare un ID negativo. Forse l'esempio più estremo di usare float come ID è più intuitivo. – avnr

Penso che ci siano diversi modi per eseguire il backup e il porting di un database. Il backup/portabilità binario è un'opzione, ma non ci siamo limitati. Il vero errore sarebbe affidarsi all'architettura fisica per il backup o il porting di qualcosa. Come ho detto, nel caso in cui ciò accadesse, la portabilità sarebbe ancora un problema per qualsiasi altra colonna non fatturabile. Quindi risolverlo per il PK in realtà non risolverebbe nulla. La tua affermazione non si applica solo per PK, si applica a qualsiasi colonna di numeri, quindi sarebbe un errore usarla ovunque se è consentito un negativo, che è davvero privo di senso. – falsarella

Ci sono più di 51 milioni di siti che parlano di questo problema.

Sono d'accordo con @ Mike Sherrill ed è probabile che i campi NULL/Empty o ID negativi creino gravi problemi nel determinare i valori reali. Non serve affatto a scopi di informazione e può solo portare a risposte sbagliate e sfiducia nel database stesso.

Consentire valori zero, valori negativi nelle colonne introduce un nuovo grado di incertezza nel database. le supposizioni devono essere fatte dal programmatore SQL per neutralizzare i risultati errati dei valori NULL in un database.

fonte

2015-12-29 20:04:19 vrn53593

Perché l'ID negativo o lo zero sono considerati una cattiva pratica?

risposta

Problemi correlati