Più che fantascienza, mi sembra un'idea folle. Che senso ha avere un database che si basa sui numeri di pagina del catalogo? Semmai dovrebbe essere il catalogo ad uscire come conseguenza del db.
Più che fantascienza, mi sembra un'idea folle. Che senso ha avere un database che si basa sui numeri di pagina del catalogo? Semmai dovrebbe essere il catalogo ad uscire come conseguenza del db.
Ti quoto in toto.
Ma si tratta della classica eccezione. Il catalogo cartaceo, in realta' e' un hyper-catalogo cartaceo con rimandi in ogni pagina. Ogni pagina contiene 'collegamenti' (tanti; almeno una decina per pagina) ad altre pagine. E' un catalogo cartaceo molto complesso, dal punto di vista dei rimandi o riferimenti incrociati. E quindi il numero di pagina e' cruciale.
Io dovrei riproporre qualcosa che gli assomigli a livello web. Ma ricostruire l'intero catalogo e' economicamente non remunerativo. La soluzione pare essere quella di presentare un simil catalogo cartaceo on-line.
Senza dimenticare che nel tempo questo catalogo viene aggiornato.
Io immaginavo una tabella di tutte le pagine del catalogo. Aggiorno il catalogo cartaceo e aggiorno la tabella delle pagine. Fin qui e' facile.
Poi immaginavo una tabella prodotti in cui specifico per ogni prodotto la pagina iniziale e la pagina finale.
Mi manca il meccanismo che, all'aggiornamento del catalogo (tabella pagine), mi permetta di aggiornare il numero di pagina iniziale e finale di ogni prodotto.
Esempio: aggiungo il prodotto X che occupa 4 pagine dalla 320 alla 323.
In pratica dovrei aggiornare tutti i riferimenti delle pagine che fanno riferimento (scusate il gioco di parole) alle pagine dalla 320 in poi, incrementandoli del numero di pagine occupate dal nuovo prodotto (+4).
Si puo' fare una UPDATE che mi seleziona un range di prodotti (in base alle pagine inziali e finali) e mi incrementi due campi di 4? (e qui scatta la mia conoscenza superfiaciale di mysql).
Alla peggio faccio delle UPDATE MANUALI. Si tratta di due o tre aggiornamenti all'anno.
Hellppp!
tony