Decomposizione per "ruolo" o per "utilizzo" - è una cosa?

2

Ho una tabella mail_queue su cui sono scritte le richieste Web, poi un lavoratore ha lavorato per inviare i messaggi. Ora ho avuto un momento di illuminazione. ciò di cui non ero a mio agio nel design.

Prima: Una tabella di database chiamata mail_queue, che il lavoratore elabora, & aggiunge un campo sent_at quando inviato. Ciò significa ottenere messaggi da inviare, deve fare una selezione da dove send_at è nullo. Per essere parsimonioso sulle tabelle del database, non ho davvero bisogno di un'altra tabella, perché un send_at null può benissimo indicare che un messaggio deve ancora essere inviato.

Eppure, c'era qualcosa che non mi sentivo a mio agio nell'avere una coda che non era stata eliminata. Cosa succede se il campo sent_at è stato annullato per errore? Non posso probabilmente vederlo accadere, ma anche così, ero a disagio con questo design.

Leggendo le code un po 'di più ho avuto l'impressione che alcune code possano essere elaborate da più tipi di processi. Vedo che ciò che il mio operatore può fare è togliere il file mail_queue, elaborarlo e, in caso di successo, cancellarlo dalla coda, più aggiungere praticamente lo stesso record a una nuova tabella mail_sent, insieme al nuovo campo sent_at.

Qual è la giustificazione per avere una tabella aggiuntiva, quando il primo metodo descritto sopra sembra del tutto corretto in termini di parsimonia con le rappresentazioni del database?

La risposta che ho trovato è che ora posso vedere che, ad esempio, volevo ascoltare i webhook in arrivo come consegnati, il processo che riceve quel webhook non ha più bisogno di accedere a il mail_queue, solo mail_sent.

È una specie di "decomposizione" ? Mi sembra che lo sia. Non si tratta di dividere le operazioni; piuttosto sulla suddivisione dello storage dei dati in base all'utilizzo; "decomposizione per ruolo" "per uso", "per accesso". Sono quei una cosa?

Solo essere un po 'discorsivo qui, aiuta molto a scrivere le cose e apprezzo molto l'opportunità di condividere qui e discutere.

(Stavo guardando un video di Rich Hickey che parlava di Clojure che mi ha fatto pensare alla decomposizione:))

    
posta mwal 05.10.2018 - 21:37
fonte

1 risposta

1

What is the justification for having an extra table, when the first method outlined above seems entirely ok in terms of being parsimonious with database representations?

Non vedo una giustificazione per questo. Forse c'erano alcune circostanze speciali che hanno portato l'autore a preferire quel disegno. Probabilmente, si sbagliava al riguardo.

Il design a tavolo singolo è migliore perché è più semplice e fa la stessa cosa.

Is that a kind of "decomposition"?

Sì, è una decomposizione inutile. La decomposizione non rende magicamente l'architettura migliore. A volte non guadagni nulla ma introduci il sovraccarico di gestione. Questo è il caso qui.

"decomposition by role" "by usage", "by access"

Non si può arrivare ad una buona architettura applicando tali "decomposizioni" / schemi generici. I buoni programmatori hanno una cassetta degli attrezzi mentale di 1000 modelli. Hanno scelto con gusto quali di essi si applicano a una determinata soluzione. Non puoi decidere con una regola rigida. Piuttosto, devi considerare l'intero sistema che stai costruendo e trovare la migliore architettura possibile.

    
risposta data 08.10.2018 - 12:07
fonte

Leggi altre domande sui tag