Controllo del database: "Aggiornato a" Null o Not Null?

Naviga le tue risposte
0

Attualmente, stiamo lavorando al team di architettura sulla definizione dei modelli di database. Ciò che mi ha turbato è il consiglio del mio superiore quando si tratta di lavorare con campi di controllo .

Egli sostiene che i campi updated_at e updated_by siano Nullable, ragionando sul fatto che questi devono essere inizializzati come NULL perché la voce del database non è stata aggiornata ancora . 

CREATE TABLE example_table (
  ...
  created_at TIMESTAMP WITH TIME ZONE NOT NULL,
  created_by VARCHAR(128)             NOT NULL,
  updated_at TIMESTAMP WITH TIME ZONE NULL,
  updated_by VARCHAR(128)             NULL
);

Inoltre, osserva che per esperienza ha imparato che è meglio lasciarli come NULL , ma sfortunatamente non mi ha fornito esempi concreti.

Sono più propenso a rendere questi campi aggiornati NOT NULL perché:

  • Ci si assicura che questo non possa essere lasciato vuoto da qualsiasi errore.

  • Si può facilmente capire che il record è nuovo se i campi created_at e updated_at hanno lo stesso valore.

  • Il codice che funziona con questi campi aggiornati sarà più pulito in quanto non dovrà verificare la possibilità che siano nulli.

  • Altri team al lavoro hanno riscontrato inconvenienti. Alcuni strumenti che funzionano con i dati sono incompatibili o non funzionano correttamente con voci con valori aggiornati nulli.

Ecco cosa vorrei implementare: 

CREATE TABLE example_table (
  ...
  created_at TIMESTAMP WITH TIME ZONE NOT NULL,
  created_by VARCHAR(128)             NOT NULL,
  updated_at TIMESTAMP WITH TIME ZONE NOT NULL,
  updated_by VARCHAR(128)             NOT NULL
);

Ho cercato su Google un po 'di tempo, ma non sono riuscito a trovare un articolo che indicasse che una scelta fosse corretta, o che almeno una fosse migliore dell'altra.

Quindi sono curioso: mi manca qualche altro punto di vista? Quale approccio è migliore?

I miei esempi di codice sono in SQL , ma la mia domanda potrebbe riguardare anche altri tipi di database.

    
posta cavpollo 25.05.2018 - 19:25
fonte

3 risposte

2

What has been troubling me is my superior's advice ...

Hai chiesto al tuo superiore queste domande con l'atteggiamento di essere insegnabile? Onestamente questo sarà il tuo approccio migliore.

Which approach is better?

Né. Rappresentano la stessa quantità funzionale di dati. Le domande a cui devi rispondere sono:

  • È possibile che un valore null interrompa la segnalazione?
  • Quanto è complesso scrivere query?

I campi di controllo di solito non vengono interrogati spesso, ma solo quando è necessario ricostruire gli eventi. Entrambi gli approcci funzionano bene per il caso d'uso previsto.

    
risposta data 25.05.2018 - 20:31
fonte
2

Entrambi gli approcci sono fattibili e non c'è niente di intrinsecamente sbagliato in entrambi. Tenderei a preferire l'approccio che stai sostenendo principalmente perché i null sono un problema con cui lavorare in SQL a causa della logica a tre valori. In generale, è meglio evitarli. Come dici tu, aggiornato = creato ti dice la stessa cosa in cui il campo aggiornato è nullo per i nuovi record.

Da una nota a margine, il design generale di questo potrebbe essere migliorato. Con questo approccio, puoi vedere quando è stato creato il record e quando è stato aggiornato l'ultima volta. Non puoi dire quando altrimenti potrebbe essere stato modificato in mezzo o quali erano i valori in ogni fase. Un approccio più robusto consisterebbe nell'utilizzare un approccio di tipo "solo inserimento". In tal caso, traccia solo il timestamp creato. Quindi hai l'intera cronologia di tutte le modifiche. Puoi utilizzare una vista su questa tabella per semplificare per i client che necessitano solo dei dati correnti.

    
risposta data 25.05.2018 - 20:25
fonte
2

Hai già delle buone risposte qui, ma lascia che risponda ai tuoi argomenti "NOT NULL":

One makes sure this cannot be left empty by any mistake.

Un errore lasciando che questi campi si svuotino quando si verifica un aggiornamento non è più o meno probabile che dimenticare di aggiornare i campi ai valori corretti quando si verifica un aggiornamento, quindi questo argomento è un errore logico.

One can easily figure out the record is new if the created_at and updated_at fields have the same value.

Certo, ma non è né più difficile né più facile da testare per NULL. Ok, per alcuni casi si deve prestare particolare attenzione ai NULL nelle query, ma questa non è una differenza abbastanza importante da proibire generalmente le colonne NULL.

The code that works with these updated fields will be cleaner as it won't have to check for the possibility of them being null.

Dipende molto dal linguaggio e dal framework db che vengono utilizzati, ma onestamente, il supporto del valore NULL non è una scienza missilistica e non dovrebbe rendere il codice quello più complicato.

Other teams at work have experienced inconveniences. Some tools that work with the data are incompatible, or don't function properly, with entries that have null updated values.

Quindi stai dicendo che ci sono altri team con problemi a gestire correttamente i valori NULL? Sul serio? Se hanno davvero degli strumenti che hanno problemi con questo, come fanno gli strumenti a gestire le colonne Nullabili in altre tabelle? Sono sicuro che non hai una regola aziendale per vietare tali colonne (altrimenti non avresti fatto la domanda in primo luogo), quindi è meglio che correggano quegli strumenti, poiché prima o poi dovranno trattare con NULL valori.

In breve, anche tu (e probabilmente anche il tuo superiore) stai pensando troppo a questo, entrambi gli approcci sono ugualmente validi, e la cosa migliore che puoi fare è lanciare una moneta.

    
risposta data 25.05.2018 - 21:51
fonte

Leggi altre domande sui tag

Metodo per aggiornare un tipo di riferimento - restituire un oggetto o usare void Web API Response, Error Code Convention [duplicate]