Aiuto Database

[giuseppe500]

Salve, forse questo non è il forum giusto(se non lo è spostatemi e scusate).
il database è mysql
Il mio problema è questo : devo costruire il database di un sito con le seguenti caratteristiche:
1)ho 4 categorie:news,articoli ,biografie e recensioni
2)per ognuna di queste categorie devo specificare 4 sottocategorie:recensore,titolo,news e newscompleta(campi testo).
4)ogni categoria ha uno schema ben preciso di visualizzazione
3)in ogni sottocategoria devo poter effettuare ricerche.
La risoluzione che mi veniva in mente era quella di creeare 4 tabelle con le categorie contenenti le 4 sottocategorie
ma mi sembra un approccio che non è quello giusto in un dataase relazionale.
Scusate ma sono agli inizi Grazie in anticipo.

[eiyen]

ma quale è il problema? La cosa migliore (a parte naturalmente questioni di sviluppo professionale) è realizzarlo come meglio ti trovi tu. Se lo imposti correttamente puoi fare come ti sembra meglio. Hai già postato una "soluzione" (poi bisognerebbe vedere, certo, come è fatta in dettaglio, ma da quel che si intuisce si può fare...)

[giuseppe500]

il problema è che non sono abituato a scrivere database per il web , forse anche il piu semplice dei problemi me lo complico.
Ma sono davvero cosi semplici le soluzioni di database per il web?
In risposta vorrei dire che non è vero che "basta che funzioni" io voglio conoscere il metodo migliore gia dai problemi semplici di modo che ci sia una crescita futura.

[eiyen]

beh: x il metodo migliore ci vuole una buona analisi. "basta che funzioni" (come ho scritto sopra) si riferisce a una soluzione "non professionale" (che non vuol dire "non importante": lo preciso perchè non sembri offensivo - non lo è!)

Nel tuo caso non bastano i dati che hai postato. Posso dirti alcuni fattori che influenzano la scelta per il db: tipi di dati, quantità dei dati, metodo di ricerca dei dati e loro visualizzazione.

In un caso medio (o cmnq semplice) tipo pochi dati e richiamo dei dati con semplici tabelle e query dirette (forse è il tuo caso) c'è poca differenza, quindi la scelta migliore è quella con cui ti trovi meglio. Se ti può interessare una indicazione più precisa, potresti postare altre informazioni (soprattutto il tipo e la quantità dei dati)

[13manuel84]

Io non so se sono riuscito ad inquadrare bene il tuo problema, comunque era già stata postata una soluzione a riguardo di database con categorie, sottocategorie etc. ed una soluzione molto flessibile che era stata proposta era stata quella di fare un db composto di un'unica tabella, il chè risultava molto flessibile ed estensibile. Era gestito con una specie di ricorsività; cerco di spiegartelo in poche parole, sperando di non fare confusione.

Dunque tu hai un unica tabella, con (mettiamo il caso più semplice e banale) 3 soli campi.

id_categoria | nome_categoria | id_categoria_padre

nell'ultimo campo metterai 0 (o un valore che vuoi tu) se la categoria non ha una categoria padre (e quindi è padre di per sé).

In questo caso la tua tabella è altamente flessibile nel senso che puoi arrivare ad esempio anche al 100° livello con una sola tabella; chiaramene (almeno a mio parere) richiede più cura nella progettazione e nella stesura. E va benissimo nel caso in cui tu non sappia a priori quanti livelli deve avere il tuo db.
Per livelli intendo una struttura del genere:

Sport
|
|----Individuali
|    |
|    |----Scherma
|    |
|    |----Boxe  
|
|----Di Squadra
     |
     |----Calcio

Questo con una struttura ricorsiva richiede una sola tabella, altrimenti te ne dovrai fare 2 o 3 (2 se il db tratta solo di Sport 3 se tratta di più Argomenti).

Nel secondo caso, lo puoi fare benissimo quando sai a priori il numero di livelli che avrai, dovrai implementare una tabella per ogni livello ed in ogni tabella avrai ad esempio l'id del livello padre impostato come chiave esterna. Questo è relativamente più semplice (parlo per mia esperienza, che naturalmente non è la stessa di molti altri) e richiede meno cura, in quanto ogni volta che hai bisogno di un nuovo livello basta aggiungere una nuova tabella; richiede molta meno testa nel ragionamento delle query per risalire ad esempio al nodo padre (bastano un paio di JOIN), ma per contro (come già detto) è poco flessibile ed estensibile ed occupa maggior spazio inteso come memoria.

A mio modesto parere non esiste una soluzione migliore in ogni campo, in quanto ognuno potrebbe elaborare una soluzione a lui congeniale, una soluzione che lui trova semplice ed immediata.

Detto questo spero di essere riuscito a chiarirti qualcosa e non il contrario.

e buon lavoro!

[giuseppe500]

per quanto riguarda la quantita dei dati sono qualche migliaio di record,è per questo che come hai bene precisato sopra mi sembra che quella delle tabelle divise non sia una scelta professionale.
Per quando riguarda il tipo dei dati sono tutti testi tranne un campo data per ogni categoria.
Il problema della ridondanza che è quella per cui da come ho capito in questi anni (ma posso anche non avere capito molto)
sono stati sviluppati i database relazionali assieme alla "gestibilita" in questo caso non la vedo:Ogni record corrisponde ad una determinata pagina e basta in cui tutte le informazioni sono diverse (non c'è ridondanza).
Se mai ho pensato che si puo creare uno schema di come visualizzarle queste pagine e li forse c' è del lavoro da fare(correggimi se sbaglio).
Intanto grazie per la gentilezza ,ma se mi rispondi sono piu felice.

[eiyen]

"qualche migliaio" non è tantissimo dal punto di vista del db. Quindi un'unica tabella può andare pure bene. Come detto nel post prec. la soluz. ricorsiva è flessibile ma un po' complicata. Se il tuo caso è quello che hai descritto sopra ti conviene UNA tabella con campi recensore, titolo, news, newscompleta, categoria (dove quest'ultima assume solo 1 valore tra i 4 che hai indicato).

[giuseppe500]

manuela, non ho capito molto mi puoi dare qualche link o ulteriori informazioni?
Grazie mille comunque ,ciao

[13manuel84]

link non ne ho, e se mi dici dove non hai capito cerco di rispiegartelo.

p.s. comunque sono manuel non manuela

[giuseppe500]

scusa , manuel(mia sorella si chiama manuela ,ecco spiegato l'errore sul nome).
Il problema che non capisco è come fare a navigare con le query("select..")all' interno della mia tabella , ho pensato di usare funzioni ricorsive(dimmi se sbaglio)ma non so come implementarle:devo tenere traccia praticamente del id_categoria_padre
grazie , ciao