A mio avviso, puoi risolverlo in due modi:
La categoria è un tipo speciale di prodotto
Ciò significa che per ogni dato prodotto nel database, contiene una chiave esterna che punta allo stesso prodotto tabella. Un prodotto è un prodotto solo se non esistono prodotti la cui chiave esterna è uguale all'ID di detto prodotto. In altre parole, se non contiene prodotti, è un prodotto.
Ciò semplificherebbe un po 'le cose. I prodotti per le proprietà avrebbero una relazione uno-a-molti e quindi anche le tue categorie hanno una relazione uno-a-molti in quanto sono anche prodotti. Aggiungere una proprietà a una categoria sarebbe facile come aggiungere una proprietà a un prodotto nel tuo programma. Caricare tutte le proprietà significherebbe combinare le proprietà del prodotto con le proprietà del prodotto della categoria associata e fino a raggiungere un prodotto della categoria senza parent.
La tua applicazione di e-commerce dovrebbe fare questa distinzione, ma se è probabile che tu carichi comunque prodotti di una categoria, non è una perdita di prestazioni sapere se hai a che fare con una categoria o un prodotto. Si presta anche bene alla ricerca nella struttura ad albero a livello di prodotto poiché ogni prodotto (categoria) si aprirà a un elenco di sottoprodotti senza molto lavoro aggiuntivo.
Il rovescio della medaglia di questo è ovviamente l'informazione extra presente nel prodotto che non ha senso per una categoria creerebbe campi inutilizzati imbarazzanti nel prodotto. Sebbene questa soluzione sia più flessibile nella tua applicazione, è anche un po 'meno intuitiva.
Rapporto molti-a-molti
I prodotti non hanno più una relazione composita con la proprietà. Si crea una tabella ProductProperty con chiavi esterne sia della tabella dei prodotti che della tabella delle proprietà che collegano i due. Allo stesso modo, si dispone di una tabella delle categorie con una relazione molti-a-molti con la tabella delle proprietà e una tabella CategoryProperty con chiavi esterne sia della tabella delle categorie che della tabella delle proprietà.
Il prodotto stesso avrebbe una relazione molti-a-uno con la categoria, consentendo in sostanza di creare un elenco di proprietà uniche relative sia al prodotto che alla categoria attraverso un'istruzione select ben formalizzata.
Dal punto di vista del database, questo è decisamente più pulito e flessibile. La tua applicazione potrebbe probabilmente funzionare per la maggior parte senza occuparsi direttamente di CategoryProperty o ProductProperty se la query viene eseguita correttamente. Tuttavia, non dovresti trattare la categoria o il prodotto come proprietario della proprietà. Dovrebbe essere una sua entità all'interno del tuo programma. Ciò significa anche che la gestione di dette proprietà sarebbe una questione di creazione della proprietà stessa, quindi di associazione con una categoria o un prodotto in due fasi separate. Certamente più lavoro rispetto alla prima soluzione, ma non è affatto più difficile.
Oltre a questo, dovresti anche eseguire un controllo aggiuntivo alla cancellazione della categoria o del prodotto se una delle sue proprietà viene utilizzata da altri (a differenza della prima soluzione in cui potresti eliminare in modo sicuro tutte le proprietà associate di un determinato prodotto / categoria) .
Conclusione
In un contesto professionale, farei il miglio in più e la categoria di distanza dal prodotto e il prodotto dalla proprietà usando l'approccio molti-a-molti. Non vi sarebbe alcuna possibilità di sovrapposizione di dati e, in un certo senso, è più facile ragionare su ognuna di queste tre come una propria entità. Tuttavia, la prima soluzione non è affatto una cattiva in quanto consente anche di scrivere un'applicazione più semplice. Sappi solo che se pensavi di dover eventualmente passare da una soluzione all'altra, probabilmente sarebbe nel tuo interesse scegliere la seconda.
In bocca al lupo!
