Ho un record SKU che tiene traccia delle materie prime utilizzate, dei prezzi, dei costi, ecc. Un esempio di SKU sii un Hamburger (1 panino, 1 patty, 1 oz ketchup, costa $ 11, costa $ 4, ecc.)
Ho bisogno di aggiungere il concetto di SKU compositi ora, come Burger and Fries Meal, che avrebbe un SKU Hamburger e SKU Fries, oltre a confezioni speciali per il pacchetto Pasto. È improbabile che il numero di sottovoci aumenti di più di 5 al massimo.
Ho bisogno di modellarlo nel mio DB e nella mia applicazione. L'utente non si preoccupa se uno SKU è composto o meno, eccetto quando sta facendo effettivamente l'installazione iniziale e sta componendo in cosa consiste una SKU composita.
Ecco una cosa che ho considerato:
Opzione 1: Ho preso in considerazione l'idea di fornire a SKU una SKU principale opzionale. Quindi il numero di voci secondarie è scalabile (da 1 a molti), e l'uso dell'oggetto SKU nel mio codice applicativo rimarrebbe in gran parte lo stesso (specialmente nella parte dell'applicazione utente), come continuerei a utilizzare SKU. Una truffa è perché uno SKU sarebbe denotato come avente un genitore, quindi avrei bisogno di creare gli SKU di Hamburger per la vendita indipendente, per i pasti di hamburger e patatine fritte, per i pasti all'anello di hamburger e cipolle, ecc. prospettiva di mantenimento delle scorte.
Opzione 2: Fornire gli articoli secondari facoltativi SKU SKU.SubSku1, SKU.SubSku2, ecc. (Da 1 a N). I pro di questo sono che ancora una volta mi permette di cambiare molto poco del mio codice rivolto all'utente. Permetterebbe ad un hamburger di apparire in più di uno SKU composito, oltre che in versione standalone. Sostenere l'aggiunta di sotto-elementi nell'interfaccia utente esistente sarebbe molto più semplice anche in questo modo. Questo non richiede una tabella di join. Il cono è che supportava un aumento nel numero di sotto-elementi richiederebbe un cambio di schema.
Opzione 3: Sostanzialmente uguale a 2, ma usando una tabella Join (molti a molti). Questo scalerebbe meglio, ma non sono sicuro che il ridimensionamento sia davvero un problema, come ho detto che questo è più un problema di Pasto in Hamburger, non una relazione da Organizzazione a Persona. Questo potrebbe essere complicato da gestire nel mio codice UX, ma vedremo.
Opzione 4: Creare un modello CompositeSku nella relazione many-to-many o 1-N con SubItems. Questa opzione potrebbe essere suddivisa in base alla relazione. Ma il significato di questa opzione è che si tratta di un modello separato dal mio normale oggetto SKU. Dato che questo SKU composito proviene dal mio livello dati nel mio livello aziendale / servizio, potrei adattarlo affinché appaia come un normale SKU, probabilmente come lo adatterei alle opzioni precedenti. I pro si attengono a più di un singolo modello per paradigma di modello e meno campi inattivi (cioè campi che vengono utilizzati solo quando SKU è un genitore). I truffatori dovevano adattare un oggetto per apparire come uno SKU, o scrivere un sacco di codice per gestire gli SKU compositi ovunque nella UX dove sono gestiti gli SKU attualmente normali. Un altro grande problema è il recupero e la ricerca dei dati. Estraggerei i dati da una tabella aggiuntiva, dovendo unirli ai normali dati della SKU.
Mi sto davvero avvicinando al 2 e al 3, ma il # 2 sembra un po 'un anti-pattern. La relazione da 1 a N (parent.child1, parent.child2) è un anti-pattern?
Se è importante, sto utilizzando Entity Framework, MS-SQL e C #. UX fa un uso pesante delle griglie Kendo (che ritengo possa influenzare il mio design troppo probabilmente).