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

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

User che veda uno o più brand

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

Contents

  User che veda uno o più brand GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-07 21:43 +0200
    Re: User che veda uno o più brand Alessandro Pellizzari <shuriken@amiran.it> - 2018-04-07 21:32 +0100
      Re: User che veda uno o più brand GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-08 14:47 +0200
        Re: User che veda uno o più brand Alessandro Pellizzari <shuriken@amiran.it> - 2018-04-08 16:38 +0100
          Re: User che veda uno o più brand GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-08 22:57 +0200
            Re: User che veda uno o più brand Alessandro Pellizzari <shuriken@amiran.it> - 2018-04-09 15:36 +0100
              Re: User che veda uno o più brand GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-09 22:06 +0200
      Re: User che veda uno o più brand fmassei@gmail.com - 2018-04-08 08:55 -0700

#21961 — User che veda uno o più brand

Salve,

da newbie vorrei un parere sulla situazione seguente:

User che può vedere uno o più brand ed ogni brand ha i suoi prodotti 
memorizzati in product.

Usando MySQL, INNODB e le FK è facile legare la tabella user alla 
tabella brand con un rapporto di 1 a 1 ma come potrei fare a legare un 
user a più brand? O meglio come potrei inserire tali informazioni in una 
tabella del db?

Per quanto riguarda la tabella product invece basta una sola chiave per 
legare i prodotti al brand quindi in questo caso il rapporto 1 a 1 va bene.

Saluti.
GabrieleMax

[toc] | [next] | [standalone]

#21962

On 07/04/18 20:43, GabrieleMax wrote:

> User che può vedere uno o più brand ed ogni brand ha i suoi prodotti 
> memorizzati in product.
> 
> Usando MySQL, INNODB e le FK è facile legare la tabella user alla 
> tabella brand con un rapporto di 1 a 1 ma come potrei fare a legare un 
> user a più brand? 

Ti serve un rapporto n:n, non 1:1 (o 1:n, come nel caso dei prodotti per
brand).

in SQL normalizzato lo puoi fare solo con una tabella intermedia:

create table user (id primary key, ...)
create table brand (id primary key, ...)
create table user_brand (user_id int, brand_id int)

A seconda dei casi potresti denormalizzare il rapporto, e semplicemente
mettere la lista dei brand_id dentro un array (su un DB che li supporta,
tipo PostgreSQL) o encodarli in JSON dentro un campo string nella
tabella user.

Non ci puoi fare le join, naturalmente, ma solitamente non è un problema
perché se l'utente è loggato hai già in memoria una class coi suoi dati,
inclusi i brand deserializzati.

> Per quanto riguarda la tabella product invece basta una sola chiave per 
> legare i prodotti al brand quindi in questo caso il rapporto 1 a 1 va bene.

1:n, che in SQL si esprime "al contrario" (cioè sono i prodotti che
linkano al brand, e non viceversa):

create table product (id primary key, brand_id int references brand(id),
...)

(vado a memoria con la sintassi, ultimamente sto usando troppi DB
diversi... :D)

1:1 significa che hai un solo prodotto per brand, che non ha senso. :)

Il rapporto 1:1 con foreign keys si usa di solito per ottimizzare i dati
sul supporto. Per esempio mettendo in una partizione diversa o su un
engine diverso dati che vengono acceduti meno spesso anche se in realtà
potrebbero stare nella stessa tabella.

Nel caso del brand, per esempio, potresti mettere l'indirizzo o i
contatti in una tabella separata, perché ti servono solo quando
l'amministrazione deve fatturare, e tenere solo nome, id e logo in una
tabella può portare ad avere effettivamente tutta la tabella dei brand
in cache in RAM per il 99.9% del tempo.

Bye.

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

#21963

> Ti serve un rapporto n:n, non 1:1 (o 1:n, come nel caso dei prodotti per
> brand).

Si hai ragione!

> in SQL normalizzato lo puoi fare solo con una tabella intermedia:
> 
> create table user (id primary key, ...)
> create table brand (id primary key, ...)
> create table user_brand (user_id int, brand_id int)

Nella tabella user dovrei creare tanti utenti quanti sono i marchi 
presenti nella tabella brand e collegarli tra loro con le FK in un 
rapporto di 1:1?

Nella tabella user_brand dovrei creare l'utente "vero e proprio" per il 
login ma ad esempio l'utente "X" in questa tabella come può essere 
associato a più utenti che potremmo definire "A" "B" e "C" contenuti 
nella tabella user visto che, come già accennato, l'utente "X" potrebbe 
vedere non solo "A" ma anche "B", "C", etc.

> A seconda dei casi potresti denormalizzare il rapporto, e semplicemente
> mettere la lista dei brand_id dentro un array (su un DB che li supporta,
> tipo PostgreSQL) o encodarli in JSON dentro un campo string nella
> tabella user.

Ok!

> Non ci puoi fare le join, naturalmente, ma solitamente non è un problema
> perché se l'utente è loggato hai già in memoria una class coi suoi dati,
> inclusi i brand deserializzati.

Ok.

> 1:n, che in SQL si esprime "al contrario" (cioè sono i prodotti che
> linkano al brand, e non viceversa):
> 
> create table product (id primary key, brand_id int references brand(id),
> ...)
> 
> (vado a memoria con la sintassi, ultimamente sto usando troppi DB
> diversi... :D)

Si, il concetto è corretto! :)

> 1:1 significa che hai un solo prodotto per brand, che non ha senso. :)

Vero.

> Il rapporto 1:1 con foreign keys si usa di solito per ottimizzare i dati
> sul supporto. Per esempio mettendo in una partizione diversa o su un
> engine diverso dati che vengono acceduti meno spesso anche se in realtà
> potrebbero stare nella stessa tabella.

Interessante, non lo sapevo!

> Nel caso del brand, per esempio, potresti mettere l'indirizzo o i
> contatti in una tabella separata, perché ti servono solo quando
> l'amministrazione deve fatturare, e tenere solo nome, id e logo in una
> tabella può portare ad avere effettivamente tutta la tabella dei brand
> in cache in RAM per il 99.9% del tempo.

Giusta osservazione, il tutto va contestualizzato all'uso che se ne deve 
fare del db e quante volte certi dati debbano essere "tirati" fuori!

> Bye.

Saluti e grazie ancora per tutte le precisazioni/risposte!
GabrieleMax

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

#21964

On 08/04/18 13:47, GabrieleMax wrote:

>> create table user (id primary key, ...)
>> create table brand (id primary key, ...)
>> create table user_brand (user_id int, brand_id int)
> 
> Nella tabella user dovrei creare tanti utenti quanti sono i marchi 
> presenti nella tabella brand e collegarli tra loro con le FK in un 
> rapporto di 1:1?
> 
> Nella tabella user_brand dovrei creare l'utente "vero e proprio" per il 
> login ma ad esempio l'utente "X" in questa tabella come può essere 
> associato a più utenti che potremmo definire "A" "B" e "C" contenuti 
> nella tabella user visto che, come già accennato, l'utente "X" potrebbe 
> vedere non solo "A" ma anche "B", "C", etc.

No. Nella tabella user metti tutti i dati degli utenti. Nella tabella
brand metti tutti quelli dei brand.

Nella tabella user_brand metti sono l'id dell'utente e quello del brand
a cui vuoi associarlo.

Vuoi tutti i brand di un utente (dato un $userId)?

select b.* from user_brand ub join brand b on ub.brand_id=b.id where
ub.user_id=$userId

Vuoi tutti gli utenti associati a un brand (dato un $brandID)?

select u.* from user_brand ub join user u on ub.user_id=u.id where
ub.brand_id=$brandId

Bye.

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

#21966

> No. Nella tabella user metti tutti i dati degli utenti. Nella tabella
> brand metti tutti quelli dei brand.
> 
> Nella tabella user_brand metti sono l'id dell'utente e quello del brand
> a cui vuoi associarlo.

Ti ringrazio per l'ulteriore risposta! Ti chiedo un parere, se avessi 
una tabella chiamata user con tutti gli utenti e le loro descrizioni e 
la tabella brand con tutti i marchi e la loro descrizione potrei 
"linkare" con una FK uno o più marchi allo stesso utente usando quindi 
solo due tabelle!

Saluti.
GabrieleMax

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

#21967

On 08/04/2018 21:57, GabrieleMax wrote:

> Ti ringrazio per l'ulteriore risposta! Ti chiedo un parere, se avessi 
> una tabella chiamata user con tutti gli utenti e le loro descrizioni e 
> la tabella brand con tutti i marchi e la loro descrizione potrei 
> "linkare" con una FK uno o più marchi allo stesso utente usando quindi 
> solo due tabelle!

Se un marchio può essere associato a un solo utente (1:n), allora sì, 
col sistema che ho spiegato per collegare i prodotti ai brand.

Se un brand può essere associato a più utenti e un utente a più brand 
(n:n) l'unico modo è quello con la tabella di collegamento.

Bye.

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

#21968

> Se un marchio può essere associato a un solo utente (1:n), allora sì, 
> col sistema che ho spiegato per collegare i prodotti ai brand.
> 
> Se un brand può essere associato a più utenti e un utente a più brand 
> (n:n) l'unico modo è quello con la tabella di collegamento.

L'esigenza (almeno per ora) sarebbe quella di associare solamente più 
brand ad un utente però con una tabella in più come da te consigliato 
potrei avere una situazione più aperta perchè alla fine dello stesso 
marchio se ne potrebbero occupare più utenti!

Di sicuro la tua soluzione è la migliore per i motivi già descritti e se 
vi fosse la necessità di implementarla in uno step successivo sarebbe un 
"bel" problema!

> Bye.

Saluti!
GabrieleMax

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

#21965

On Saturday, April 7, 2018 at 4:32:08 PM UTC-4, Alessandro Pellizzari wrote:

E' tutto giusto, ma solo due appunti.

> A seconda dei casi potresti denormalizzare il rapporto, e semplicemente
> mettere la lista dei brand_id dentro un array (su un DB che li supporta,
> tipo PostgreSQL) o encodarli in JSON dentro un campo string nella
> tabella user.
> 
> Non ci puoi fare le join, naturalmente, ma solitamente non è un problema
> perché se l'utente è loggato hai già in memoria una class coi suoi dati,
> inclusi i brand deserializzati.
> 

Questo, a me, suona molto come cattiva architettura.
L'idea di base dovrebbe sempre essere che qualsiasi operazione può in
teoria essere fatta unicamente sul DB. Si costruisce un servizio web
per chi non sa (o semplicemente non ha voglia di) fare query a mano.
Quando questo non è possibile si sta evidentemente spostando un pezzo di
dati dalla base di dati, dove dovrebbe stare, alla logica applicativa,
rompendo la separazione delle competenze.

Naturalmente quando si deve per forza ottimizzare tutto è concesso, ma
aspetterei il momento di non poter proprio fare altrimenti.

> Nel caso del brand, per esempio, potresti mettere l'indirizzo o i
> contatti in una tabella separata, perché ti servono solo quando
> l'amministrazione deve fatturare, e tenere solo nome, id e logo in una
> tabella può portare ad avere effettivamente tutta la tabella dei brand
> in cache in RAM per il 99.9% del tempo.
> 

Probabile, ma qui c'è un altra cosa da dire. Prevedere il caching di un
DBMS è una delle cose più complicate che esistano, perché a quel livello
di astrazione ci sono almeno quattro/cinque livelli di cache. Anche qui,
prima di cercare di capire di cosa ha effettivamente bisogno di stare in
cache, e soprattutto non fidarsi degli algoritmi di default, bisogna essere
in una situazione non comune.

Ciao!

[toc] | [prev] | [standalone]

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

csiph-web