architettura del database per l'app di e-commerce

0

Sto creando un'app che consente a users di pubblicare, vendere e acquistare items . Ogni item ha un attributo intero count impostato dall'iniziale user e che viene ridotto di n con ogni acquisto. Quando count è 0, quel item non può più essere venduto a meno che uno dei precedenti user compratori riporti il item acquistato: nel qual caso, il nuovo item eredita tutte le proprietà dell'originale item eccetto price , che è determinato dal nuovo user proprietario e count , che è determinato da quanto count hanno acquistato nella transazione iniziale.

Al momento ho due colonne del database: items e users . Dovrò registrare transazioni e trasferimenti di proprietà fino a quando sul sito esiste un item , quindi ciò significa che ho bisogno di una terza colonna per transactions . Di cos'altro avrei bisogno e cos'altro dovrei ricercare? L'ereditarietà della tabella standard è utile per questo tipo di funzionalità?

Devo eliminare l'intero approccio count ? Sarebbe un enorme trascinamento sul database se avessi creato un nuovo oggetto per ogni [i] in count ? Quindi, dì che user imposta count a 10.000 e ho fatto in modo che l'app creasse tanti singoli oggetti di database per ogni item pubblicato. E poi dici che ci sono migliaia di persone che fanno la stessa cosa allo stesso tempo con il loro items .

Molto nuovo per lavorare con la progettazione del database e non so dove altro chiedere, quindi apprezzo molto il tuo feedback.

    
posta sabaeus 17.07.2016 - 03:38
fonte

1 risposta

2

Questo è un tipico problema di gestione dell'inventario.

Il modo in cui lo gestisci dipende da come gestisci fisicamente lo spazio pubblicitario. Se ciascun articolo (non SKU, ma articolo) ha un numero di serie univoco, è possibile che si stiano monitorando istanze di articoli specifici.

Più probabilmente, riceverai una scatola dell'elemento (widget, per esempio) e incrementerai l'inventario a disposizione del conteggio nella casella, forse 24. Ogni transazione di vendita riduce l'inventario a disposizione del numero venduto.

La mia regola è: mantienila semplice, ma mantienila reale. Se hai più magazzini in fusi orari diversi o cose del genere, hai un problema più complicato. Se hai un singolo magazzino, la vita è più semplice: aggiungi solo num_on_hand o simile all'entità item . (Non utilizzare count poiché si tratta di una parola chiave SQL, tra le altre ragioni).

Questo è un buon caso in RoR per una transazione; effettua il decremento della parte num_on_hand della transazione add to cart o checkout . Non dimenticarti di cose come aggiustamenti (ad esempio inventario di fine anno), rotture, resi e tutte le altre cose che sono transazioni ma che potrebbero cambiare o meno l'inventario.

Vorrei anche sottolineare che questo è un problema che è stato risolto innumerevoli volte, ed è solo uno dei tanti problemi che riguardano la gestione dei contenuti, la gestione dei negozi, ecc. È questo software che vuoi davvero scrivere da solo, oppure Esiste un bel gioiello o uno strumento che puoi usare per gestire questo problema complesso in modo più semplice, in modo che la tua azienda possa arrivare al problema di fare ciò che è buono a, come vendere roba: -)

    
risposta data 28.07.2016 - 02:23
fonte

Leggi altre domande sui tag