Progettare tabelle e modelli per la spedizione e le modifiche e mantenerlo normalizzato

Naviga le tue risposte
0

La nostra azienda acquista oggetti di valore di seconda mano (articoli) dai clienti e li rivende per loro. Per fare in modo che il cliente arrivi nel nostro sito e chiedere una spedizione, può scegliere il momento in cui l'addetto alle consegne viene a ritirare il prezioso. Se non sceglie il momento in cui un venditore lo chiama e organizza il tempo per lui. È anche possibile che il cliente chiami e chieda la modifica dell'orario di consegna. Fino ad ora abbiamo appena salvato i dati nella tabella spedizioni in questo modo:

id, item_id, schedule_time, scheduled_by_type, scheduled_by_id, created_at

scheduled_by è polimorfico può essere Clint o Salesman

Se il cliente desidera aggiornare il tempo, dovremmo semplicemente aggiornare la riga di spedizione. Ora l'azienda deve fare un rapporto della programmazione creata ogni giorno (per i bonus al venditore), quindi ho bisogno di mantenere i dati anche per le modifiche. Devo anche mantenere la possibilità di ottenere l'ultimo programma per una spedizione. Mi piacerebbe sapere qual è la migliore pratica per fare questo significato, rendendo i dati più vicini ai concetti di dominio e non duplicando i dati (normalizzandoli). Le prestazioni non sono un grosso problema.

La mia idea di rimuovere schedule_time, scheduled_by_type, scheduled_by_id dalla tabella spedizione e di creare una nuova tabella chiamata shipment_schedules . Inoltre ho aggiunto latest_shipment_schedule_id alla spedizione tabella

Quindi shipment_schedules sarà:

id, shipment_id, schedule_time, scheduled_by_type, scheduled_by_id, created_at

e spedizione saranno:

id, item_id, latest_shipment_schedule_id, created_at

Il mio dilemma è perché non sono questa la soluzione migliore per descrivere il dominio. Perché non è come la spedizione ha davvero molti orari come padre ha molti figli. Le cose importanti sono solo l'ultimo programma. La nuova tabella è solo per il salvataggio della cronologia. Un altro approccio sarebbe mantenere la tabella di spedizione come era prima di creare la nuova tabella e magari rinominarla shipping_history o shipment_changes. Può descrivere meglio il dominio perché hai l'ultimo risultato e un elenco di modifiche che ti hanno portato a questo risultato (come annullare in Word) ma d'altra parte otterrai dati duplicati.

Quale pensi sia l'approccio migliore per farlo. Non deve essere uno di questi alle soluzioni

Usiamo Ruby On Rails 4 e PostgreSQL 9.6 Ma una lingua non ha molta importanza

Un'altra domanda è dalla prospettiva di Ruby On Rails. Voglio aggiornare la spedizione e creare i record shipping_schedule con una singola chiamata dal controller. Lo sto facendo con i callback di Active Record. dovrei utilizzare una richiamata after_create sul modello ShipmentSchedule per aggiornare il modello di spedizione o utilizzare after_update sul modello di spedizione per creare ShipmentSchedule? In altre parole, cosa viene prima di creare lo ShipmentSchedule o l'aggiornamento della spedizione?

    
posta Natan Rubinstein 09.10.2017 - 10:41
fonte

1 risposta

1

Per avere un buon modello, non dovresti prima pensare alla persistenza. La persistenza è un altro problema che dovrebbe essere risolto separatamente. Pensare contemporaneamente ai 2 problemi spesso comporterà una complessità non necessaria. Quindi analizziamo la domanda in due:

Come progettare il modello di dominio: Il modello di dominio dovrebbe riflettere il business. Nel nostro caso, un articolo ha una sola spedizione. E il venditore ha una cronologia delle spedizioni. Suggerirei il seguente modello di dominio. La classe Item ha una proprietà shipmentSchedule che dovrebbe essere un'istanza della classe ShipmentSchedule (dovrebbe essere un oggetto valore). La classe Salesman ha una history di spedizione che è una raccolta di SalesmanShipmentSchedule. Ogni volta che viene creata una pianificazione da un venditore, la pianificazione della spedizione dell'articolo viene aggiornata e viene aggiunto un nuovo SalesmanShipmentSchedule all'oggetto Salesman (ciò può essere fatto tramite eventi)

Come mantenere il modello: Penso che sia abbastanza semplice persistere. Vedo che per questo progetto stai usando un database relazionale. Per ShipmentSchedule puoi avere una tabella separata ma in questo caso, non penso che la spedizione abbia bisogno di un'identità, quindi può essere un oggetto valore che viene serializzato e memorizzato in una colonna. Se stai usando doctrine, puoi memorizzarlo come embeddable o semplicemente serializzarlo come json (Postgres e MySql > 5.7 supportano l'interrogazione dei campi json). Per SalesmanShipmentSchedule, è possibile creare una tabella separata che contenga tutti i programmi di spedizione.

Penso che per ora sia un modello semplice, ma può diventare complicato quando si aggiungono più entità e oggetti di valore. E poi potresti aver bisogno di un buon sistema per separare dominio e persistenza. Ecco un bel articolo che affronta questo tipo di problemi

    
risposta data 09.10.2017 - 11:55
fonte

Leggi altre domande sui tag

T4 Template vs conversione manuale in C # Inietti il tipo come iniezione di dipendenza, quando sono richieste nuove istanze per ogni chiamata di metodo - Come evitare?