Sta usando -1 come ID speciale una buona idea in SQL?

Question

Sta usando -1 come ID speciale una buona idea in SQL?

#1 da (4 voti)
#2 da (1 voti)

3

Sto provando a determinare se l'utilizzo di '-1' in una colonna Identity presenta degli svantaggi o se esiste un modo migliore di fare ciò che voglio.

Nel mio database ho una tabella User e una tabella Group . Tutti gli utenti devono appartenere a un solo gruppo. Le definizioni di tabella sono simili a questa.

CREATE TABLE User
(
    UserId int Identity(1,1) not null primary key,
    GroupId int not null -- FK to group
    /* More columns */
)

CREATE TABLE Group
(
    GroupId int Identity(1,1) not null primary key,
    /* More Columns */
)

Quando l'utente accede all'applicazione, è in grado di visualizzare informazioni sul gruppo a cui appartiene. Ora vogliamo aggiungere un gruppo speciale in cui gli utenti sono in grado di visualizzare (e non modificare) i dati per tutti gli altri gruppi. Il mio team ha già deciso che gli utenti devono appartenere a un gruppo speciale per ricevere questa funzionalità. Mi chiedo se sia una buona idea indicare questo gruppo come speciale impostando il suo GroupId su 1.

sql database-design relational-database

posta Andrew Bonsall 05.10.2018 - 22:21

fonte

2 risposte

1

Penso che sia necessario separare completamente i "gruppi" da "autorizzazioni". Quello che sembri essere dopo è il ruolo e l'autorizzazione basata sui permessi.

Un utente ha molti ruoli
Un ruolo ha molte autorizzazioni
Ci dovrebbe essere 1 autorizzazione per ogni azione che un utente può eseguire su ogni entità nel sistema, sia essa una lettura, scrittura o cancellazione.

In questo momento potrebbero dire che un utente esegue solo un tipo di ruolo nel sistema. Queste cose cambiano tutto spesso. Gli utenti possono giocare molti ruoli nel tuo sistema, specialmente dopo aver aggiunto moduli aggiuntivi.

Poiché un utente può giocare molti ruoli nel sistema, un record utente deve essere associato a più ruoli. Forse in questo momento lo standard è solo 1 ruolo per utente. Va bene. Modella il database per più ruoli per utente in ogni caso. Non è molto lavoro extra.

Inoltre, il "ruolo" riprodotto da un utente si traduce in più azioni e, in quanto tale, un ruolo deve essere associato a più autorizzazioni.

Alla base di tutto questo c'è il "permesso". Crea 1 autorizzazione per ogni azione che un utente può eseguire.

Questa triplice combinazione di "ha molte" relazioni ti dà una grande flessibilità. Puoi refactoring l'autorizzazione nel sistema aggiungendo o rimuovendo i permessi da un singolo ruolo, e presto! Gli utenti vengono aggiornati, in virtù del fatto che sono associati a tale ruolo e le autorizzazioni che un utente ha derivano dai ruoli che hanno. Nel mondo della modellazione dei dati sarebbe noto come normalizzazione.

Ho trovato l'autorizzazione ad essere una delle frequenti eccezioni a YAGNI (Ya Is not Gonna Need it). Hai già bisogno di due ruoli. Quando l'azienda scopre quanto sia facile creare ruoli, troverà di più . E anche se la creazione di un ruolo è resa difficile, troverà di più, dal momento che le esigenze aziendali cambiano costantemente.

risposta data 07.10.2018 - 02:46

fonte

Leggi altre domande sui tag sql database-design relational-database

Come sei venuto a conoscenza della sicurezza nel tuo sviluppo web? Scelta dei colori per l'applicazione [chiuso]

score 4 · Accepted Answer

In effetti, è corretto dedurre che questa è una pessima idea (indicativa dell'odore del design). L'uso di "-1" come ID "speciale" / Chiave primaria è orribile e non dovrebbe mai essere utilizzato in alcun database legittimo o di produzione. L'implementazione di tale pratica implica che tu (o il tuo team) abbia un problema di progettazione che non vuoi indirizzare correttamente e completamente.

Penso che ci sia molto valore nella lettura della buona progettazione del database e della modellazione dei dati; in particolare l'immenso valore di pensare in modo critico attraverso il framework di progettazione sul perché questa sarebbe davvero una pessima idea da implementare una volta completata la lettura di cui sopra.

Ecco alcuni punti generali dei proiettili per giustificare la mia risposta in modo più completo (anche se una corretta lettura e ricerca sono strenuamente raccomandate quando si parla di modellazione dei dati e buona progettazione del database):

Ora stiamo stabilendo numeri "magici" in un database rispetto allo sviluppo di una soluzione completa utilizzando tabelle e relazioni appropriate
Probabilmente non documenteremo i numeri "magici" da nessuna parte (o molto improbabili da leggere o notare in futuro) o aggiorneremo la documentazione relativa (inclusa nell'applicazione che utilizza detto DB)
Cosa succede quando viene creato un altro caso d'uso "speciale"? Usiamo -2? Quindi -3, -4, ... Stiamo aprendo una lattina di vermi e ci tufferemo in una tana del coniglio che alla fine si evolverà in troppi dolori da risolvere
Stiamo ignorando un meccanismo DB fondamentale per una soluzione rapida a un problema di progettazione di modelli di dominio / dati
Interagiremo potenzialmente con qualsiasi rapporto che potrebbe essere scritto (non è raro in Reporting land usare -1 per creare un'opzione "Select All" per un parametro che non può utilizzare l'opzione multi-valore, accade raramente ma succede) già o in futuro (e il significato dei rapporti di "-1" per la tabella sarà incoerente con il significato effettivo della chiave "-1" nel DB)
Quando i DBA senior si uniscono al team e vogliono risolvere correttamente il problema, probabilmente dovremo avere alcuni problemi tra i nostri amministratori di database e gli sviluppatori a causa del lavoro richiesto per cambiare un (cosa che si spera sia 1) "magico" numero.