Modellazione di opzioni di prodotto complesse

Question

Modellazione di opzioni di prodotto complesse

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

5

Ho lavorato a un brainstorming su un problema specifico per un po 'e oggi ho pensato a una soluzione. Ma non ne sono troppo sicuro. Quindi questa domanda per feedback e suggerimenti.

Userò il semplice esempio di un prodotto T-Shirt .

La T-Shirt ha più opzioni:

Color : White , Black

Size : Small , Medium , Large

Ora, nel caso di una T-shirt White , non c'è Large e Medium . Pertanto, l'opzione Large e Medium non dovrebbe essere disponibile quando si seleziona White .

Questo significa che se selezioni per la prima volta Large o Medium . Quindi White non dovrebbe essere disponibile.

L'implementazione precedente è stata eseguita come struttura ad albero. Quindi devi sempre selezionare Color poi Size . Ma non è davvero un albero come lo vedo io.

La mia idea era di creare un elenco di regole.

codice pseudo:

rule1: if color is white, sizes not allowed are [large, medium]

//then generate the opposite rules based on rule1.
rule2: if size is medium, color not allowed are [white]
rule3: if size is large, color not allowed are [white]

store rules in database

Quando hai a che fare con prodotti che hanno molte opzioni questo potrebbe complicarsi, ecco perché pensavo che la generazione delle altre regole basate sulla prima regola potesse ridurre la complessità.

Pensieri a qualcuno?

Aggiornamento:

Qualcuno ha notato di seguito e ho capito che ho usato l'esempio sbagliato. Non è un prodotto con SKU e livello di stock. È un servizio. Un esempio migliore sarebbe un computer configurabile. Molte combinazioni di CPU, RAM, GPU, ecc. Che tutti producono un prezzo diverso e dipendono da specifiche schede madri o da una selezione specifica, non tutte le CPU e / o RAM ecc. Sono selezionabili.

Update2:

I prodotti / servizi hanno ciascuno circa 7 opzioni. Ogni opzione può avere tra 2 e 7 valori. Una struttura a matrice come suggerito, diventerebbe complessa IMO.

Inoltre, ci siamo allontanati dall'avere un prezzo per ogni singola variazione (cosa che è stata ridicola da gestire) con la formula per generare prezzi in modo dinamico.

C'è sempre stato un problema con il carico del DB a causa della struttura ad albero. Ogni volta che viene selezionata un'opzione, deve recuperare i valori delle opzioni successive. Ogni volta che aggiungi un nuovo valore a un'opzione, puoi anche duplicare molte delle opzioni successive. Quindi ti sfugge molto velocemente.

Per entrare in maggiori dettagli la mia soluzione era usare un database basato su documenti (NoSQL) Avresti una raccolta "Prodotti" o "Servizi".

Ogni prodotto / servizio sarà simile a questo:

{
  "product": "T-Shirt",
  "options": {
    "size": [],
    "color": [],
    "pattern": [],
    ... about 4 more
  },
  "rules": [....],
}

Inizialmente si caricano tutte le opzioni nell'interfaccia. Quindi, mentre esegui le selezioni, esegui le regole per disabilitare i valori delle opzioni specificate.

L'uso di una struttura del genere mi sembra che avrebbe un sovraccarico minore avendo le regole incorporate in ogni prodotto / servizio invece di avere una grande tabella relazionale con tutte le opzioni (che è già enorme).

Il lato client è vantaggioso perché non deve interrogare il DB ogni volta che viene modificata un'opzione.

design

posta moleculezz 13.01.2017 - 15:38

fonte

4 risposte

Leggi altre domande sui tag design

Perché Protobuf 3 ha reso facoltativi tutti i campi sui messaggi? DependencyInjection - Constructor over-injection smell vs service locator - dove è l'approccio corretto?

score 3 · Answer 1

Un albero (la tua implementazione esistente) è più semplice da modellare ma imponi limiti nell'ordine con cui gli utenti devono selezionare il tipo di prodotto che desiderano. Se ciò non va bene per te, un modo generico di modellare tutte le combinazioni (esistenti o future) è rappresentare le combinazioni come una matrice multidimensionale indicizzata da stringhe anziché da numeri (più come un dizionario multidimensionale in realtà).

Nella risposta dell'utente COMEFROM è rappresentato ciò che è rappresentato, un array tridimensionale: Product x Color x Size . All'intersezione di tutte le colonne si memorizza un valore booleano. Se ['t-shirt', 'white', 'large'] == false , allora non hai una maglietta bianca grande. Se è vero, allora hai.

Naturalmente questo si complica velocemente. Più aggiungi prodotti e opzioni, più dimensioni aggiungi all'array. Sopra le 4 dimensioni ed è difficile visualizzare la struttura dei dati o pensarci. Anche il numero di valori memorizzati aumenta.

Ma se hai solo poche eccezioni, forse puoi modellare solo quelle con una matrice multidimensionale. Fondamentalmente si presuppone che una combinazione sia valida e quindi si cerca nell'array multidimensionale di eccezioni per vedere se il valore è presente. Se è così, l'ipotesi è falsa, il che significa che non hai quella particolare combinazione.

Il vantaggio di un array multidimensionale è che puoi guardarlo da qualsiasi direzione tu voglia. Primo colore poi taglia, o prima dimensione e poi colore, è tutto uguale. Alla fine raggiungi la cella in cui si incrociano tutte le opzioni e vedi il valore che hai lì. Lo svantaggio è che la dimensione dell'array può diventare molto grande e che è necessario ricostruire i valori ogni volta che si aggiunge una nuova dimensione.

Anche la tua soluzione per avere regole può funzionare. È simile all'array multidimensionale, ma modella l'esecuzione (se-allora-altro) invece della ricerca dei dati basata su alcuni valori (la ricerca dei dati è più semplice della logica delle regole).

score 2 · Answer 2

Potresti voler consultare il Valore dell'entità-Attributo design per modellare cose che hanno più tipi di attributi con valori arbitrari.

Ho imparato a conoscere questo modello di design da Magento, un'app di e-commerce. Puoi leggere come utilizzano l'EAV qui .

score 1 · Answer 3

Il termine standard per il tuo problema viene solitamente definito product lines . Un esempio meno semplificato sono le auto. Quando acquisti una nuova auto, ci sono molte opzioni per configurarla con molti vincoli su quali combinazioni sono possibili e quali no.

Product lines significa semplicemente che un prodotto è disponibile in molte diverse configurazioni (linee).

Per avvicinarti alle tue domande, queste configurazioni sono in genere singole funzionalità, che possono essere modellate insieme ai loro vincoli. Dai un'occhiata a FeatureIDE per un esempio di uno strumento disponibile per questo tipo di feature modeling .

Tenere presente che in generale, vincoli arbitrari possono portare a valutazioni veramente complesse che sono necessarie, su quali funzionalità sono ancora selezionabili e quali no. La modellazione di feature utilizza quindi approcci molto più sofisticati rispetto alle semplici valutazioni ad albero. Forti strumenti come FeatureIDE quindi traducono le tue caratteristiche selezionate e tutti i vincoli in una formula SAT di grandi dimensioni e eseguono solutori SAT all'avanguardia per rispondere a domande come "quali altre funzionalità posso ancora selezionare?".

Spetta a te decidere se il tuo caso d'uso garantisce questa complessità e richiede la modellazione completa delle funzionalità, o se hai un modello di funzionalità molto semplice e vuoi fare le cose manualmente. Come le altre risposte finora non hanno fatto notare, che ci sono strumenti di modelli di funzionalità là fuori, ho appena aggiunto questo per completezza e come riferimento per i futuri lettori.

score 0 · Answer 4

Probabilmente avrei una serie di set di opzioni memorizzate per ciascun prodotto. Quindi, per la maglietta ci sarebbe questo set di opzioni disponibili:

{ 
    {"color:white", "size:small"},
    {"color:black", "size:small"},
    {"color:black", "size:medium"},
    {"color:black", "size:large"}
}

Questi sono tutti i dati necessari per riconoscere i tipi di opzioni di un prodotto ("colore", "dimensione"), i valori disponibili per ciascun tipo e le combinazioni di opzioni consentite in un ordine valido del prodotto.

Si noti che questo modello funziona solo quando c'è una scelta relativamente limitata di opzioni e valori. Non è possibile concedere alcun colore RGB a 24 bit come opzione. I set diventerebbero semplicemente troppo grandi per essere archiviati e gestiti.

(Nota: la sintassi di cui sopra non dovrebbe essere JSON o qualcosa di veramente. La tecnologia è irrilevante.Questi {} s indicano un set come in matematica.Gli oggetti (opzioni) nei set potrebbero essere stringhe o di qualche tipo personalizzato Il punto è avere un semplice set di dati che rappresenti ogni valida combinazione di opzioni per un prodotto.)

Modifica: dopo aver letto l'aggiornamento 2 della domanda, direi che questa non è una soluzione fattibile. Però avrebbe funzionato per un numero limitato di opzioni basate sui livelli di scorte di un prodotto.