Imporre le relazioni di entità condizionale

1

Mentre lavoro su un'applicazione, sto affrontando un problema. E non sono sicuro di come risolvere questo.

Per spiegazioni, sono riuscito a trovare un semplice esempio di seguito:

Considera un'applicazione di un negozio di alimentari.

  • Ha un numero finito (il che significa che gli oggetti non cambieranno spesso) di oggetti.
  • Ogni elemento è diverso dagli altri e ha le sue proprietà. In questo esempio sono:
    • Orange
    • Prenota
    • Cioccolato
  • L'utente aggiungerebbe una o più istanze sopra gli elementi in un BASKET.

Da saggezza convenzionale ho deciso di rappresentare questa struttura in DB relazionale come segue:

  • Crea tabelle individuali per ARANCIONE, PRENOTA, CIOCCOLATO e CARRELLO.
  • E creato una tabella di mappatura tra sopra con BASKET.

Questo funziona fin qui bene. Ecco il problema

Una volta che l'utente salva il carrello, al momento del checkout il negozio imporrà alcune regole / sconti che sono impostati per uno scenario individuale, ad esempio:

  • Se il carrello dell'utente ha 2 arance, non può effettuare il checkout dei cioccolatini a forma di ROUND.
  • Se il cesto di checkout degli utenti tra le 10 e le 12 non gli è consentito il checkout dei libri dall'autore: Dan Brown.
  • E alcune altre regole, puoi vedere dove sto andando con queste.

L'utente non sarà a conoscenza di queste regole sopra al momento dell'aggiunta degli articoli nel carrello. Ma queste regole sono imposte al momento del pagamento.

Il mio problema è COME e DOVE dovrei memorizzare queste regole? Non riesco a codificarli con difficoltà nell'applicazione. Devono essere conservati da qualche parte come linee guida per il cassiere al momento del pagamento.

Non sono sicuro di poter articolare correttamente il problema, ma l'ho semplificato il più possibile.

Se qualcuno ha delle soluzioni per favore fammelo sapere.

    
posta Kishor Prakash 28.03.2018 - 23:52
fonte

1 risposta

2

Considera di avere una tabella Rule . Per ogni riga in una tabella Rule , hai una riga in RuleCondition , una riga in RuleAction e n righe in RuleParameters .

RuleCondition descrive le condizioni per cui viene attivato il RuleAction . Ad esempio, se il tempo è tra le 10 e le 12, o il cesto cassa contiene 2 arance. RuleCondition contiene anche il nome della classe che implementa questa condizione della regola.

RuleAction descrive l'azione da eseguire quando RuleCondition è true. Questo potrebbe essere qualsiasi cosa dall'invalidare il checkout alla semplice rimozione degli articoli dal checkout. RuleAction contiene anche il nome della classe che implementa questa azione della regola.

RuleParameters , con una chiave esterna per la regola, è una tabella many-to-one contenente tutti i parametri con nome relativi a questa regola specifica . Ad esempio, per evitare di avere un RuleCondition per ogni possibile periodo di tempo, per le condizioni delle regole che richiedono un tempo di inizio e fine, in RuleParameters , potresti creare due parametri con nomi startTime e endTime . L'implementazione di RuleCondition verrebbe assegnata alla lista di tutti i parametri e l'effettiva implementazione di RuleCondition userebbe i parametri di cui ha bisogno. Applica la stessa possibilità anche a RuleAction .

Dovresti creare una classe RuleEngine che carichi tutte queste regole e applichi ogni azione della regola il cui RuleCondition sia soddisfatto durante il checkout.

Da lì il cielo è il limite. Mi aspetto che ci siano molte regole e RuleParameters , ma non così tanti RuleConditions o RuleActions come sarebbero parametrizzati. Se carichi queste regole ad ogni checkout o ogni 5 minuti circa, puoi applicare le modifiche al volo. Potrebbe anche essere fornita un'interfaccia, consentendo al client di eseguire le modifiche secondo necessità.

Inoltre, se posso fare un piccolo consiglio, probabilmente non dovresti avere un tavolo per ogni possibile oggetto. Anche se è vero che hanno i propri dati relativi ad esso, si potrebbe facilmente avere una tabella Product con% coppie chiave / valore% co_de con tutte le informazioni richieste per quel prodotto. O anche una soluzione ibrida con ProductInfo tabella con chiave esterna a Produce tabella contenente tutto ciò che è specifico per produrre prodotti, consentendo di liberare un po 'di Product .

    
risposta data 29.03.2018 - 09:19
fonte