Database schema blog (simile)

[KILLERIX]

Buongiorno ragazzi, sto provando a ricreare un sito simile a questo (https://www.mobafire.com/league-of-legends/browse). Vorrei creare la pagina qui sopra ma prima devo creare il database.
Alla fine è come fosse un blog: un utente si registra, va nella pagina per aprire una nuova guida, la scrive tramite l'editor e la pubblica. Se la visualizza l'utente creatore, può editarla; se la visualizza un qualsiasi utente può commentarla e valutarla.

Secondo voi, che tabelle devo creare?
Ogni guida (tabella guida: id, nome, autore_id, data_pubbl, data_update, contenuto, feedback, commenti) può appartenere a più categorie (tabella categorie: id, categoria).
Poi dovrei creare una tabella per i commenti delle varie guide (tabella commenti: id, id_guida, order, autore_id, contenuto, data_pubbl).
Anche un sistema di tag come quello di questo sito, che permette di aggiungerli prima di pubblicare qualcosa.

Per il contenuto della guida, invece, vorrei avere una struttura particolare, proprio come nel link descritto. Faccio un'altra tabella (tabella contenuto: id, id_guida, title, img, descr, overwiev, strategy, option, tips)?

Lo so che la questione potrebbe essere lunga ma sappiate che, prima di scrivere questi papiri, cerco sempre su google ore e ore, anche in inglese, guide o pagine che mi possano aiutare a creare la struttura base delle mie idee ma non ho trovato niente.

Grazie!

 

[Antonio De Marco]

Premetto che non ti do queste indicazioni in veste di un progettista di database ma come programmatore. Ad ogni modo ti butto li quelle tabelle che mi vengono in mente leggendo:
tbl_utenti
tbl_guide (chiave esterna su tbl_utenti)
tbl_guida_valutazioni (con chiavi esterne su tbl_utenti e tbl_guide)
tbl_guida_commenti (chiave esterna su tbl_guide e tbl_utenti)
tbl_categoria
tbl_guida_categorie (chiave esterna su tbl_categoria e tbl_guide)

Su alcuni concetti (tipo i tag) ti sei soffermato più sulle funzionalità che non ho avuto modo di testare quindi ho omesso. In linea di massima comunque la struttura è quella.

 

[KILLERIX]

Il tag, forse sbaglio, lo userei per cercare le varie guide, usando le parole chiavi, un po' come funziona qui: inserisci HTML, PHP, CSS e ti trova tutti i post con quei tag. Quindi, dovrei creare tbl_tag per inserire i vari tag e una tbl_guida_tag per associare una guida a uno o più tag.

Invece, sono un po' perplesso per quanto riguarda la tabella guida: vorrei costringere l'utente, tramite varie textarea, a compilare sempre nello stesso modo una guida. Ovvero: una textarea per il "titolo", una per "caratteristiche", una per "immagini", una per "osservazioni", una per "altro"... o altre cose del genere, così da non avere un attributo unico nel DB che prenda tutto.

 

[Antonio De Marco]

Ah okey perfeto, beh si a questo punto sono d'accordo per i TAG che in qualche modo sono anche utili per le categorie se vogliamo anche vederla sotto questo aspetto.
Per quanto riguarda la perplessità non esserlo, è importante che all'interno di una tabella i dati memorizzati nelle colonne siano di valore atomico (insomma un dato solo e non tutti accorpati). A tal proposito ti rimando al concetto di Normalizzazione con 1NF, 2NF e 3NF (Normal Form). https://it.wikipedia.org/wiki/Norma...oni_della_1NF_.28atomicit.C3.A0_dei_valori.29

 

[KILLERIX]

Grazie mille per le delucidazioni.
Invece ho un dilemma sulla tbl_valutazioni. Io la farei [utente_id, guida_id, voto_id] per far si che un utente non possa valutare due volte la stessa tabella. Potrebbe essere l'approccio giusto? E farei lo stesso per le visualizzazioni e fare in modo che un utente, anche se entra 100 volte a vedere una guida, non possa incrementare le views... ma ho trovato in internet un altro approccio: far in modo che un utente possa incrementare il contatore delle views una volta per sessione. Usando una tabella e views univoche, avrei un contatore preciso al 100%; col secondo metodo non rappresenta le views uniche effettive, ma avrei meno rogne dal punto di vista del DB. Quale potrebbe essere il migliore? Secondo me il secondo approccio è migliore. In fin dei conti, le views le utilizzerei solo per calcolare le guide più viste ed, effettivamente, se lo stesso utente in più sessioni visualizza sempre la stessa guida significa che è apprezzata. Così, basterebbe mettere nella tbl_guide un attributo che mi conti le views.

 

[Antonio De Marco]

Il primo dilemma non mi è chiaro perchè a prescindere da come strutturi la tabella qualche controllo prima di inviare la query lo faresti e quindi non permetteresti neanche di visualizzare il modulo di votazione, non trovi ?
Per quanto riguarda le views puoi gestirla come meglio credi, alla fine sta a te decidere il grado di "veridicità" di ogni singola views.