Newsgroup: it.comp.www.php
Titolo: campi booleani o stringa?

ho scritto un software in ambiente WAMP per la gestione di un questionario.
nel questionario ci sono tante domande con risposta vero - falso che io ho
tradotto nel software con delle checkbox.
nel DB queste risposte le ho tradotte con un campo di tipo enum (0,1)
assegnando 0 se falso e 1 se vero.
Cos� come � fatto va bene, per� ora mi sorge un dubbio allo scopo di
migliorare l'efficienza del programma: 
dato che queste domande nel questionario sono tutte vicine e sono
abbastanza (supponiamo 5), potrei invece che fare un campo per ogni
risposta, cio� 5 campi di tipo enum (0,1), farne uno unico di tipo char(5)
dove inserirei i 5 valori 0 o 1, 
cio� per esempio invece di avere 5 campi cos�:
c1 enum(0,1),c2 enum(0,1),c3 enum(0,1),c4 enum(0,1),c5 enum(0,1)
potre averne 1 solo cosi:
c varchar(5)
cos� invece di avere: 
c1='1'
c2='0'
c3='0'
c4='1'
c1='0'
avrei:
c='10010'
tanto poi MySQL contiene delle funzioni di testo per estrapolare da un
campo il 3 carattere e cos� via...
secondo voi cosa conviene fare?
una tabella di un DB per essere efficiente quanti campi non deve superare
(come numero)?
cioa e grazie
alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 alessandro
cerca di far lavorare il db con dati piu' facili da elaborare per lui.. 
compattare 5 bool in un varchar non conviene..
cosa succederebbe se dovessi cercare tutti quelli che hanno risposto ad 
una determinata domanda con un "si"? il db sarebbe costretto a convertire 
N stringhe per arrivare al risultato..
ti consiglio anche di slegarti dal vincolo di avere al massimo 5 
risposte..
una possibile soluzione sarebbe un db simile a questo..
Users
---------------
user_id INT
user_name VARCHAR
Questionnaires
---------------
questionnaire_id INT 
questionnaire_title VARCHAR
Questions
---------------
question_id INT
question_text VARCHAR
Question_series
---------------
questionnaire_id INT 
question_id INT 
Anwers
---------------
user_id INT 
questionnaire_id INT
question_id INT
answer BOOL
-- 
www.iuz-lab.info

 ciao, f.
Bhè adesso non esageriamo.
Certo, avere un char(5) invece che 5 bool diversi è sconveniente, ma
se adesso ha nel database (come penso) una tabella con una colonna per
risposta, a mò di excel, è normale cercare soluzioni alternative
'fantasiose'.
Se lavorasse su postgres potrebbe, ad esempio, usare un campo di tipo
array, che a seconda di mille fattori potrebbe anche rivelarsi molto
efficente (cosa che personalmente dubito, per questi approcci
solitamente si usa il metodo descritto da iuz)

 solitamente si usa il metodo descritto da iuz)
Questo esattamente COSA c'entra con quanto sopra ?
PS: Uso PostgreSQL da anni. MAI usato gli array, infatti, Mai.
ciao, f.

 conseguenze a livello penale e la perdita del diritto di voto.
Stra-quoto. Aggiungerei l'asportazione delle falangi ungueali della mano
sinistra e la radiazione dall'albo degli informatici e l'iscrizione di
ufficio a quello dei peracottari.
	Y.

(come numero)?
Non funziona cosi' :-) - puo' darsi che il "numero di colonne" impatti in
modo sensibile sulle prestazioni in SQLite3 (lo faceva per DB3 Nantucket)
ma i parametri veri sono altri.
Ha piu' senso - lo aveva in MySQL 3 e PostgreSQL 7 - dire "Cercare di non
avere campi varchar" (non "averne pochi": proprio "nessuno". Da uno a due
non cambiava nulla, da uno a zero qualcosina si').
Ma in realta' il tuo costo complessivo e' dato solo in minima parte dalle
"prestazioni del database", anche perche'... QUALI prestazioni? Quelle in
ricerca? In aggiornamento? Hai provato a immaginarti come si fa un UPDATE
di c3 da 0 a 1 quando c3 è il quarto carattere di "c char(5)"? E come fai
a fare ricerche del tipo "Almeno 3 risposte affermative su 5"?
(D'altra parte... con char(5) rispondi bene a domande come "Trovami tutti
quelli che hanno dato tre risposte consecutive uguali").
Un altro costo che non devi sottovalutare e' quello di manutenibilita' ed
estendibilita' del codice. Caso disgraziato: una di quelle cinque domande
riguarda il titolo di studio... "Laurea Si/No". Le prime avvisaglie della
tempesta perfetta arrivano quando il cliente ti cambia il campo booleano,
da Laurea Si/No a Laurea, Laurea Breve, No Laurea. La prima volta è forte
l'impulso a cavarsela con quella che chiamo la terna booleana (0, 1, 2).
Quando compare la maturità artistica, non ti basta l'esadecimale; e credi
a me, la gestione è diventata roba da sbolognare al tuo peggior nemico.
Inoltre, riutilizzare il codice è pressoché impossibile, e finirai, quasi
di sicuro, con l'avere campi "orfani" o valori fantasma che si tramandano
di generazione in generazione.
Io ho visto roba cosi' in sistemi nati in (argh) COBOL in ambito bancario
e traghettati sul uebbduepuntozzero, ultima bacchetta magica fantasizzata
dal management per trasformare lo sterco di tirannosauro in oro - non che
funzioni, sia chiaro, ma qualche venditore di olio di serpente che ancora
ci prova si trova, oh se si trova.
Ma tornando a noi: "che fare?".
Be'. Prima studia bene il problema. Poi guarda COS'E' che, davvero, porta
via tempo. Sono le ricerche? (Indexes! Slow Query logging! Forme normali!
Lookup tables! Cache! EXPLAIN!) Gli update? (Slow/batch update; partition
sets; Indexes; Slow Query logging)? Il rendering delle form? (Tabulazioni
e paginazioni, CSS, Y-Slow, W3C compliancy (non sembra, ma aiuta)...).
Se ti trovi in una situazione dove ridefinire i campi (di cosi' poco come
accorpare cinque boolean in un char(5)) ti cambia la vita, vuol dire IMHO
che sono stati fatti errori piu' a monte; e probabilmente piu' d'uno. O -
possibile anche questo - che e' il momento di considerare cose come VM, e
database distribuiti, e saggiare il terreno nel campo cloud.
Leonardo che non ha imparato dai propri errori, però ne ha fatti parecchi
-- 
The cock doth craw, the day doth daw,
the channerin' worm doth chide:
gin we be mist oot o' oor place,
a sair pain we maun bide.