Buona giornata. Ho bisogno di aiuto per un caso specifico. Un po 'di background: abbiamo un'app esistente, è come un visualizzatore di PDF e puoi disegnare a mano libera, evidenziare, aggiungere evidenziazioni con note, aggiungere elementi di azione, ecc.
In questa discussione, discuterò le due tabelle del database 1) la tabella ACTION_ITEM contenente l'elenco degli elementi azione di un documento e 2) la tabella HIGHLIGHT contenente l'evidenziazione e le note.
La differenza tra una nota evidenziata e un'azione è che nella voce azione è possibile assegnarla a una persona, specificare una data di scadenza e contrassegnarla come completata.
Al momento abbiamo aggiunto un miglioramento, affinché l'utente finale possa convertire una nota evidenziata in un'azione. Quindi abbiamo aggiunto una casella di controllo "[] Action Item". Quando si converte in un oggetto azione, la UX di esso sarà sempre la stessa: visivamente sembra ancora una nota, è ancora associata a un'evidenziazione, e si trova ancora su una pagina, tranne che ha "Azione "controllato. (La nostra "solita" azione, non è associata a una pagina).
I programmatori (incluso me) hanno già codificato il miglioramento (questo è in più piattaforme), in modo tale che lo sapevamo meglio: abbiamo aggiunto le nuove colonne necessarie alla tabella HIGHLIGHT: data di scadenza, persona assegnata, stato e una voce azione indicatore.
Ora ecco la parte difficile, c'è una discussione sul design in corso per cambiare il design fisico per trasferire la nota evidenziata contrassegnata come una voce di azione alla tabella ACTION_ITEM. Ciò significa copiare tutte le colonne necessarie nella tabella HIGHLIGHT come rettangolo di evidenziazione, posizione della nota, numero di pagina, ID documento, ecc. E copiarlo nella tabella ACTION_ITEM.
Questo vale solo per evidenziare note contrassegnate come azioni. Se la nota di evidenziazione non è contrassegnata come una voce di azione, dobbiamo ancora memorizzarla nella tabella HIGHLIGHT. Attualmente, contrassegnando una nota come un'azione, cambiamo semplicemente una colonna, nel nuovo design, dobbiamo trasferire l'intero record su un'altra tabella.
Non solo il design fisico cambierà, ma tutta la logica relativa alla sua memorizzazione e al suo recupero (che è molto).
Il motivo è che l'analista dei sistemi ha detto che invece di programmare per comodità, abbiamo bisogno di allineare la progettazione fisica al concetto di business. In questo caso, una voce azione è un concetto aziendale diverso, quindi deve essere nella tabella ACTION_ITEM.
La mia domanda è, Systems Analyst è corretto? Uniamo entità fisicamente diverse nella stessa tabella, solo perché è lo stesso concetto di business? Sembra illogico per me come programmatore. Non è solo per comodità, è per efficienza.