[mysql] struttura per tabella e-comm

[Manuel.s]

ciao a tutti

sto creando un e-comm che sia anche un po flessibile, ma mi trovo ad affrontare lo scoglio di strutturare una tabella che contenga le informazioni relative alle quantità. Il problema è che vorrei avere mano libera per quanto riguarda le caratteristiche prodotto: se si trattasse solo di taglia e colore farei una tabella con id, id_prodotto, taglia, colore e quantità, ma se volessi fare in modo che sia l'utente a definire le caratteristiche di un singolo prodotto? premetto che questa parte l'ho gia affrontata, mi serve solo un idea su come memorizzare le quantità...

grazie

[mosquito70]

Originariamente inviato da Manuel.s
ciao a tutti

sto creando un e-comm che sia anche un po flessibile, ma mi trovo ad affrontare lo scoglio di strutturare una tabella che contenga le informazioni relative alle quantità. Il problema è che vorrei avere mano libera per quanto riguarda le caratteristiche prodotto: se si trattasse solo di taglia e colore farei una tabella con id, id_prodotto, taglia, colore e quantità, ma se volessi fare in modo che sia l'utente a definire le caratteristiche di un singolo prodotto? premetto che questa parte l'ho gia affrontata, mi serve solo un idea su come memorizzare le quantità...

grazie

Non so se ho capito bene quello che cerchi, perche' non e' chiaro se esistono i prodotti di base e l'utente li associa a se stesso con una taglia o un colore, oppure se intendi qualche altra cosa.

Comunque, se fosse cosi', si potrebbe strutturare il db nel seguente modo (e' un esempio e ce ne potrebbero essere altri)

Tabella prodotti
id (autoincrement)
desc_prodotto


Tabella Taglia
id (autoincrement)
desc_taglia

Tabella colore
id (autoincrement)
desc_colore

Tabella utente
id (autoincrement)
desc_nome
desc_cognome
...altri campi...

Tabella relaUtenteProdotti
id (autoincrement)
id_utente FK
id_prodotto FK
id_taglia FK
id_colore FK
quantita

(le relative FK creale te...)

In questo caso il colore e la taglia sono obbligatorie, anche perche' non ha senso definire un prodotto (vestito) che non le abbia
Dovresti inoltre controllare (a livello di codice o di DB) che non si possano inserire gli stessi id
per lo stesso record nella tabella relaUtenteProdotti.

Ogni volta che l'utente crea un prodotto, lo obblighi ad inserire taglia e colore e di default metti quantita' 1 (chiaramente modificabile).
Se torna successivamente su quel prodotto, gli permetti di scegliere tra i colori e le taglie scelte e quindi andrai in update sulla tabella di relazione.
Se vuoi eliminare un prodotto, vai in delete e se vuoi diminuirne la quantita' di nuovo in update.

Con questo schema, hai la possibilita' di estrarre i totali delle quantita', sia a livello di singola taglia/colore che a livello dei prodotti per singolo utente o per tutti gli utenti.

Non so se e' questo e' il suggerimento che cercavi.

[Manuel.s]

ciao
ti ringrazio per la risposta

quello che cerco è un po diverso, la struttura che tu proponi va bene se i prodotti prevedono taglia e colore, ma devo avere la flessibilità di poter aggiungere caratteristiche (deve poterlo fare l'amministratore) senza modificare alcuna tabella. Forse ho dimenticato di dire una cosa: quello che mi serve a questo punto è una ipotetica tabella "magazzino" dove conservare le quantità. Se le caratteristiche fossero solo taglia e colore, mi andrebbe bene una tabella magazzino cosi predisposta:

Tabella Magazzino
id
id_prodotto
taglia
colore
quantita

cosi da sapere quante maglie rosse XL, quante rosse L, quante nere M, ecc ci sono in magazzino.

ma se l'admin dello shop decide di iniziare a vendere camice, che iltre a taglia e colore prevedono la misura del collo? e se successivamente volesse inserire dei cappellini, le cui caratteristiche sarebbero colore e tessuto? devo avere una struttura adattabile a tutte le esigenze ed è qui che mi sono fermato.

A dire il vero una scappatoia la avrei trovata ma è piu basata sul codice che sul DB, se trovassi una soluzione pulita basata su DB sarebbe meglio...

grazie
ciao

[mosquito70]

Ora e' piu' chiaro

Appena ho un attimo di tempo (oggi esco tra una oretta) provo a tirare giu' uno schema.
Comunque, cosi' a prima vista, io non scarterei anche l'ipotesi di usare una struttura XML

[deleted_29]

una soluzione TUTTA basata sul codice (e dipendente in particolare dalle prestazioni necessarie) è quella di taggare.

sostanzialmente usando un campo BLOB ci mettei dentro qualcosa del tipo
taglia=xxx;colore=yyy;forma=zzz

questo darà la massima libertà di definizione all'utente (è banale creare una tabella delle tag da cui attingere) MA...
... lato applicazione dovrai farti le funzioncine (o i metodini, se lavori ad oggetti)

codificatag:elenco_stringhe-> stringa
decodificatag:stringa -> lista tag, lista valori
cercatag
aggiungitag
cambiatag
eliminatag

il "vero" problema è la ricerca, che richiede dei LIKE %taglia=qualcosa;% il che è decisamente devastante se hai molte righe e/o molte interrogazioni.

In questo caso, normalmente, uso sphinx per "trasformare" le ricerche in full text, con performances di pochi millisecondi su tabelle di milioni di righe

----------
Questo è UN approccio, non L' approccio, spero comunque di averti dato qualche spunto di riflessione

[Manuel.s]

è esattamente quello che ho fatto
l'unica differenza è che costruisco un array con tutte le informazioni che mi servono, es:

$myArr[$caratteristica] = $valore1;
$myArr[$caratteristica2] = $valore2;
$myArr[$caratteristica3] = $valore2;

dove ad esempio $caratteristica1 è colore e valore1 è verde, caratteristica2 è taglia e valore2 è XL

sul campo BLOG salvo l'array serializzato, facile da recuperare e ricomporre...

non vorrei sembrare presuntuoso ma se siamo entrambi arrivati a questa soluzione, evidentemente è la strada migliore da seguire

buon anno

[deleted_29]

buon anno anche a te, considera che questa soluzione, banale in realtà, ha però il "problemino" delle ricerche, ove perdi ovviamente qualsiasi indice (se non usi sphinx o qualche accrocchio del genere).

Come intendi affrontarlo? (così magari mi dai qualche suggerimento utile)

Nei miei applicativi, paradossalmente, spesso carico in memoria l'intera tabella (o meglio la porzione che mi interessa) e poi ci lavoro lì (!!!), compresi i cambiamenti e poi li riscrivo tutti (!!!!) in un colpo solo.

[Manuel.s]

per quanto riguarda la ricerca di solito viene fatta sui campi descrittivi (titolo, descrizione,ecc), se invece volessi fare una ricerca tipo "seleziona tutti i prodotti taglia XL colore rosso", si potrebbe cercare nel campo blog, nel senso che se seleziono qeste caratteristiche da delle select, ottengo il solito array serializzato, dunque cercherei con una query del tipo

"select * from products_quantity where caratteristiche = 'a:2:{s:3:"f-2";s:1:"4";s:3:"f-3";s:1:"7";}'"

non ho provato ma potrebbe funzionare, bisognerebbe però avere alcune accortezze:

- caratteristiche e valori devono essere codificati, significa che devi avere una tabella caratteristiche, una tabella valori (relazionata a caratteristiche) ed una tabella di raccordo tra caratteristiche e prodotti (che indica quali prodotti hanno come caratteristica colore e taglia, quali solo colore, quali colore e lunghezza, ecc...)

- l'array prima di essere serializzato e salvato sul DB deve essere ordinato, questo per evitare di trovarti con array serializzati diversi tra loro ma che esprimono le stesse proprietà, a causa dell'ordine nel quale sono stati inseriti i diversi elementi.

non mi vengono in mente altre cose da tenere a mente, se viene in mente qualcosa a te possiamo discuterne, anche se temo che stiamo andato OT rispetto al forum...

a presto

[deleted_29]

mi sono un po' perso, provo a ricapitolare.

Se codifichi in una stringa una serie di tag, intesa come coppie di chiave-attributo, ottieni qualcosa del tipo (esempio banale di 4 righe)

taglia=27;colore=rosso;peso=34;
taglia=28;peso=25;
colore=rosso;peso=34;
colore=verde;

il problema si pone nel momento in cui voglio, ad esempio, tutti gli oggetti di colore rosso.

dovrò fare qualcosa simile a
select ... from ... where upper(tag) like '%COLORE=ROSSO;%'
o equivalente.

una ricerca di questo tipo è una full-scan su tutte le righe della tabella,
il che può andar bene (se la tabella è piccola), molto male (se la tabella è grande),
malissimo (se la tabella è usata in una join) o terribile (in una select ... in )

In questo caso perdi ogni possibilità di utilizzare indicizzazioni; a parte la ricerca full text su myisam (ma in realtà non va bene per tabelle grandi).

Per questo tipo di ricerche, come accennato, tipicamente mi appoggio a un motore ad hoc (sphinx) proprio per "fingere" una ricerca full text all'interno del campo tag.

Tuttavia uno spunto positivo cui non ho pensato sarebbe proprio utile