Progettazione ortogonale per la determinazione del prezzo del prodotto e la pianificazione della produzione con un database NoSQL [chiuso]

2

Sono in procinto di sviluppare software estensibile per la società con cui lavoro per la determinazione del prezzo e la pianificazione della produzione.

Lo scenario attuale

Esistono fondamentalmente due tipi di prodotti: fabbricati e scambiati (semplice acquisto e vendita senza conversione). Prodotto può essere regolare o fatto su ordinazione con il fatto su misura per lo più essendo un deviante del modello normale. Esiste solo un numero finito di prodotti (circa 2000), ma ogni prodotto ha attributi multipli come dimensioni, colore, sfumature e altro. Attualmente, vi è un software per la gestione degli ordini con inventario e un pacchetto contabile decente. Il calcolo dei costi e dei prezzi viene ora effettuato su base arbitraria tramite il campionamento di alcuni modelli e l'aggiunta di spese generali e percentuali di margine.

Obbligatorio

  • Per calcolare il costo del prodotto per unità
  • Convertili in un modello di prezzo valido (i prezzi possono variare in base alla quantità e ad altri fattori),
  • Calcola il costo esatto e la redditività per prodotto,
  • Pianifica in modo proattivo la produzione di modelli regolari e unità su commessa, in base al sistema di gestione degli ordini esistente e all'inventario

Design proposto

Ho proposto il seguente design.

  • Memorizza le informazioni sul prodotto per ciascun prodotto unico in stile documento in base ai 5 milioni di produzione (Uomo, materiale, macchine, metodi e denaro)
  • Un modulo separato di ciascuna delle quattro M - Uomini, Macchina, Materiale e Metodi in termini di denaro con blocchi elementari primitivi per ogni modulo che possono essere uniti e combinati in un blocco composto
  • Memorizza i metadati e il set di risultati richiesti insieme a ciascun documento
  • Un livello separato per analizzare i metadati, agire sui dati in base ai metadati e impostare i risultati di ritorno come definiti (simile a un DSL con metadati e set di risultati ridefiniti in fase di runtime)
  • Un modello di determinazione dei prezzi separato che funziona sul costo del prodotto
  • Un modulo di pianificazione della produzione separato che funziona sui dati del sistema di gestione degli ordini e le informazioni sul prodotto
  • Utilizzare MapReduce per aggregare i dati e analizzarli
  • Tecnologie: MongoDB , Python, Django e NumPy

Tutti i dati da memorizzare in formato JSON con tutta la logica aziendale scritta per analizzare un file JSON (tecnicamente, nel mio caso un dizionario Python) e produrre output basato su chiavi e valori.

Allora, perché sono qui?

La presente azienda di software ha raccomandato un sistema RDBMS pronto all'uso che può essere personalizzato. Il problema principale che riscontro nel sistema è la duplicazione dei dati per prodotti con attributi diversi, mancanza di strumenti analitici, accoppiamento stretto con prodotti e prezzi e troppi join per query complesse, ma è consigliato per una maggiore robustezza e una migliore analisi aggregata e il XXXX ha sempre detto al mercato che gestisce questo approccio. Poiché l'intero software non deve essere utilizzato in tempo reale e gran parte dei collegamenti di sistema in tempo reale solo a prodotti unici.

  • Il mio progetto proposto è veramente ortogonale?
  • Il prodotto incoerente, i costi e i prezzi funzionano?
  • Qual è l'approccio generale per questo tipo di problema?
  • MapReduce fornisce un modo migliore di analizzare i dati per questo tipo di problemi (insieme a NumPy) rispetto all'approccio SQL tradizionale

Fondamentalmente lavoro con i numeri e sto pensando a un modello generico che potrei estendere in futuro.

    
posta Ubermensch 17.12.2011 - 08:05
fonte

1 risposta

2

Probabilmente troverai strumenti migliori e (più importante) esperti di soluzioni basate su RDBMS rispetto a quelli basati su NoSQL. In genere, è necessario considerare la soluzione basata su NoSQL quando si iniziano a colpire i limiti delle prestazioni (ad esempio quantità di memoria, numero di query al secondo).

Quasi tutte le soluzioni NoSQL allentano i requisiti di coerenza, disponibilità o tolleranza delle partizioni (vedi Teorema CAP ) e dovrai gestirlo nella logica dell'applicazione. IMO, dovresti astenervi da questa complessità a meno che non si stiano veramente raggiungendo i limiti RDBMS.

    
risposta data 17.12.2011 - 08:38
fonte

Leggi altre domande sui tag