Creazione tabelle relazionate: consigliatemi

[Drummelo]

Ciao a tutti.

Come sapete sono nuovo in materia ma nelle ultime settimane sto leggendo una quantità impressionante di informazioni su php e mysql.

Detto questo, vorrei un consiglio sulla creazione di un database ed eventualmente su cosa concentrarmi e andare a studiare bene.

Vorrei realizzare un database per un erboristeria che ha anche prodotti di sanitaria, ortopedia, pediatria e altri.
Inizialmente, nell'ignoranza, pensavo di fare tutto con una tabella ma ovviamente non è fattibile.
Sono quindi venuto a conoscenza delle relazioni tra tabelle, cosa eccezionale, ma purtroppo mi sono un po perso in tutte queste informazioni.

VORREI PRECISARE che l'intento non è un sito e-commerce. I dati nei database mi servono solo perchè, per fare un sito del genere (che vorrebbe essere più un catalogo che altro) posso fare in modo, tramite php, di visualizzare in automatico i dati che servono, pagina per pagina.

La struttura vorrebbe essere questa:

DATABASE
|
Tabella contenente tutti i tipi di sezioni (erboristeria, sanitaria, pediatria, ecc..)
|
TANTE Tabelle (una per ogni sezione).

Quello che in sostanza vorrei fare è mettere i prodotti di ogni sezione/categoria all'interno della propria tabella, e in una tabella separata inserire i nomi delle sezioni/categorie.

La domanda è questa.
Il ragionamento è corretto o sto sbagliando nella concezione vera e propria?
Se è corretto, come realizzo tutto ciò?

Mi affido alle vostre mani e ai vostri consigli che fino a questo momento sono stati utilissimi e determinanti.
Quindi grazie in anticipo!

[deleted_29]

Originariamente inviato da Drummelo

Quello che in sostanza vorrei fare è mettere i prodotti di ogni sezione/categoria all'interno della propria tabella, e in una tabella separata inserire i nomi delle sezioni/categorie.

La domanda è questa.
Il ragionamento è corretto o sto sbagliando nella concezione vera e propria?

le informazioni sono troppo poche per poter già dare una risposta, in quanto bisognerebbe fare un minimo di progetto logico.

Per andare terra-terra (fermo che la risposta "giusta" è "dipende", posso andare avanti tranquillamente un 20 giorni a discutere tutti i perchè ed i percome), così a naso direi di no.

Una tabella "master" (coi tipi), e UNA tabella "slave", con dentro il tipo di sezione (in un campo).

Non mi intendo un granchè di farmacie, ma direi qualcosa del tipo

tipi prodotti

1,sanitaria, "prodotti per la blablabla"
2,ortopedia, "prodotti blablabla"
3,erboristeria, "prodotti per blablabla"

...
prodotti

1,XXX001, "prodotto sanitario1"
1,XXX002, "prodotto sanitario2"
1,XXX003, "prodotto sanitario3"
2,AAA001, "prodotto ortopedia1"
2,AAA002, "prodotto ortopedia2"
2,AAA003, "prodotto ortopedia3"

questo ti consentirà in modo semplice di fare interrogazioni del tipo
"tutti i prodotti delle sanitarie".

Anzi ti dirò di più: visto la "niubbezza" de-normalizza (ragionevolmete) la descrizione del tipo, ossia

1,sanitaria,XXX001, "prodotto sanitario1"
1,sanitaria,XXX002, "prodotto sanitario2"
1,sanitaria,XXX003, "prodotto sanitario3"
2,ortopedia,AAA001, "prodotto ortopedia1"
2,ortopedia,AAA002, "prodotto ortopedia2"
2,ortopedia,AAA003, "prodotto ortopedia3"
...

qui ti risparmi join continui, sia in ricerca, sia in reportistica, nell'ipotesi che la descrizione di un tipo non vari (da sanitaria non diventa sanitariO)

In realtà se lo progettassi io userei "trucchettini sporchi" (facendo sparire ad esempio la tipiprodotti), ma nel tuo caso direi di evitare "sconvolgimenti" e mantenere una certa linearità.

[optime]

usa una sola tabella per gli articoli. nel record dell'articolo metterai anche il riferimento alla sezione, per poi fare un'estrazione rapida e mirata

[Drummelo]

Innanzitutto grazie per le risposte.
So che detta così è molto difficile per creare un progetto concreto, e cerco di spiegarmi meglio.

In dettaglio ciè che vorrei fare è questo..
Un index con le varie categorie (erboristeria, sanitaria ecc..), una pagina CATEGORIA contenente le sottocategorie della categoria scelta (affaticamento, stress, insonnia, ecc), una pagina ELENCO contenente la lista dei prodotti della sottocategoria scelta (ad esempio tutti i prodotti della sottocategoria STRESS) e infine una pagina DETTAGLIO dove dice in dettaglio il prodotto selezionato nella pagina ELENCO.


PAGINA INDEX -(clicco sulla categoria)->
PAGINA CATEGORIA - contiene le sottocategorie -(clicco sulla sottocategoria)->
PAGINA ELENCO - contiene l'elenco prodotti della sottocat. scelta -(clicco prodotto)->
PAGINA DETTAGLIO - contiene in dettaglio le informazioni del prodotto.

Cioè, in pratica io con 4 pagine php precise voglio creare l'intero sito internet. A livello php ci sono riuscito, ma è la concettualizzazione e la creazione delle tabelle che non mi torna.

Detto questo, in sostanza (nella mia testa) dovrebbe esserci una tabella CATEGORIA (erboristeria, sanitaria ecc..), una tabella SOTTOCATEGORIA (contenente le sottocategorie e che collega le categorie ai prodotti) e una tabella PRODOTTI (in cui a quanto ho capito dovrò mettere TUTTI i prodotti esistenti nel negozio, sia essi sanitaria o erboristeria o quant'altro).

Ovviamente voglio fare questo piccolo progetto innanzitutto per imparare la relazione tra tabelle, è un bell'argomento. Quindi vorrei capire COME orientarmi LOGICAMENTE nella creazione del sistema di tabelle, così in futuro ci posso ragionare da solo concretamente. Per quanto riguarda i comandi da eseguire penso (e spero!) di poterci arrivare leggendo un po qua e la i vari argomenti.

@franzauker:nell'esempio che mi hai fatto tu in pratica attribuisci un numero ad una categoria, e nell'altra metti quel numero a ogni prodotto della categoria corrispondente esatto? Ho capito il ragionamento.
Il punto è che da tutto il sistema funzionale che mi hai dato, non riesco a estrapolare una pagina php in cui posso stampare SOLO le sottocategorie che sono contenute per ogni categoria principale. Capito il mio problema?

@optime: è esattamente ciò che avevo fatto io, ma incappo nel problema delle sottocategorie stampate nella pagina in php...

[optime]

la sottocategoria è una novità, ma non un ostacolo.

avrai quindi

tab categoria
- id
- descrizione

tabella sottocategoria
- id
- id categoria
- descrizione

tabella articoli
- id
- id sottocategoria
- descrizione
- altri valori

that easy!

[Drummelo]

optime, ti giuro su mia madre che avevo fatto uno schema su un foglio di carta IDENTICO a quello che mi hai appena postato adesso!

Lo stavo seguendo, quando ad un tratto mi sono reso conto che la tabella CATEGORIA non mi serve perchè posso tranquillamente incorporarla nella tabella SOTTOCATEGORIA, e così ho fatto la seguente:


tabella sottocategoria
- id
- nome_categoria (diversamente da id categoria)
- descrizione

tabella articoli
- id
- nome_categoria (diversamente da id categoria)
- descrizione
- altri valori

Mi sono accorto di non avere la necessità di avere una tabella CATEGORIE in relazione a come ho impostato il sito.
Se però sbaglio ditelo!!

Grazie infinite per avermi aperto gli occhi!!! Vi voglio bene!! DDDDDDDDD

[Dascos]

Meglio se usi la struttura a tre tabelle.
Fare delle join su numeri è più rapido e eviti errori dovuti a diverso inserimento dei dati (o meglio ti devi preoccupare di "normalizare" i dati di nome_categoria)
Inoltre è più gestibile avere tre tabelle, perchè ti diventa più facile fare "spostamenti" da una categoria all'altra di un prodotto o da una sottocategoria all'altra o di riassegnare una sottocategoria eccetera

[optime]

ascolta dascossss e resta su tre tabelle

[deleted_29]

diciamo che per quello che (con tutta probabilità) è un mini-db puoi scegliere sostanzialmente l'approccio che preferisci.

le differenze si notano quando il db diventa grande (o grandissimo).
---
tornando al merito la tabella categorie ti serve se non la crei dinamicamente, o se hai interesse a che non possano essere facilmente create nuove categoria.

Puoi, ad esempio, fare una SELECT DISTINCT delle righe, ed ottenere tutte le categorie già inserite, da presentare all'utente il quale può sceglierne una.

Questo va bene in una situazione fortemente dinamica, ossia nella quale è normale creare numerose categorie, anzi l'utente può crearle limitandosi ad inserire un nome-categoria non già in archivio: verrà "magicamente" presentata alle prossime immissioni.

Essenzialmente: prendi l'elenco delle categorie dalle righe, le proponi all'utente. Se l'utente ne sceglie una => bon.
Se ne inserisce una nuova => automaticamente ne crea una, senza necessità di avere una tabella "a parte", con i relativi comandi inserisci nuova categoria, elimina categoria etc.
---
Se i "tipi categoria" hanno dei payload consistenti (ossia non solo il nome, ma una caterva di campi) => tabella separata.
Se hanno solo il nome => puoi pensare di "inglobarla" nelle righe.

Quello che invece puoi fare è denormalizzare il campo nome, ossia metterne una copia dentro le singole righe, come già accennato.

Questo nell'ipotesi che il nome non cambi mai (o quasi mai), ti risparmierà un bel po' di lavoro (join) e di rotture di maroni (report).

Dovrai però mettere nella logica dell'applicazione (o del db) qualcosa che ti faccia un UPDATE... set NOME=nuovo-nome where ... se può capitare di cambiarlo
---
Non dimenticare poi un campo SER autoincrementante (se usi mysql), ma ti sconsiglio come chiave primaria, bensì come "cursore", su tutte le tabelle.

Se fai la "tipi" metti una chiave aggiuntiva intera che puoi copiare brutalmente dalla SER [non vedo problemi di concorrenza per un mini-db] al momento dell'inserimento (DA PROGRAMMA, NON DA DB!) questo ti mette al riparo da possibili problemi di disallineamento del campo autoincrementante nel caso di backup-restore-manutenzioni varie
---
Ed infine ragiona un poco su chi sia il "principale" oggetto che manipolerai, ossia quali interrogazioni vuoi fare.
Quello ti permette di stabilire chi diventi il "master", e chi lo "slave".
Dal punto di vista RDBMS è uguale, cambia a livello di prestazioni fare join tra tabelle "sinistre" grandi e piccole.

[Drummelo]

@Dascos e optime: farò come dite. PS: GRAZIE!

@franzauker: penso ci metterò un mese a capire che cosa mi hai scritto nel tuo ultimo post!... Però a parte gli scherzi, penso che tu stia dicendomi cose che sono molto più avanti di ciò che è di mia conoscenza al momento e penso che siano cose che devo sapere per evitare problemi a lunga scadenza, quindi grazie per avermi orientato.

Detto questo ragazzi, io sono infine riuscito a creare ciò che volevo (al momento ancora con 2 tabelle ma aggiungerò la terza) senza l'ausilio del JOIN che ancora devo imparare.
Magari tra qualche giorno faccio l'upload di qualcosina cosi capite di cosa sto parlando.

Infine, mi tolgo il cappello e vi ringrazio infinitamente. Siete come al solito UTILISSIMI e necessari, e soprattutto, lo voglio sottolineare, sempre disponibilissimi.

Era una vita che volevo imparare il php e imparare un modo di immagazzinare dati (grazie ai db, che nn conoscevo) e mi avete aperto gli occhi. Grazie davvero..