Qual è lo schema MySQL più elegante per prodotti, opzioni e categorie?

Question

Ho lavorato con una dozzina di sistemi di template (Zen Cart, Cube Cart, ecc.). Ognuno di questi ha il proprio modo bizzarro di strutturare prodotti, opzioni e categorie. Tutte le funzionalità aggiuntive determinano una situazione di pila di carte di McGuyver che rende il lavoro con il codice una resistenza totale.

Così, sei anni fa ho costruito il mio motore di webstore, che si è evoluto nel corso degli anni e si è trasformato in un proprio mazzo di carte. Ora sto facendo una revisione totale del motore. Mentre nessuno motore sarà soddisfare tutte le esigenze Webstore, mi chiedevo se il seguente modello ha svantaggi, o se c'è un modo migliore per creare un, normalizzato, di database non antipatico flessibile per il commercio:

Note:
option_types = colori, dimensioni, materiali
options = rosso, bianco, blu, S, M, L, cotone, spandex, cuoio

Altro che roba di base omesso di proposito (posizione, attiva, ecc .), qualcuno vede un modo per migliorare questo?

Answer 1

Ecco i miei appunti/opinioni su questo. Ti mancano le cardinalità, ma farò del mio meglio per indovinarle.

• Categories è ok.

• Rimuovereda item_categories come non lo si utilizza. Crea una chiave primaria composita su ID_categoria e id_articolo.

dando ogni record un ID univoco è più intelligente in molti modi: più veloce per ricerca su un campo che su due, più sicuro per eliminare, ecc

Cosa ricerca faresti su quell'id? Le domande che eseguirai sono: "Ottenere tutte le categorie per un oggetto" e "Ottenere tutti gli oggetti per una categoria". Non capisco perché sarebbe più sicuro da cancellare. Tuttavia, direi che aggiungere id potrebbe non essere sicuro da inserire in quanto potresti avere id diversi ma le stesse coppie category_id e item_id. Dovrete verificare i vincoli lì e assicurarsi che le coppie sono uniche (e non sono che ciò che PK sono utilizzati per?)

• items è ok ... (vedi commenti qui sotto)
• Rimuovere id da item_options (stesso caso come sopra e vedere commenti qui sotto)
• option_types è ok

Ora, credo che le voci modo e le opzioni sono correlate richiederà più pensare. Sembra essere una relazione molti-a-molti. Come un oggetto, come una T-Shirt può avere molte dimensioni, ha senso dire che ogni coppia di oggetti e opzioni dovrebbe avere una dimensione diversa. Ma cosa succede quando, a parte le dimensioni, hai anche un materiale diverso, come il cotone e la pelle. Dovrai avere informazioni sulle coppie cotone-S, cotone-M, cotone-L e pelle-S, pelle-M e pelle-L. Questo ha senso perché sono abbastanza sicuro che tutti avranno un prezzo e un peso diversi. Ma ora aggiungiamo 2 colori alle nostre T-shirt. Dovrai aggiungere un prezzo e un peso per ciascuna delle 12 combinazioni che avremo ora.

Senza contare che se un utente desidera vedere il prezzo di un articolo dovrà scegliere tutte le opzioni fino a quando non avrà raggiunto un prezzo. Non sono sicuro di come dovrebbe essere fatto perché non sono a conoscenza dei requiremets. Sto solo lanciando un'idea: potresti applicare prezzi e variazioni di peso oltre un prezzo base e un peso che sarebbe parte dell'articolo.

Solo alcuni pensieri non trasformati prima di andare a dormire:

• option_types potrebbe essere una sorta di gerarchia
• riflettere attentamente su come si dovrebbe gestire stock dato che il design. Avrai 10 articoli per una maglietta nera ... ma quanti articoli avrai per una t-shirt di pelle nera? In che modo quel numero è correlato ai 10 originali?

Answer 2

Tabella delle opzioni Vorrei aggiungere un valore sotto il nome. vale a dire Nero L Nero M Nero S Blu L Blu M Blu S ecc come spin off all'idea di Mosty.