[SQL] Com'e' meglio organizzare un db?

[/dev/null]

Ho ancora delle domande sull'SQL... Uso MySQL, ma sono domande generiche, valide per qualunque database...

Mi spiego con un esempio per semplificare...
Un utente inserito nel mio database dovrebbe poter avere un numero indefinito (da 0 a 1000 ad esempio) di caratteristiche tutte dello stesso tipo...
Con un linguaggio di programmazione userei senza dubbio un array con dimensione variabile, ma per memorizzarle in un database non so come comportarmi...
Imparai tanto tempo fa che il modo piu' elegante sarebbe creare una tabella apposita con soli due campi: l'userid e un campo per questo valore, quindi se un utente deve avere cento valori diversi aggiungero' cento righe a questa tabella con lo stesso uid... Poi, qunado leggo i dati di ogni utente dal database degli utenti, per ognuno che trovo vado a cercare nell'altra tabella se ci sono righe con l'id corrispondente e in tal caso le carico...
Adesso pero' mi chiedo se questo metodo sia proprio il migliore
Oppure e' meglio (parlo in termini di risparmio delle risorse) mettere nella tabella degli utenti un nuovo campo di tipo testo, dove vado a memorizzare tutte le caratteristiche separandole con un carattere speciale, e poi una volta letta la stringa splittarla?

Devo far girare la mia applicazioncina su un 386 con 128mb di memoria o poco meno... E spero di avere tanti utenti... Quindi voglio limitare al massimo lo spreco inutile di risorse per non essere costretto ad aggiornare la macchina...

[Gianni_T]

la prima soluzione è quella corretta, anche dal punto di vista delle prestazioni. Infatti, usando una megastringa, ogni operazione su questi dati richiederebbe una sorta di parsing: immagina le operazioni di UPDATE e DELETE in cosa si possono tradurre. Tieni presente che MySQL (cme qualsiasi DBMS) è stato progettato ed ottimizzato per manipolare tabelle. La soluzione di unsare un campo testo diventa quasi obbligatoria nel caso in cui tu non sappia a priori ne quanti dati inserire, ne il tipo di dati (es. un albero le cui foglie possono essere qualsiasi cosa)

Per altri dubbi siamo quì

[Tymba]

se i valori di cui hai bisogno sono solamnte true o false puoi usare un intero per memorizzare queste informazioni senza scomodare una stringa o una tabella.

esempio:

poniamo che hai un'area privata e l'utente in relazione ai diritti può accedere o meno alle varie zone.

zona 1
zona 2
zona 3

usando un intero per gestire questa cosa hai a disposizione 32 "variabili"


0000 0000
0000 0000
0000 0000
0000 0000

uno schema di questo genere vieta l'accesso a qualsiasi area.

se devi attivare l'accesso alla zona 2 valorizzerai a 1 il bit 2 quindi

0100 0000
0000 0000
0000 0000
0000 0000

riconverti il binario in intero e lo memorizzi

per leggerlo ovviamente dovrai convertire l'intero in binario.

per fare questo avrai sprecato lo spazio di 4 byte e basta.

se scegli la soluzione di una tabella avrai la necessità di memorizzare come minimo i 4 byte per l'intero di riferimento all'id utente e come minimo 1 byte per la memorizzazione del valore, questo unito allo spazio necessario per la memorizzaione della struttura della tabella (mysql memorizza in un file diverso ogni tabella).

ovviamente non farti vincere dalla pigrizia e memorizzare quindi una stringa di 32 caratteri perchè la stringa è parecchio più dispendiosa di un integer in termini di spazio ed anche come routine di gestione è più esosa dei numeri e bit.

buon divertimento, questa è una bella "sfida" se la raccogli bene per risparmiare risorse all'osso.

per maggior info puoi andare sul sito di mysql e guardare i vari tipi di dati e scegliere quello che calza meglio alle tue esigenze.

[/dev/null]

Grazie
(Per ora ) non ho piu' dubbi


@Tymba: i valori che memorizzare sono interi (4 bytes) o stringhe (di dimensione indeterminata) quindi in entrambi i casi dovrei usare stringhe e, a quanto pare, e' meglio usare tabelle apposite

[carlo2002]

scusa, ma una delucidazione adesso servirebbe a me.

di solito progetto delle tabelle ke contengono tutti i campi necessari corrispondenti ai valori e questo mi porta a sprecare risorse per quelli ke rimangono vuoti. mi interessa il sistema ke hai illustrato ke in pratica è una relazione uno-a-molti e penso in qualke caso di poterlo adottare.

xò mi sfugge un particolare, quando dici:

Originariamente inviato da /dev/null
Imparai tanto tempo fa che il modo piu' elegante sarebbe creare una tabella apposita con soli due campi: l'userid e un campo per questo valore

cosa intendi dire, l'userid è già un valore, quindi basterebbe un campo solo e non due, oppure ci metti vicino ad esempio il nome?

[/dev/null]

Intendo un campo dove viene memorizzato l'userid dell'utente a cui e' assegnato il valore, ed uno per il valore...

Ti faccio un esempio pratico e stupido... Ho un database degli utenti cosi' fatto:

USERID   USERNAME  PASSWORD
0        Pippo     pippo
1        Ciccio    ciccio
2        Bingo     bingo

Ogni utente puo' avere uno o piu' immagini (o anche nessuna), che raccolgo nel database immagini:

USERID    IMAGE
0         pippo.gif
1         ciccio.gif
0         pippo2.gif
0         pippo.jpg
1         ciccio.png

Quando poi ho bisogno di sapere che immagini ha l'utente con id 1 vado nel db immagini e le cerco tutte...




Ho aperto questo thread per sapere se era meglio gestire una cosa del genere nel modo appena illustrato oppure come nel seguente modo:

USERID   USERNAME  PASSWORD    IMAGE
0        Pippo     pippo       pippo.gif~pippo2.gif~pippo.jpg
1        Ciccio    ciccio      ciccio.gif~ciccio.png
2        Bingo     bingo

Cosi' mi sarebbe bastato caricare la stringa IMAGE nel database degli utenti e poi splittarla...
Questo metodo e' piu' scorretto pero'

[VaLvOnAuTa]

Io per queste situazioni uso una tabella apposita.
L'unica difficoltà (se proprio vogliamo considerarla tale) è un eventuale aggiornamento (aggiunta o cancellazione) di un record, ma con semplicissimo algoritmo si risolve anche questo

[carlo2002]

personalmente non userei la splittatura, mi sembra + comodo e corretto l'uso di un'apposita tabella, ma devi proprio stare così stretto di memoria?

grazie x la delucidazione, ma avevo capito male, in fondo x le immagini faccio già così xò mi hai fatto pensare...

senza fare esempi complicati xò supponendo ke in realtà si debbano trattare molti dati, una roba del genere..?:

USERID   USERNAME  PASSWORD
0        Pippo     pippo
1        Ciccio    ciccio
2        Bingo     bingo


USERID    NOME_VALORE   VALORE
0         nome          tizio
1         nome          caio
0         tel.1         12345
0         tel.2         54321
1         peso          80

in pratica mi permette di memorizzare solo i
valori esistenti, xò si crea una ridondanza nei
NOMI_VALORE ke xò potrebbe essere risolta con
una relazione ad una tabella dei NOME_VALORE.

mi sto inventando l'acqua calda, è una boiata
pazzesca o cosa ?

[piero.mac]

USERID   USERNAME  PASSWORD
0        Pippo     pippo
1        Ciccio    ciccio
2        Bingo     bingo

tab_id    USERID   DESCR    TIPO
0         0        tizio    BIANCO
1         2        caio     GIALLO
2         0        12345    CUCUMELO
3         1        54321    NONE
4         1        80       NONE

Ogni tabella dovrebbe avere una chiave PRIMARIA, quindi univoca e meglio se numerica. Molto meglio cos' che due soli campi.

[carlo2002]

ok, mi era sfuggito, ma l'idea è valida o può portare dei problemi?