Organizzazione tabelle db concessionario

[StefanoV]

Salve a tutti,
sto facendo il sito di un concessionario...

Come sapete le auto possono avere numerosi optional, e mi chiedevo qual'è il modo migliore per organizzare questi dati nel db...

1. unica tabella con campi Booleani del tipo:
- airbag
- abs
- servosterzo
- ecc...

2. 3 tabelle con relazione molti a molti del tipo:
- id auto

- id_auto
- id optional

- id_optional
- nome optional

però in questo caso avendo ad esempio 100 auto con 20 optional l'uno verrebbe una tabella enorme...

3. 2 tabelle... e la funzione serialize ovvero:
- id auto
- optional (long text)

- id_optional
- nome_optional

e dentro il campo optional ci metto l'array serializzato cn tutti gli id degli optional...
però in questo caso dovrei fare la query normale, unserializzare, e rifare la query x ottenere i nomi degli optional...


io ho scelto la prima + pacchiana opzione... ovvero tabella cn campi booleani... e un campo testuale con scritto "altro" per gli optional aggiuntivi (ke nel secondo caso potrebbero essere aggiunti alla 3 tabella)

voi che dite, qual'è il miglior metodo per tabelle che conterranno moltissimi dati?

[StefanoV]

Forse ho scritto in modo un pò confusionario... ricapitolando:

Metodo 1 = Meno risorse, meno query, ma difficolta ad inserire altri optional, e rompimento a non poter ciclare i campi per il print...

Metodo 2 = + veloce da implementare, possibilità di aggiungere altri optional in seguito, ma che succede quando la tabella di relazione avrà sui 10000 records?

Metodo 3 = Meno risorse da sprecare, ma campo enorme di testo per il serialize, e utilizzo di molte query per otterenere il nome degli optional dagli id unserializzati...


Quale uso? la 2 è la migliore, ma qualcuno sa ke può succedere se si riempie la tabella?

[StefanoC]

Ciao Stefano,

secondo i sacri testi
l'opzione 1 sarebbe da evitare. (spreco di spazio e prestazioni, specie se hai tante auto che non prevedono molte opzioni)

direi l'opzione 2, dal momento che la 3 l'ho capita fino ad un certo punto...

per il numero dei record non mi farei impressionare: i DB sono ottimizzati per questo....

ciao
stefano
---------
Se cerchi su internet "progettazione di DB" trovi molto...
ti segnalo però subito:
http://www.dea.unipi.it/db/UtentiEA/...20database.ppt

[StefanoV]

Grazie mille... alla fine infatti ho usato la 2... mi trovo anche meglio, l'unico dubbio era la pesantezza...spero non dia problemi

[StefanoC]

Originariamente inviato da StefanoV
Grazie mille... alla fine infatti ho usato la 2... mi trovo anche meglio, l'unico dubbio era la pesantezza...spero non dia problemi

Ti suggerisco di fare una simulazione:
crea un db fittizio e riempi le tabelle a più non posso (che ne so.. copia/incolla molto corposi).
poi vedi se il db regge o se va in palla con più query simultanee...

ciao,
stefano