Questa è una buona soluzione per disattivare coppie di valori chiave?

Question

Questa è una buona soluzione per disattivare coppie di valori chiave?

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Un'applicazione CRUD (relativamente) semplice su cui lavoro ha una tabella di ricerca che contiene coppie chiave-valore, alcune delle quali hanno coppie di valori-chiave figlio. Questi sono usati principalmente negli elenchi a discesa sul front-end dell'applicazione.

Attualmente esiste un campo RowStatus per specificare che una coppia valore-chiave è attiva / non attiva e non deve essere inclusa negli elenchi a discesa. Questo va bene per la creazione di record, tuttavia si tratta di un problema durante l'aggiornamento dei record storici.

Ho intenzione di introdurre un campo ValidFrom e ValidTo nella tabella di ricerca per cui verranno utilizzate le schermate "Crea", insieme al campo RowStatus esistente, per garantire che tutti gli elementi negli elenchi a discesa siano validi per la data corrente- tempo. Anche questi sarebbero nullable nel qual caso il sql sottostante ignorerebbe il campo.

Le schermate

"Aggiornamento" continueranno a utilizzare solo il campo RowStatus, un vantaggio sarebbe che le schermate di aggiornamento potessero visualizzare anche gli articoli che erano validi al momento della creazione, anche se le regole aziendali lo determinerebbero.

In pratica, un controllo utente carica le coppie chiave-valore dalla tabella di ricerca e utilizza criteri diversi a seconda della pagina su cui si trova il controllo utente. vale a dire.

Crea:

select * from lookuplist where RowStatus=1 and ValidFrom < sysdate and ValidTo > sysdate

Aggiornamento:

select * from lookuplist where RowStatus=1

o

select * from lookuplist where RowStatus=1 and ValidFrom < CreatedOn and ValidTo > CreatedOn

Ci sono problemi con questo approccio che non ho considerato?

Qualsiasi modo in cui questo potrebbe essere migliorato?

Il codice è in c # / ASP.Net / Oracle 12C ma non è estremamente rilevante.

keys lookup

posta atamata 23.10.2015 - 15:30

fonte

3 risposte

Leggi altre domande sui tag keys lookup

Come fare report da python [chiuso] PHP best practice per il filesystem

score 1 · Answer 1

Ignorare il flag durante l'aggiornamento OR contrassegna l'aggiornamento come in errore se il flag passa da attivo a inattivo.
Ciò che scegli dipende dalla logica di business che stai implementando. In alcuni casi il primo è appropriato, in altri il secondo.
Ad esempio abbiamo un campo che determina gli intervalli di ispezione per le macchine. Questo campo è collegato ai requisiti legali e determina la data di scadenza di un certificato che è un documento legale. Se il valore in quel campo diventa inattivo, saltiamo il controllo attivo nella convalida del record perché ovviamente non è una buona idea cambiare la data di scadenza del certificato al volo solo perché un intervallo di ispezione non è più consentito ma una macchina è stata ispezionata l'ultima volta prima della modifica. Naturalmente quando si inserisce una nuova ispezione, è possibile selezionare solo gli intervalli validi validi.

In altri casi potresti voler contrassegnare il record per aver bisogno di essere aggiornato con un nuovo valore. Pensa a un campo che contiene il titolo di un cliente. Se decidi di non consentire un possibile valore in quella lista (forse a causa di un errore di battitura), vorresti che ogni successivo aggiornamento del record del cliente richieda la modifica del valore.

score 1 · Answer 2

C'è un fattore che potresti non considerare: i tempi di default dovrebbero essere vuoti o finirai con persone che mettono "un po 'di tempo in futuro" come predefinite e un giorno, riceverai una chiamata di assistenza per chiedere perché tutti i menu a discesa hanno smesso di funzionare (è successo a un collega nel momento peggiore - sono scaduti a mezzogiorno, dopo che i venditori hanno fatto il loro demo al mattino che doveva essere mostrato ai clienti nel pomeriggio).

Un valore predefinito di 3000 anni in futuro potrebbe funzionare, ma uno spazio vuoto per "non impostato" sarebbe più facile da leggere - e si può facilmente vedere quali sono "vivi" come la data di scadenza non sarebbe stata impostata. Allo stesso modo dovrai mettere una data di creazione su tutto ciò che potrebbe causare problemi per i tuoi record storici a meno che tu non abbia perfettamente ragione.

score 0 · Answer 3

Una considerazione potrebbe essere la riga che non è valida, quindi valida, quindi non valida di nuovo.

Per contrastare questa e altre complessità ti consiglierei di forzare la creazione di una nuova riga per un'azione di "riattivazione".

Ho già fatto sistemi simili e ho scoperto che gli utenti trovano le voci di menu "storiche" confuse, specialmente in una struttura gerarchica.

Un altro approccio consiste nell'avere "versioni" dell'intero albero, che poi cambi tra quando pubblichi / ripristini.

Una volta che una versione è attiva, non puoi modificarla. Ciò impone alcune buone pratiche agli utenti che mantengono la struttura e riducono la complessità della manutenzione.