Come posso archiviare record incompleti ma applicare la correttezza dei dati?

5

Sono nelle fasi di pianificazione / progettazione di un nuovo progetto e ho difficoltà a trovare un buon modo per gestire uno dei requisiti:

Users must be able to create a new record and save it as "Incomplete" without filling out all required fields.

Questo è un requisito che si applicherà a quasi tutti i tipi di record modificabili dall'utente nell'applicazione.

I record hanno un numero di stati potenziali e in uno stato diverso da "Incomplete" devono avere tutti i campi obbligatori compilati.

È abbastanza semplice, ma ho difficoltà a capire come archiviarlo in modo da non sacrificare la capacità di applicare la correttezza dei dati sui record "completati".

Il modo più semplice per gestire questo requisito sarebbe quello di rendere nullable tutti i campi dell'oggetto business e della sua tabella di database e quindi eseguire controlli di convalida rigorosi contro i record ogni volta che vengono spostati dallo stato Incomplete. Tuttavia, non mi piace l'idea di imporre la maggior parte dei requisiti di correttezza dei dati puramente nel codice a livello di applicazione piuttosto che nel design del database, quindi sto cercando di trovare qualche altra opzione.

Mantenere uno schema separato per i record incompleti è un'idea che è stata discussa, ma c'è il timore che aggiunga troppi costi aggiuntivi, poiché ora abbiamo uno schema separato da estendere ogni volta che qualcosa cambia e dovremo gestire i record in movimento da uno all'altro quando sono completati.

Esiste una best practice per questo tipo di problema? Dovremmo solo mordere il proiettile e rendere nullable tutti i campi?

(Lo stack tecnologico che stiamo usando è ASP.NET WebAPI su SQL Server 2014, ma sembra piuttosto applicabile a qualsiasi stack supportato da un database relazionale)

    
posta Angle O'Saxon 20.01.2016 - 03:29
fonte

3 risposte

5

Potresti avere una tabella separata per lavori in corso. Si utilizzerà più o meno lo stesso schema di tabella, solo con ogni campo impostato come annullabile.

Quando un record viene inizialmente creato, entra nella tabella dei record incompleti (è possibile avere un assegno per inserire i record completati per la prima volta direttamente nella tabella dei record completati, ovviamente). Una volta che un record è stato completato, lo copierai nella tua tabella completata e lo cancellerai da incompleto.

Ovviamente, questo ti costringerebbe ad unirti alle tabelle nel caso in cui volessi eseguire query su record completi e incompleti, ma non è certo la fine del mondo [Citation Needed]

    
risposta data 20.01.2016 - 03:59
fonte
3

Una possibilità, non ancora menzionata, è che non si configura un record incompleto nel database affatto - lo si tiene semplicemente come un blob (serializzato in qualche modo) da qualche parte (potrebbe essere nel database, potrebbe essere altrove).

Dipende piuttosto da cosa, se non altro, viene fatto con record incompleti (si tratta di flusso di lavoro e relativi). In particolare se il 90% del codice carica i dati con variazioni di '' 'WHERE NOT status = incomplete' '', i record sostanzialmente incompleti sono solo rumore. Se, d'altra parte, il valore inizia ad accumularsi anche se il record è incompleto, allora questa non è necessariamente una buona soluzione.

In ogni caso, semplicemente ponendo la domanda può essere d'aiuto una migliore comprensione

    
risposta data 20.01.2016 - 10:55
fonte
1

Il requisito è auto-contraddittorio: i campi obbligatori devono essere tutti facoltativi. Ma okay, ridiamo della persona che ha scritto le specifiche e poi proseguiamo.

Penso che creare due tabelle sia una pessima idea. Ciò significherebbe che tutte le definizioni dei campi devono essere duplicate. È probabile che molte query debbano essere duplicate, il tuo inserto di base al minimo. Quindi ogni volta che si modifica lo schema, devi fare attenzione a farlo in entrambi i punti. Prima o poi qualcuno si dimenticherà, o ci farai lavorare un programmatore che non conosce i due tavoli, e poi se sei fortunato lo fa saltare in test e non in produzione. Se si dispone di processi che si applicano a record completi e incompleti, ora è necessario eseguire UNION, che se la query è semplice potrebbe non essere un grosso problema ma se la query è complessa aggiungerebbe un ulteriore livello di complessità e creerebbe potenziale errore. Potrebbe essere necessario preoccuparsi di duplicati tra la tabella completa e la tabella incompleta. Ecc. Tutto intorno, suona come un dolore gigantesco.

Se la convalida di un record completo è semplicemente "non nulla", allora ok, farlo in una tabella ti costringe a scrivere del codice extra. Questo non mi sembra un grosso problema per me. Puoi facilmente inserire un trigger di add / update che dice che se complete = true e (il nome è nullo o foo è nullo o la barra è nullo), genera un errore.

Penso che ti serva comunque questa convalida nel codice. Probabilmente hai una sorta di schermata di immissione dei dati in cui l'utente deve digitare tutto questo. Penso che ti piacerebbe dare un messaggio di errore come "Errore: il cognome non può essere vuoto" o qualcosa del genere. Non ti basi solo su un'eccezione SQL per dirti che i dati non sono validi, vero? Certo, quando un campo è veramente richiesto, metterò un vincolo non nullo nel DB come una garanzia extra contro i dati cattivi. Ma il codice dovrebbe controllarlo prima di scrivere un record, quindi se il campo è realmente solo condizionalmente richiesto, inserisco quel test nel codice.

    
risposta data 20.01.2016 - 05:29
fonte

Leggi altre domande sui tag