tabella pesante vs molteplici tabelle

[dany0]

come da titolo vorrei sapere

se coviene avere una tabella pesante per modo di dire (in cui ad esempio ci sia un campo txt che suddivido poi io in vari dati) oppure molteplici tabelle (con molteplici a quel punto intendo un 300 tabelle....)??????io opterei cosi' a naso per la prima.....

[gianiaz]

Non è questione del tanto o poco, ma devi strutturare il tuo db seguendo dei principi:

dividi con le tabelle concetti diversi ed evitando la ridondanza dei dati:

ad esempio se vuoi fare un db di film puoi usare una tabella fatta cosi:

+---------+-------------+------------------+
| id      | titolo      | attori           | 
+---------+-------------+------------------+
| 1       | matrix      | k.reaves         |
+---------+-------------+------------------+
| 2       | matrix 2    | k.reaves         | 
+---------+-------------+------------------+
| 3       | matrix 3    | k.reaves         |
+---------+-------------+------------------+

oppure nei fai 2 cosi:

+---------+-------------+------------------+
| id      | titolo      | id_attore        | 
+---------+-------------+------------------+
| 1       | matrix      | 1                |
+---------+-------------+------------------+
| 2       | matrix 2    | 1                | 
+---------+-------------+------------------+
| 3       | matrix 3    | 1                |
+---------+-------------+------------------+

+------+---------------+
| id   | attore        | 
+------+---------------+
| 1    | k.reaves      | 
+------+---------------+

in questo modo eviti di scrivere più volte il nome dell'attore (quindi risparmiando spazio e tempo), ed eviti di scrivere una volta k.reaves, un'altra k rives, un altra keanu reaves, chianu rivs ecc ecc

eviti ridondanza ed errori.

Questo vale per un esempio banale, figuriamoci con progetti + complessi.

ciao

[dany0]

bhe grazie cmq...ma nel mio caso al cosa è alquanto complessa....

ovvero

ci sono tanti elementi A .Ogni elemento A può avere uno o più elementi B, con la necessità di saperne il numero.

io quindi avevo pensato

tabella_elementi_B contenente le caratteristiche delgi oggetti B

tabella_elementi_A con un campo mettiamo "proprietà" di tipo longtext contenente ad esempio : idb_1-4,idb_2-5 ecc ecc dove idb_x indica l'id dell'elemento in b e il numero dopo il meno la quantità posseduta....cosi' caricando il campo proprietà e suddividendo i dati ho sia l'id per poi eventualemnte prenderne le sue caratteristiche dall'altra tabella , sia la quantità posseduta

faccio una grossa cavolata?????

l'altra idea era avere la stessa tabella_elementi_A con in proprietà il nome della tabella delle proprietà dell'id selezionato in quella riga.nella nuova tabella (però quindi una per ogni elemento di A) avrei tutte le proprietà senza longtext ma con due campi semplici.....


mbo

[13manuel84]

non ho ben capito la tua necessità forse, ma se si tratta di un'ssociazione n<->n io farei due tabelle A e B ed in più una tabella associazioni che avrà A_id, B_id e un count per tener traccia di quanti B sono associati ad A, così con una sola query in estrazione avrai A, B e numeri di B associati ad A.

So che è un pò difficile spiegare queste cose tramite un forum, ma spero di essermi spiegato un pochino.

Se non è chiaro chiedi pure, se invece ho canato e non ho capito la tua richiesta sorry

[dany0]

si bhe in pratica la seconda ipotesi...ok tnx

[dany0]

si ora che ho creato le tabelle decisamente la tua è una soluzione semplice e pulita good!!!!!!!!!!!!!!!!!!!!!!!!! tnx

[13manuel84]

son contento che ti vada bene!

ho iniziato ad usare questa soluzione dopo che mi sono trovato a dover mettere le mani su un lavoro in cui c'era una tabella A collegata ad una tabella B e la struttura era questa:

tab A

id        B_id
1        1-2-7-9
2        3-5-8

e per far le query dovevo andare a tirare in ballo substr, replace e funzioni che andavano a rallentare notevolmente il sistema quando le tabelle diventavano consistenti.

Mentre con la struttura sopra con una query velocissima ho tutto quello che mi serve


poi comunque dipende sempre dalla mole di dati su cui devi lavorare; ma personalmente preferisco spendere un pò più di tempo nel progetto che piangere poi quando tutto è finito e accorgermi di aver fatto una boiata

[gianiaz]

giustamente, segui la teoria dei db relazionali, quando ci sono delle relazioni molti-a-molti vanno scomposte in più relazioni uno-a-molti.

questo viene fatto con l'aggiunta di una tabella di appoggio.

N.B. Non volevo minimizzare la tua soluzione, solo segnalare che studiando un po' di teoria si arriva a queste soluzioni senza scervellarsi.

[13manuel84]

si si la teoria l'ho studiata, e la so
ma ho preferito spiegarla con un esempio pratico (in cui mi sono imbattuto), in modo che si capissero meglio i vantaggi di questa soluzione.

io mi scompongo sempre una relazione n-n crandomi una tabella di appoggio, ma purtroppo quando si deve lavorare su progetti non propri si vedono le cose più brutte sulla faccia della terra