On 18 Set, 16:52, "PadovaBoy (ovvero Giovanni)"
Post by PadovaBoy (ovvero Giovanni)Post by PadovaBoy (ovvero Giovanni)Si può sapere il genere del progetto?
--
Questo è il sito di riferimento:www.lppcollecting.it
E' stato fatto fino ad oggi senza un database, e adesso stiamo
lavorando per metterne uno.
Ce ne sarà uno per ogni sezione (uno per la rossa, uno per la gialla
ecc), visto anche che ogni sezione farà storia a se.
La necessità di avere un bel numero di tabelle è data dal fatto che
ogni sezione principale è divisa a sua volta da tante sottosezioni
(determinate dalla espansioni delle carte) per cui viene creata una
tabella per gestire in modo semplice ogni sottosezione, considerando
che ogni tabella avrà da un 60 fino a 250 righe. In questo modo ogni
volta che dovrò andare a cambiare un prezzo (cosa che avviene tutti i
giorni o quasi) non avrò difficoltà a trovare il punto dove devo fare
la modifica.
Con un'unica tabella, mi trovo ad avere una lista di oltre 3000
articoli, alcuni anche con lo stesso nome, e capisci che andare a
cambiare un prezzo qui è molto più complicato, per quanto ci arrivo
comunque nel punto desiderato.
Inoltre gestire una tabella di 3000 articoli per visualizzarne in una
pagina 30 al max è molto più complicato che non avere una tabella con
in media 100 articoli, peraltro di una sola sottosezione.
Devo dire che come idea è interessante.
Mi viene male al pensiero solo delle prime leggi della normalizzazione
ma ha il suo senso.
Diciamo che hai "semplificato" la struttura del database per sopperire
alle tue mancanze di conoscenza di php.
Non è malvagia, ed è pur sempre una scelta.
Quello che ti giochi così però è la flessibilità: domani introdurre la
vendita online o altri aspetti sarà un suicidio.
Solitamente in questi casi si costruisce una tabella in cui vengono
inserite tante colonne quanti sono i dettagli di tutti i tipi di
prodotto (nome, taglia, prezzo e altro).
Poi viene magari aggiunta una o più colonne che faranno riferimento ad
altre tabelle contenti relazioni con categorie, sottocategorie, key etc..
A mio avviso dovresti pensare meglio alla struttura se un domani non
vuoi perdere un bel pò di tempo a ricucire il tutto senza perdere dati.
--
Giovanni
------------------------------
Xbox360 Live Tag: PadovaBoy
WiiTag: neanche io lo so
GOW TAG: pappa per Criceti
PadovaBoy crocciola padovaboy DOT it
www.padovaboy.itdal 2001 con furore ;)
Dicono di me: che sia femmina e di pordenone...starà a voi crederci- Nascondi testo citato
- Mostra testo citato -
Infatti noi stiamo già strutturando le tabelle in previsione futura,
per cui nella colonna disponibilità mettiamo 1 oppure 0 a seconda se
il prodotto è disponibile oppure no.
Poi con una funzione gli facciamo scrivere disponibile oppure no.
In futuro questa funzione metterà l'icona del carrello verde se
disponibile oppure quella rossa se non disponibile. Per cui sull'icona
rossa non ci potrai cliccare, mentre su quella verde ci clicchi ed
invii al carrello le 3 info che interessano per "fare la spesa" e cioè
codice, articolo e prezzo, poi la quantità l'utente se la modifica nel
carrello.
La nostra fortuna è quella che abbiamo migliaia di articoli da
gestire, ma in sostanza con gli stessi parametri. E la struttura di
ogni sezione in sostanza è la stessa.
Chiaro che si potrebbe gestire anche tutta la struttura del sito via
batabase, ma per il momento ci accontentiamo, visto anche che
l'esperienza la si fa con il tempo ed al momento ne abbiamo ancora
poca ^_^
In futuro poi probabile che ci potranno essere delle modifiche alle
tabelle, anche se noi, mentre le costruiamo adesso, stiamo già
ragionando su tutte le colonne che ci possono servire, anche quelle
che poi non visualizziamo nella pagina che vede l'utente. Per cui
cerchiamo comunque di fare una struttura che in futuro deve subire il
minor numero di modifiche o addirituttra nessuna.
Grazie a tutti per i consigli, se me ne serviranno altri, non esisterò
a chiedere ^_^