Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20317 > unrolled thread

[OT] MySQL e tabella prodotti

Back to article view | Back to it.comp.www.php

Contents

  [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-10 14:48 +0100
    Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-10 06:00 -0800
      Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-10 21:01 +0100
        Re: [OT] MySQL e tabella prodotti Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-10 20:21 +0000
          Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-10 12:42 -0800
            Re: [OT] MySQL e tabella prodotti Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-11 08:23 +0000
              Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-11 13:52 +0100
                Re: [OT] MySQL e tabella prodotti "ciccio" <21669invalid@mynewsgate.net> - 2016-02-11 13:58 +0000
                  Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-12 13:57 +0100
                    Re: [OT] MySQL e tabella prodotti "ciccio" <21669invalid@mynewsgate.net> - 2016-02-12 19:03 +0000
                Re: [OT] MySQL e tabella prodotti Warp10 <warp10@libero.it> - 2016-02-11 15:10 +0100
                  Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-12 14:02 +0100
              Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-12 06:53 -0800
                Re: [OT] MySQL e tabella prodotti Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-13 18:09 +0000
                  Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-13 12:30 -0800
                    MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-13 21:03 +0000
                      Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) fmassei@gmail.com - 2016-02-13 14:01 -0800
                        Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-16 08:25 +0000
                          Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) fmassei@gmail.com - 2016-02-21 21:27 -0800
          Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-12 14:07 +0100
        Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-10 12:38 -0800
          Re: [OT] MySQL e tabella prodotti leo <leofante_XNOSPAMX_@gawab.com> - 2016-02-11 11:45 +0100
            Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-12 06:59 -0800
              Re: [OT] MySQL e tabella prodotti leo <leofante_XNOSPAMX_@gawab.com> - 2016-02-15 10:40 +0100
                Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-15 11:26 -0800
                  Re: [OT] MySQL e tabella prodotti bramante <bramante@yopmail.com> - 2016-02-16 01:58 +0100

Page 1 of 2  [1] 2  Next page →

#20317 — [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

[toc] | [next] | [standalone]

#20318

On Wednesday, February 10, 2016 at 8:47:45 AM UTC-5, GabrieleMax wrote:
> 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?
> 

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!

[toc] | [prev] | [next] | [standalone]

#20319

> Visto che è una "curiosità"..

Esatto, intanto ti ringrazio per la risposta, non faccio il 
programmatore per lavoro però qualcosina so fare e dovendo far fare il 
lavoro vero a terzi mi piace capire e ragionare se le soluzioni che 
verranno adottate saranno concettualmente le migliori sapendo ovviamente 
che in questo ambito si può andare da "A" a "B" prendendo diverse strade 
e tutte fattibili!

> 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.

Ok, anche in passato tutti e sottolineo tutti quelli a cui feci una 
domanda simile mi scrissero la stessa cosa che mi indichi tu ovvero il 
creare una tabella prodotti unica!

> 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"?

Varianti di colore, materiale, accessori ed utilizzo, ad esempio  un 
tavolo può essere in legno o cristallo, avere il piano in laminato o 
vetro, essere per 2 o 4 o 6 persone e cosi' via mentre una sedia a 
livello descrittivo e di utilizzo ha discriminanti diverse rispetto ad 
un tavolo altro discorso ancora per una lampada!

Se devi fare un configuratore devi avere poi tutti campi separati vedi 
dimensioni, colori, materiali, etc, non puoi mettere tutti in un 
generico campo descrizione...

Ora mi chiedo cosa mettere nella tabella prodotti? Un codice prodotto 
univoco associato al marchio (potrebbero esserci codici uguali ma 
associati a marche diverse).

Quindi la tabella prodotti avrebbe "Codice prodotto" e tutti i restanti 
campi sarebbero delle FK verso tabelle esterne, quando un determinato 
prodotto non ha una caratteristica potrei dargli il valore di NULL ad 
esempio una sedia in corrispondenza del campo "tipologia_piano" 
rimarrebbe senza valore...

> Ciao!

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#20320

Il Wed, 10 Feb 2016 21:01:35 +0100, GabrieleMax ha scritto:

> Varianti di colore, materiale, accessori ed utilizzo, ad esempio  un
> tavolo può essere in legno o cristallo, avere il piano in laminato o
> vetro, essere per 2 o 4 o 6 persone e cosi' via mentre una sedia a
> livello descrittivo e di utilizzo ha discriminanti diverse rispetto ad
> un tavolo altro discorso ancora per una lampada!

Avendo prodotti fisici e non immateriali (come possono essere software o 
simili), devi gestire anche le rimanenze/disponibilità per ognuno.

In questo caso puoi fare un "prodotto master" (il tavolo) e una serie di 
prodotti collegati. Il prodotto master può essere una categoria con un 
flag speciale o, se tutti i tuoi prodotti sono configurabili, una "tabella 
intermedia" (cioè avrai categorie-prodotti-varianti).

Se sei un fabbricante, e i prodotti li puoi fare senza limiti (utopico, ma 
mettiamo il caso :) potresti anche avere un singolo prodotto, e salvare le 
varianti in un campo "text" con dentro un JSON.

Un'alternativa è staccarsi dai DB SQL e andare, per esempio, su MongoDB, 
in cui avrai un documento "tavolo" con dentro tutte le caratteristiche e 
le varianti.
 
> Quindi la tabella prodotti avrebbe "Codice prodotto" e tutti i restanti
> campi sarebbero delle FK verso tabelle esterne, quando un determinato
> prodotto non ha una caratteristica potrei dargli il valore di NULL ad
> esempio una sedia in corrispondenza del campo "tipologia_piano"
> 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.

[toc] | [prev] | [next] | [standalone]

#20322

On Wednesday, February 10, 2016 at 3:21:11 PM UTC-5, Alessandro Pellizzari wrote:
> <snip>
> Un'alternativa è staccarsi dai DB SQL e andare, per esempio, su MongoDB, 
> in cui avrai un documento "tavolo" con dentro tutte le caratteristiche e 
> le varianti.
> <snip>
>
> 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.
>

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!

[toc] | [prev] | [next] | [standalone]

#20323

Il Wed, 10 Feb 2016 12:42:35 -0800, fmassei ha scritto:

> 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) :)

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.

[toc] | [prev] | [next] | [standalone]

#20326

> 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.

Diciamo che in generale i programmatori non vedono di buon occhio il 
"cambiare strada", ti faccio un esempio di quanto accaduto nell'azienda 
in cui lavoro, necessità di un database aziendale che gestisse 
matricole, prodotti, materiale, etc. sia internamente che esternamente 
per i tecnici che fanno assistenza onsite e devono movimentare 
matricole, modelli, etc.

In che modo tu avresti tradotto la carta ed i fogli di excell? Pensaci 
qualche secondo... pensaci ancora e dopo ti scrivo qual'è stata la 
soluzione del programmatore da me da subito criticata.

Gestionale fatto con un software Buffetti, tutti i client windows hanno 
un *.exe che una volta aperto ha delle schermate che dialogano con SQL 
Server Microsoft.

Ovviamente da remoto su smartphone, tablet, etc. non è possibile 
accedere al database e quindi si usa la carta e poi la carta deve essere 
ritrascritta per cosi' dire sul software che gira solo in lan.

Risposte del programmatore alle mie domande di attivazione di un 
L.A.M.P.? "Ah ma non è sicuro un webserver, non va bene, non va di qua, 
non va di la, non va di su, non va di giu'...

> Soprattutto di MySQL. :D

Leggevo tempo fa i confronti tra Postgree e MySQL, forse alla fin fine 
anche qui si va di prassi poi imho il 90% dei progetti non avrebbero 
sostanziali migliorie nell'adottare una soluzione diversa...

> Bye.

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#20327

GabrieleMax <gabriele1NOSPAM@hotmail.com> ha scritto:

CUT
> Diciamo che in generale i programmatori non vedono di buon occhio il 
> "cambiare strada", ti faccio un esempio di quanto accaduto nell'azienda 
> in cui lavoro, necessità di un database aziendale che gestisse 
> matricole, prodotti, materiale, etc. sia internamente che esternamente 
> per i tecnici che fanno assistenza onsite e devono movimentare 
> matricole, modelli, etc.
> 
> In che modo tu avresti tradotto la carta ed i fogli di excell? Pensaci 
> qualche secondo... pensaci ancora e dopo ti scrivo qual'è stata la 
> soluzione del programmatore da me da subito criticata.
> 
> Gestionale fatto con un software Buffetti, tutti i client windows hanno 
> un *.exe che una volta aperto ha delle schermate che dialogano con SQL 
> Server Microsoft.
> 
> Ovviamente da remoto su smartphone, tablet, etc. non è possibile 
> accedere al database e quindi si usa la carta e poi la carta deve essere 
> ritrascritta per cosi' dire sul software che gira solo in lan.
> 
> Risposte del programmatore alle mie domande di attivazione di un 
> L.A.M.P.? "Ah ma non è sicuro un webserver, non va bene, non va di qua, 
> non va di la, non va di su, non va di giu'...

Cambia immediatamente programmatore.

[toc] | [prev] | [next] | [standalone]

#20335

> 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!

[toc] | [prev] | [next] | [standalone]

#20344

GabrieleMax <gabriele1NOSPAM@hotmail.com> ha scritto:

> > 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!

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.

;-)

[toc] | [prev] | [next] | [standalone]

#20329

Il 11/02/2016 13.52, GabrieleMax ha scritto:

> Risposte del programmatore alle mie domande di attivazione di un
> L.A.M.P.? "Ah ma non è sicuro un webserver, non va bene, non va di qua,
> 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

[toc] | [prev] | [next] | [standalone]

#20336

> Il programmatore non ha capito la domanda. Prova a rifargliela in VB6.
> :)

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...

[toc] | [prev] | [next] | [standalone]

#20340

On Thursday, February 11, 2016 at 3:23:58 AM UTC-5, Alessandro Pellizzari wrote:
> Il Wed, 10 Feb 2016 12:42:35 -0800, fmassei ha scritto:
> 
> > 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) :)
> 
> 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
> 

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!

[toc] | [prev] | [next] | [standalone]

#20350

Il Fri, 12 Feb 2016 06:53:07 -0800, fmassei ha scritto:

> 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: 

"NoSQL" è un termine troppo vago e racchiude almeno una trentina di tipi di 
DB diversi, compresi gli SQL (visto che sta per "Not Only SQL" :)

Detto questo, ho usato MongoDB in passato per tenere le pagine di un CMS e 
per fare un motore di ricerca. 
Attualmente lo stiamo usando per tenerci qualche centinaio di milioni di 
documenti, come queueing system (temporaneo, stiamo passando a RabbitMQ), 
come user-auth e per altre cose che ora non mi vengono in mente, e non 
possiamo assolutamente permetterci di perderle.

Il trucco sta nel settare il sync in modo che salvi almeno in un nodo del 
cluster (anche se hai un nodo solo).

> 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.

[toc] | [prev] | [next] | [standalone]

#20351

On Saturday, February 13, 2016 at 1:09:20 PM UTC-5, Alessandro Pellizzari wrote:
> Il Fri, 12 Feb 2016 06:53:07 -0800, fmassei ha scritto:
> 
> > 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: 
> 
> "NoSQL" è un termine troppo vago e racchiude almeno una trentina di tipi di 
> DB diversi, compresi gli SQL (visto che sta per "Not Only SQL" :)
> 

Io ero rimasto che stava per "non SQL", ma ho visto ora che in effetti
oggigiorno si usa la definizione tua (cambiata in corsa, a quanto pare, perché
molti NoSQL accettano query SQL) - sorry, non ero aggiornato :)

> Detto questo, ho usato MongoDB in passato per tenere le pagine di un CMS e 
> per fare un motore di ricerca. 
> Attualmente lo stiamo usando per tenerci qualche centinaio di milioni di 
> documenti, come queueing system (temporaneo, stiamo passando a RabbitMQ), 
> come user-auth e per altre cose che ora non mi vengono in mente, e non 
> possiamo assolutamente permetterci di perderle.
> 
> Il trucco sta nel settare il sync in modo che salvi almeno in un nodo del 
> cluster (anche se hai un nodo solo).
> 

Ah, qui mi posso solo fidare (e conoscendoti, naturalmente, mi fido :) ).
L'ultima volta che l'ho usato era nel periodo in cui erano appena tornati di
moda i NoSQL, saranno stati cinque/sei anni fa se non mi sbaglio, e ricordo
che c'erano casi in cui nemmeno si poteva avere la certezza che una scrittura
venisse eseguita. Magari oggi funziona tutto come mi aspetterei, ma mi riserbo
di avere un po' di tempo per ristudiarmi la situazione attuale prima di
esserne convinto.

> > unito all'assenza di consistenza, 
> 
> Non ha assenza di consistenza. Mancano solo per transazioni e l'integrità 
> referenziale,

Beh, senza quelle come fai a garantire la consistenza? :)

> che comunque il 99% dei siti web nemmeno usa.

Possibile, ma non i miei :) Sarà per come son cresciuto (informaticamente),
ma un DB deve essere sempre consistente mentre corre, indipendentemente da
cosa ci si sta facendo sopra e come. Anche sugli SQL, per esempio, non ho
mai usato ISAM (o MyISAM/Aria per MySQL che sia - su quello vado quasi
sempre di InnoDB).

Oltretutto, senza triggers e stored procedures, la gestione quotidiana dei
dati è una pila di scripts, di solito senza un filo logico, in svariati
linguaggi o scritta on-the-fly sul client :)

> 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.
> 

D'accordissimo, infatti per grandi(ssime) quantità di dati sceglierei
anche io un NoSQL.
Probabilmente prima mi chiederei se è vero che servono, tutti questi dati,
perché già per la maggior parte delle applicazioni attuali sono molto
scettico sulla necessità di memorizzare miliardi d'informazioni "inutili".

> 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).
> 

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!

[toc] | [prev] | [next] | [standalone]

#20352 — MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti)

Il Sat, 13 Feb 2016 12:30:13 -0800, fmassei ha scritto:

>> Il trucco sta nel settare il sync in modo che salvi almeno in un nodo
>> del cluster (anche se hai un nodo solo).

> Ah, qui mi posso solo fidare (e conoscendoti, naturalmente, mi fido :)
> ). L'ultima volta che l'ho usato era nel periodo in cui erano appena
> tornati di moda i NoSQL, saranno stati cinque/sei anni fa se non mi
> sbaglio, e ricordo che c'erano casi in cui nemmeno si poteva avere la
> certezza che una scrittura venisse eseguita. 

È vero. MongoDB 1.x aveva il sync di default a false, quindi scrivevi, la 
insert tornava dopo 1 microsecondo, e i dati prima o poi venivano scritti, 
se ti andava bene. :D

Dalla 2.x il sync è di default a true, e dalla 2.6 è impostato a 1 (cioè: 
assicurati che il dato sia scritto su almeno un nodo del cluster).
Che, per chi usa Mongo su un solo server, è esattamente come un SQL.

>> Non ha assenza di consistenza. Mancano solo per transazioni e
>> l'integrità referenziale,
> 
> Beh, senza quelle come fai a garantire la consistenza? :)

Forse intendiamo due cose diverse. :)

La consistenza dei dati, per come la intendo io, è: quando la insert o la 
update torna, sono sicuro che il dato è nel DB.

Per come clusterizza MongoDB, puoi avere 3 nodi in un cluster.
Quando scrivi su nodo1 con sync a 1, Il nodo 1 è consistente con sè 
stesso, cioè il dato che hai appena scritto lo conosce, e una read 
succesiva lo trova.
Se leggi da nodo2 o nodo3, potrebbe non esserci, perché viene sincronizzata 
5 secondi dopo (o più, se ci sono tanti dati in coda), ma prima o poi ci 
arriva.
Se vuoi che funzioni come un SQL, metti la sync a 3, e la insert non torna 
niente finchè il cluster non è sincronizzato.
Naturalmente le prestazioni in scrittura diventano pari a quelle di un SQL 
con 2 slave.
 
> ma un DB deve essere sempre consistente mentre corre, indipendentemente
> da cosa ci si sta facendo sopra e come. Anche sugli SQL, per esempio,
> non ho mai usato ISAM (o MyISAM/Aria per MySQL che sia - su quello vado
> quasi sempre di InnoDB).

Qui forse intendi integrità referenziale: se aggiorni dati connessi su due 
tabelle, il riferimento è sempre valido in moto atomico.

Beh, in MongoDB non hai FK, quindi non ha nemmeno senso parlare di 
integrità referenziale. :D

Quello che hai, però, è garanzia di operazioni atomiche su un documento. 
Avendo i documenti struttura libera, nella maggior parte dei casi (come in 
quello dei prodotti configurabili che facevo), è lo stesso, anche perché 
hai upsert che modifica al volo i documenti mentre fa la ricerca.

> Oltretutto, senza triggers e stored procedures, la gestione quotidiana
> dei dati è una pila di scripts, di solito senza un filo logico, in
> svariati linguaggi o scritta on-the-fly sul client :)

Operazioni di questo tipo normalmente le fai con sweep di upsert: Fai un 
primo giro di upsert settando un flag su tutti i documenti che vuoi 
processare, e poi te li passi eventualmente uno per uno.

Volendo farti male puoi anche passare un javascript a una map() (senza 
reduce) e processare i documenti server-side. :)
 
> D'accordissimo, infatti per grandi(ssime) quantità di dati sceglierei
> anche io un NoSQL.
> Probabilmente prima mi chiederei se è vero che servono, tutti questi
> dati, perché già per la maggior parte delle applicazioni attuali sono
> molto scettico sulla necessità di memorizzare miliardi d'informazioni
> "inutili".

Come dicevo, dipende dai problemi che hai da risolvere.

Ma, per esempio, un catalogo prodotti IMHO sta perfettamente in Mongo, 
visto che puoi indicizzare anche documenti embedded. Non ti serve nemmeno 
la "tabella categorie", volendo, o n tabelle incrociate per i tag, le 
varianti e, in alcuni casi, anche per i prezzi customizzati.

Idem per un blog, o un CMS.
 
> Io userei MongoDB per cose tipo collezione di dati statistici, secondo
> 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.

[toc] | [prev] | [next] | [standalone]

#20353 — Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti)

On Saturday, February 13, 2016 at 4:03:45 PM UTC-5, Alessandro Pellizzari wrote:
> Il Sat, 13 Feb 2016 12:30:13 -0800, fmassei ha scritto:
> > ricordo che c'erano casi in cui nemmeno si poteva avere la
> > certezza che una scrittura venisse eseguita. 
> 
> È vero. MongoDB 1.x aveva il sync di default a false, quindi scrivevi, la 
> insert tornava dopo 1 microsecondo, e i dati prima o poi venivano scritti, 
> se ti andava bene. :D
> 
> Dalla 2.x il sync è di default a true, e dalla 2.6 è impostato a 1 (cioè: 
> assicurati che il dato sia scritto su almeno un nodo del cluster).
> Che, per chi usa Mongo su un solo server, è esattamente come un SQL.
> 

Ah OK, era una cosa di settaggi allora.. Non so, io me la ricordo come
un incubo :) A quanto pare colpa mia di non RTFM.

> >> Non ha assenza di consistenza. Mancano solo per transazioni e
> >> l'integrità referenziale,
> > 
> > Beh, senza quelle come fai a garantire la consistenza? :)
> 
> Forse intendiamo due cose diverse. :)
> 
> La consistenza dei dati, per come la intendo io, è: quando la insert o la 
> update torna, sono sicuro che il dato è nel DB.
> 

Sì, a quanto pare intendiamo cose diverse :)
Per come la intendo io, la garanzia di consistenza è che, se vado sulla/e
macchina/e dove gira il DBMS e stacco il link di rete (o la corrente), quando
il servizio torna su e online (nel secondo caso, a meno di failure del FS,
che non dovrebbero accadere (*)), tutti i dati di tutte le tabelle  di tutti i
DB sono ancora correttamente referenziati e utilizzabili immediatamente da
tutti i servizi che li utilizzano, senza alcun bisogno di procedure di
recovery.

> Per come clusterizza MongoDB, puoi avere 3 nodi in un cluster.
> Quando scrivi su nodo1 con sync a 1, Il nodo 1 è consistente con sè 
> stesso, cioè il dato che hai appena scritto lo conosce, e una read 
> succesiva lo trova.
> Se leggi da nodo2 o nodo3, potrebbe non esserci, perché viene sincronizzata 
> 5 secondi dopo (o più, se ci sono tanti dati in coda), ma prima o poi ci 
> arriva.
> Se vuoi che funzioni come un SQL, metti la sync a 3, e la insert non torna 
> niente finchè il cluster non è sincronizzato.
> Naturalmente le prestazioni in scrittura diventano pari a quelle di un SQL 
> con 2 slave.
>

Ma questo (il partizionare i dati come hai descritto) lo puoi fare anche con
un DBMS SQL classico + slaves, non è una feature in più. D'accordo che
MongoDB è più scalabile in pratica, ma non sarebbe di per se un punto in più
a suo favore.

> > ma un DB deve essere sempre consistente mentre corre, indipendentemente
> > da cosa ci si sta facendo sopra e come. Anche sugli SQL, per esempio,
> > non ho mai usato ISAM (o MyISAM/Aria per MySQL che sia - su quello vado
> > quasi sempre di InnoDB).
> 
> Qui forse intendi integrità referenziale: se aggiorni dati connessi su due 
> tabelle, il riferimento è sempre valido in moto atomico.
> 
> Beh, in MongoDB non hai FK, quindi non ha nemmeno senso parlare di 
> integrità referenziale. :D
> 
> Quello che hai, però, è garanzia di operazioni atomiche su un documento. 
> Avendo i documenti struttura libera, nella maggior parte dei casi (come in 
> quello dei prodotti configurabili che facevo), è lo stesso, anche perché 
> hai upsert che modifica al volo i documenti mentre fa la ricerca.
> 

Anche qui, boh. Non avendo molto background sulle operazioni interne di
MongoDB, immagino "upsert" funzionare come lo "insert..on duplicate key
update": come fai senza integrità referenziale e transazioni se la corrente
ti va via a metà operazione?

> > Oltretutto, senza triggers e stored procedures, la gestione quotidiana
> > dei dati è una pila di scripts, di solito senza un filo logico, in
> > svariati linguaggi o scritta on-the-fly sul client :)
> 
> Operazioni di questo tipo normalmente le fai con sweep di upsert: Fai un 
> primo giro di upsert settando un flag su tutti i documenti che vuoi 
> processare, e poi te li passi eventualmente uno per uno.
> 
> Volendo farti male puoi anche passare un javascript a una map() (senza 
> reduce) e processare i documenti server-side. :)
>  

Come sopra. Magari c'è un meccanismo che non conosco all'opera, aspetto
il tuo commento :)

> > D'accordissimo, infatti per grandi(ssime) quantità di dati sceglierei
> > anche io un NoSQL.
> > Probabilmente prima mi chiederei se è vero che servono, tutti questi
> > dati, perché già per la maggior parte delle applicazioni attuali sono
> > molto scettico sulla necessità di memorizzare miliardi d'informazioni
> > "inutili".
> 
> Come dicevo, dipende dai problemi che hai da risolvere.
> 
> Ma, per esempio, un catalogo prodotti IMHO sta perfettamente in Mongo, 
> visto che puoi indicizzare anche documenti embedded. Non ti serve nemmeno 
> la "tabella categorie", volendo, o n tabelle incrociate per i tag, le 
> varianti e, in alcuni casi, anche per i prezzi customizzati.
> 
> Idem per un blog, o un CMS.
>  
> > Io userei MongoDB per cose tipo collezione di dati statistici, secondo
> > 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.
> 

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..

[toc] | [prev] | [next] | [standalone]

#20373 — Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti)

Il Sat, 13 Feb 2016 14:01:06 -0800, fmassei ha scritto:

> Per come la intendo io, la garanzia di consistenza è che, se vado
> sulla/e macchina/e dove gira il DBMS e stacco il link di rete (o la
> corrente), quando il servizio torna su e online (nel secondo caso, a
> meno di failure del FS,
> che non dovrebbero accadere (*)), tutti i dati di tutte le tabelle  di
> tutti i DB sono ancora correttamente referenziati e utilizzabili
> immediatamente da tutti i servizi che li utilizzano, senza alcun bisogno
> di procedure di recovery.

Dalla 2.qualcosa Mongo usa anche un sistema di journaling, quindi, sempre 
tenendo presente che non esistono referenze da tenere integre, il DB non 
si corrompe, anche se naturalmente quando salta la corrente puoi perdere 
dei dati.
 
> Ma questo (il partizionare i dati come hai descritto) lo puoi fare anche
> con un DBMS SQL classico + slaves, non è una feature in più. D'accordo
> che MongoDB è più scalabile in pratica, ma non sarebbe di per se un
> punto in più a suo favore.

Ma con gli slave non hai multimaster (non puoi scrivere sugli slave, solo 
sul master), quindi se va giù il master blocchi tutte le scritture.
O ho capito male?
 
> Anche qui, boh. Non avendo molto background sulle operazioni interne di
> MongoDB, immagino "upsert" funzionare come lo "insert..on duplicate key
> update": come fai senza integrità referenziale e transazioni se la
> corrente ti va via a metà operazione?

È un'operazione atomica, quindi o inserisce/updata il dato, o non lo fa.
Ma in realtà ho sbagliato a scrivere io. :D 
Mi riferivo al findAndUpdate(), che ti torna il documento prima della 
modifica ma applica la modifica in modo atomico. Molto utile per fare 
"soft-locking" di documenti in un ambiente multi-client.
 
> (**) 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..

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.

[toc] | [prev] | [next] | [standalone]

#20402 — Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti)

On Tuesday, February 16, 2016 at 3:25:09 AM UTC-5, Alessandro Pellizzari wrote:
> 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
>

Kudos! :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#20337

> 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');

Bene, idea interessante, grazie! :)

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web