Newsgroup: it.comp.www.php
Titolo: [OT] MySQL e tabella prodotti

Salve,
 
una curiosità, dovendo far creare un db per inserire vari prodotti con 
diverse caratteristiche tra loro (quelle comuni sarebbero solo il 20% 
del totale dei campi come prezzo, dimensioni, e pochi altri campi) 
secondo voi sarebbe meglio fare creare due diverse categorie prodotti 
ovvero due diverse tabelle prodotti?
 
Saluti!
GabrieleMax


Visto che è una "curiosità"..
 
Dipende dal tuo caso, ovviamente, ma di solito no, i prodotti vanno in una
tabella prodotti, le categorie in una tabella categorie e le caratteristiche
di ogni prodotto in una tabella attributi.
 
Oltretutto...
Dici che i field in comune sarebbero solo il 20%, solo mettendo prezzo,
dimensioni, nome, descrizione e data, che son 5, vorrebbe dire che ci sono
20 "caratteristiche" per almeno una classe di prodotti. Che razza di
prodotti sono? Sicuro che li hai contati bene? Che ci devi fare con tutti
questi campi che non puoi mettere nella generica "descrizione"?
 
Ciao!

 Ciao!
 
Saluti!
GabrieleMax
 

 rimarrebbe senza valore...
 
In questo caso non sarebbe la tabella prodotto ad avere FK, ma le varie 
tabelle varianti ad averne una verso la tabella prodotto.
 
Dovrai essere tu poi a gestirti la query in base al tipo di prodotto.
 
Per esempio:
 
insert into prodotti (id, nome, tipo) values (1, 'Ciccio', 'tavolo');
 
insert into prodotti (id, nome, tipo) values (2, 'Nonna Papera', 'sedia');
 
 
insert into prodotti_tavolo (tavolo, variante) values (1,'ripiano');
 
insert into prodotti_tavolo (tavolo, variante) values (1,'gambe');
 
insert into prodotti_tavolo (tavolo, variante) values (1,'colore');
 
 
insert into prodotti_tavolo_ripiano (tavolo, nome) values (1, 'vetro');
 
insert into prodotti_tavolo_ripiano (tavolo, nome) values (1, 'legno');
 
insert into prodotti_tavolo_ripiano (tavolo, nome) values (1, 'titanio');
 
 
Questo è un modo. Un altro potrebbe essere:
 
insert into prodotti_tavolo (tavolo, variante, nome) 
values (1,'ripiano','vetro');
 
insert into prodotti_tavolo (tavolo, variante, nome) 
values (1,'ripiano','legno');
 
insert into prodotti_tavolo (tavolo, variante, nome) 
values (1,'ripiano','titanio');
 
 
Oppure, appunto usando MongoDB:
 
db.prodotti.insert({
 'nome': 'Ciccio',
 'tipo: 'tavolo',
 'varianti': {
  'ripiano': [
    'vetro',
    'legno',
    'titanio'
  ],
  'gambe': [
   ...
  ]
 }
});
 
Poi naturalmente sta al tuo software riconoscere il campo tipo e caricare 
il configuratore apposito.
 
Bye.
 
P.S.: Se usi MongoDB ti consiglio di gestire disponibilità, carrello e 
checkout con un DB SQL, per via dell'integrità referenziale e delle 
transazioni, che Mongo non ha.

 
 
Con la struttura di cui sopra, qualcosa del tipo:
 
prodotto(id, nome, descrizione, etc.)
attributo(id, nome, tipo)  -- il "template" di un attributo
prodotto_attributo(fk_prodotto_id, fk_attributo_id, valore)  -- il valore per
    lo specifico prodotto
gruppo_attributi(id, fk_attributo_id)
prodotto_has_gruppo_attributi(fk_prodotto_id, fk_gruppo_attributi_id)
 
ovviamente cambiando a piacere in base al problema reale, ma questo è come
più o meno fanno tutti i software che gesticono prodotti (e che non fanno uso
di varianti prodotto, caso in cui c'è bisogno un altro layer composto da
una o due tabelle "variante")
 
Ciao!


 
Questo è il motivo per cui io, personalmente, MongoDB non lo prendo mai
nemmeno in considerazione per questo tipo di problema (e anche per quasi
tutti gli altri di problema, se è per questo) :)
 
Ciao!

 tutti gli altri di problema, se è per questo) :)
 
Dipende, naturalmente, dal tipo di problemi che hai. :)
 
Io credo che semplicemente molta gente sia ancora legata al modo di 
pensare relazionale di SQL, e non conosca abbastanza Mongo da usarlo anche 
nei casi in cui è enormemente migliore. 
 
Soprattutto di MySQL. :D
 
Bye.

prodotto_has_gruppo_attributi(fk_prodotto_id, fk_gruppo_attributi_id)
 
non ho capito perche'  "gruppo_attributi(id, fk_attributo_id)", non
dovrebbe essere gruppo_attributi(id, attributo) ? 
 
 

 Bye.
 
Saluti!
GabrieleMax
 

 non va di la, non va di su, non va di giu'...
 
Cambia immediatamente programmatore.
 
 

 non va di la, non va di su, non va di giu'...
 
Il programmatore non ha capito la domanda. Prova a rifargliela in VB6.
:)
 
-- 
@WarpTen10
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

> Cambia immediatamente programmatore.
 
Il problema è che LUI è un programmatore ed IO no anche se il database 
in MySQL gliel'ho progettato io (...) ed in termini economici LUI 
costava meno del progetto completo L.A.M.P. che però sarebbe stata la 
soluzione a tutte le esigenze!

 :)
 
Bella questa! :D Come già accennato nell'altro post vi erano dietro 
anche discorsi economici però imho spendere 2 e non risolvere tutti i 
problemi a fronte di una spesa di 3 che li avrebbe risolti tutti e pure 
in maniera migliore...
 

 insert into prodotti_tavolo_ripiano (tavolo, nome) values (1, 'titanio');
 
Bene, idea interessante, grazie! :)
 
Saluti!
GabrieleMax
 


Certo, ma i casi in cui è enormemente migliore non capitano praticamente
mai. I NoSQL servono quando hai tantissimi dati e se te perdi qualcuno fa
lo stesso: unito all'assenza di consistenza, direi che in vita mia di questi
casi ne avrò visti una manciata. Al contrario, ho visto spesso usare questo
tipo di DB a sproposito e poi smadonnare per problemi che non si sarebbero
dovuti presentare in primo luogo :)
 
Ciao!


L'ho scritto un po' al volo, forse non ho tradotto bene il concetto in
tabelle - riscrivo le relazioni, che si fa prima :)
 
prodotto (1-N) gruppo-attributi
gruppo-attributi (1-N) attributo
prodotto (M-N) attributo
 
certo con uno schema si vede subito, per mail in poche righe è più complesso,
ma basta carta, penna e pensarci un secondo ;)
 
Ciao!

 ha scritto:

Ora però la situazione attuale costa molto di più che passare
ad un progetto completo L.A.M.P. quando c'era la possibilità.
 
Ergo il consiglio si evolve:
 
Cambia immediatamente programmatore *E* passa a L.A.M.P.
 
;-)
 
 

 unito all'assenza di consistenza, 
 
Non ha assenza di consistenza. Mancano solo per transazioni e l'integrità 
referenziale, che comunque il 99% dei siti web nemmeno usa.
 
La consistenza è eventuale, nel senso che se hai un cluster, a meno di non 
dirgli "non tornare dalla insert finché tutto il cluster non è 
aggiornato", i client connessi a parti del cluster che vengono aggiornate 
in differita non avranno i dati in tempo reale, ma magari con 5 secondi di 
ritardo (dipende dalla rete e dalla config).
 
D'altra parte, invece, con MongoDB hai un cluster "multi-master", che 
MySQL si sogna e PostgreSQL ottiene solo smadonnando e probabilmente 
pagando.
 
Per questo consiglio di usare un SQL solo quando hai veramente bisogno di 
transazioni (o hai i dati strutturati in modo da entrarci a pennello).
 
Bye.

 
 
Ma anch'io! :D
La differenza è, si vede, quando pensiamo che le transazioni e la
integrità referenziale sia "fondamentale": per me, praticamente sempre :)
 
Io userei MongoDB per cose tipo collezione di dati statistici, secondo me
per quello calza a pennello.
 
Ciao!

 me per quello calza a pennello.
 
Io invece li metterei in Hadoop, avendo l'hardware disponibile, che 
gestisce meglio la parte "faccio l'analisi mentre sto ancora ricevendo 
migliaia di scritture al secondo". Anche se dovrei tapparmi il naso per 
Java. :)
 
Altrimenti sì, MongoDB è abbastanza buono, anche se è un po' più "manuale" 
da gestire in questo scenario.
 
Bye.

 
 
Grazie per aver citato Hadoop, non lo conoscevo proprio(**)! Ci darò uno
sguardo questa sera stessa ;)
 
Ciao!
 
 
 
(*) nel caso di failure del FS, il DBMS mi deve saper dire se i dati sono,
per la definizione di cui sopra, consistenti o meno. Non voglio girare con
un disco rotto e un DBMS che non mi dice nulla...
(**) Questo per curiosità personale, se hai-voglia-di/puoi rispondermi:
dov'è che lavori adesso che hai bisogno di gestire tutta questa quantità di
dati? Io attualmente lavoro in una società di ads e, anche se non posso
dire la cifra precisa, di impressions/clicks monitorati al giorno ce ne sono
a sfinire (molti più di quando lavoravo sul porno, dove stavamo sui 10K
accessi al min), e un MySQL va alla grande..

tabelle - riscrivo le relazioni, che si fa prima :)
non era assolutamente mia intenzione puntare il dito su un eventuale
errore. Con l'sql sono gnucco e faccio sempre fatica ad afferrare le
cose. Non ho mai dedicato tempo a studiare la parte teorica e appena
le cose si complicano un po' mi arrampico sempre sugli specchi.
 
Grazie.
Ciao.

 
 
Beh, sul problema in oggetto mi son limitato a scrivere la struttura "solita"
usata da quasi tutti i software famosi, che mi sembra aver senso. Quindi
non c'è molto da inventare, al massimo cercare di capire perché quasi tutti
decidono di fare in quel modo.
 
Per quanto riguarda la progettazione di database, anch'io ho avuto sempre
problemi fino al -che anno era- mi sa 2002/2003.
 
<storymode>
La "teoria" la conoscevo tutta (avevo anche scritto un piccolo DBMS da zero,
ricordo ancora notti intere passate ad ottimizzare il mio B*-tree, beata
innocenza..). Comunque, all'epoca lavoravo per una piccola azienda che tirava su software intranet per la Italtel, e tutto girava sopra dei DB Oracle coi
peli.
Una sera dovevo ottimizzare delle query, cosa che succedeva spesso, visto che
lì una query fatta male poteva metterci più di un minuto, contro i millisecondi
soliti di quelle fatte a modo, e la query più scema andava su join di non meno
di 10/15 tabelle (tutto era sul DB) - mi si friggeva la testa.
Mi s'è messo vicino un collega, della mia stessa età, laureato in matematica,
e m'ha detto: "guarda, di quello che programmate voi non capisco nulla, ma
questa roba è una stron**ta. Son solo insiemi! Che dati devi tirar fuori?"
E, presa carta e penna: "Questo è questo intersecato quest'altro meno quel
coso lì.." e giù via di semplificazioni. In meno di dieci minuti avevamo
tutte le query che giravano da Dio.
In quel momento, oltre a dubitare della mia eterosessualità, ho capito come si
usa un DB relazionale. Non c'entrava nulla né con quello che m'avevano
insegnato né col mindset che usavo per programmare. Ed era incredibilmente
facile..
</storymode>
 
Magari prima o poi trovi anche te l'illuminazione, sempre che non passino
tutti a MongoDB prima! :D
 
Ciao!


 
quando mi capita di dover spiegare come funziona un DB relazionale 
utilizzo la teoria degli insieme e faccio giocare con "indovina chi"
 
Ciao
 
 

 stavamo sui 10K accessi al min), e un MySQL va alla grande..
 
Facciamo aggregazione di CV e tutta una serie di analisi sugli stessi, per 
i recruiter. Attualmente usiamo Mongo e Elasticsearch.
 
Con Hadoop (e Scala) ho avuto a che fare (troppo poco, purtroppo) dove 
lavoravo prima, e lì viene utilizzato per raccogliere dati statistici sui 
videogiochi, a ritmo di qualche migliaio al secondo ("partita iniziata", 
"livello raggiunto", "arma trovata", "nemico sconfitto", ecc. ecc.)
 
MySQL va bene per ricevere i dati, con una buona configurazione riesci a 
fare parecchio, ma quando devi analizzarli è una rogna e le prestazioni 
vanno a farsi benedire, oppure devi provvedere a partizionarli manualmente 
(tra tabelle o tra server diversi).
 
Ci avevamo provato dove lavoravo ancora prima (mail marketing e 
retargeting) e proprio non ce la faceva. In quel caso stavamo passando a 
Mongo. Avevo preparato la struttura del DB, lo script in js per la 
raccolta dati e alcune funzioni di analisi, poi ho cambiato lavoro. :D
 
Bye.
 


 
Kudos! :)
 
Ciao!