Consiglio tecnico su architettura DB

[lyllo]

Dopo aver postato il frutto di una giornata di lavoro e sofferenza mi è sopraggiunto un dubbio...
Ho strutturato un db mysql in modo da avere un numero ridottissimo di campi, cercando il più possibile di accorpare le informazioni in stringhe concatenate.
Questo perché ho immaginato che in termini di efficienza, un db "compatto" e con pochi campi vuoti, la presenza di concatenamenti garantisce un maggior riempimento a livello statistico, fosse meglio di un db con tabella da 30 campi che magari contengono un solo numero, ma che quindi statisticamente avrebbe molti campi vuoti (il riempimento non è obbligatorio).

È una mia elucubrazione?
In termini di banda, queries, carico sul server, efficienza meglio molte tabelle con tanti campi piccoli oppure meno tabelle, pochi campi ma "pieni" di Kb di dati?

[Alhazred]

Se non hai il sito su un hosting scarso e gratuito e non prevedi un traffico mostruoso non vedo il problema di banda o utilizzo del server.

Al posto tuo farei un campo per ogni dato che mi serve, altrimenti perderei la comodità di avere un database, a quel punto ti basterebbe un file di testo che occupa ancora meno di un db.
Un db ti da la possibilità ogni volta di selezionare tutti e soli i dati che ti servono, se fai campi con più informazioni, ogni volta prendi anche cose che non ti servono (sprecando banda) e devi poi stare ad usare funzioni per separare i dati che non ti servono e quelli che invece ti servono (appesantendo il lavoro del server).
Un campo vuoto nel db non occupa spazio ad eccezione per il nome del campo stesso, quanto vorrà occupare? 50 Bytes a voler esagerare?

Fa delle tabelle complete di tutti i campi necessari e se per caso ci sono tabelle con dati ripetuti cerca di ottimizzare quell'aspetto.

[lyllo]

intanto STRACOMPLIMENTI per la firma, l'avatar tutto il cucuzzaro!
vecchi ricordi del Necronomicon

tornando al DB, alla fine stavo infatti pensando di ristrutturarlo in modo più flessibile, ottimizzando le tabelle e basta.

unica cosa che mi chiedo è al seguente: come si può gestire una specie di "inventario" degli oggetti di un utente?

con una stringa io al campo "inventario", semplicemente mi limitavo ad accodare l'ID dell'oggetto, ma con una tabella vera e propria, non saprei davvero come comportarmi.

[Grino]

Di solito di riduce in forma normale, anche se in taluni contesti la denormalizzazione può portare i suoi vantaggi. In effetti ritengo che la modellazione di una base dati non sia altro che la ricerca di un equilibrio fra performance e consistenza.

Il non approssimarsi neanche alla 1NF per risparmiare (è tutto da vedere) qualche byte mi sembra un po' esagerato.

Il fatto che su 30 campi ne sia compilato solo 1 dovrebbe farti ripensare la modellazione della base dati. Forse molti di quei campi dovrebbero trovarsi in altre tabelle in cui il record non esiste affatto.

[lyllo]

Originariamente inviato da Grino
Di solito di riduce in forma normale, anche se in taluni contesti la denormalizzazione può portare i suoi vantaggi. In effetti ritengo che la modellazione di una base dati non sia altro che la ricerca di un equilibrio fra performance e consistenza.

Il non approssimarsi neanche alla 1NF per risparmiare (è tutto da vedere) qualche byte mi sembra un po' esagerato.

Il fatto che su 30 campi ne sia compilato solo 1 dovrebbe farti ripensare la modellazione della base dati. Forse molti di quei campi dovrebbero trovarsi in altre tabelle in cui il record non esiste affatto.

intanto grazie per la risposta.
scrivere in modo più semplice avrebbe aiutato anche altri utenti, ma penso di aver colto quello che intendevi dire. soprattutto in merito alla normalizzazione.
in effetti il discorso che stavo iniziando a riconsiderare è proprio quello di separare le tabelle in modo da poter avere più campi gestiti in modo separato.

mi sai togliere la curiosità su questo ipotetico "inventario"?
come potrebbe essere gestito?

[luca200]

Tabella inventario
id utente - id oggetto


Certo che php, con tutto questo....

[lyllo]

Originariamente inviato da luca200
Tabella inventario
id utente - id oggetto

mmmm

una tabella con due campi e lunga milioni di record?

se ogni utente può possedere un numero molto vasto di oggetti...
ci vuole poco perchè la tabella diventi infinita....

[Grino]

Non usiamo parole grosse ... infinito è ben altro.

Supponi di avere 10000 di utenti, ognuno con 10000 oggetti e di avere la tue belle tabelle
Utenti
*id
...altri attributi

Inventario
*idUtente
*idOggetto

Oggetti
*idOggetto
...altri attribbuti

Prima di tutto la tabella Inventario ti fa risparmiare un sacco di spazio, perchè anzichè duplicare gli oggetti e i loro attributi per ogni utente che li possiede hai una sola descrizione dell'oggetto in Oggetti e le fai riferimento tramite un misero numerino che se occupa 4 byte è pure troppo.

Passando ai numeri, Inventario per ogni record coccupa 8 byte (due numeri interi). In inventario avrai 10000x10000 record ovvero 100000000 che moltiplicati per 8 byte a record ti da 800000000 che sono 762 MB. Ma 10000 utenti sono tanti forse più realistico parlare di 2500? e i 10000 oggetti? Forse è più realistico parlare di 1000? Già diventa 2500000 che per 8 byte a reacord sono 19MB e a questo ci credo di più!

Comunque se mai dovessi avere la fortuna di raggiungere cifre ragguardevoli, non già infinito, penso che inizierai a ragionare in termini diversi, quindi inizierai a porti problemi di partitionig, clustering e load balancing, ma il model della base dati resta invariato.

[lyllo]

giusto..
inizi a convincermi!

no, più che altro a rassicurarmi e a farmi passare la paura!

mettiamola con un esempio, così sono più sicuro:

Tabella_oggetti.
id_oggetto
nome_oggetto
prezzo_oggetto

id_inventario
primary_key
id_utente
id_oggetto

tutto qui?
quindi non mi curo delle dimensioni e mi accontento di una tabella a due colonne pienissima di righe, che, nonostante tutto, occuperà poca robbba?

[Grino]

Il concetto è quello. In realtà le tabelle così come pensate presuppongono che un utente possa avere più oggetti purché ogni specifico oggetto sia posseduto non più di una volta, ovvero in inventario la combinazione idUtente+idOggetto deve dare luogo ad una chiave primaria nella tabella. Qualora un oggetto possa essere posseduto in quantità superiori a uno, nella tabella inventario occorre aggiungere un campo quantità.

Inventario
*idUtente
*idOggetto
Quantità

In tal caso idUtente+idOggetto sono chiave primaria e il campo quantità ti permette di stabilire quante volte uno specifico oggetto è posseduto da un certo utente. Se zero il record va eliminato perché inutile.