Newsgroup: it.comp.lang.visual-basic
Titolo: [?OT] Campo "MultiBoolean" in database

Disturbato dal numero troppo grande e in aumento dei campi delle varie
tabelle del mio gestionale, ho ipotizzato una ristrutturazione,
particolarmente per i campi Boolean convertendoli e "accorpandoli" tutti in
un unico campo testo dove ogni carattere ha un significato e il suo valore
indica lo stato (On/Off). Fermo restando che questo non serve a ridurre lo
spazio occupato sul database (per questo si potrebbero usare variabili
numeriche da trattare come collezione di bit), ma solo il numero dei campi
di una tabella, alleggerendo così (suppongo, ma non ne sono certo) il lavoro
del motore.
Ovviamente mi scontrerei con altre problematiche di non poco conto, ad
esempio: Esporre in colonne diverse in una griglia tali informazioni,
consentire semplici (per l'operatore) ricerche nella stessa, composizione
dei comandi SQL di Select ... Where o, peggio, di Update Tabella Set
Campo='...', etc.
Mi/vi chiedevo: Perchè quelle menti piene di idee non hanno previsto (con
Access e, ma non ne sono sicuro, con SQL Server) un tipo di campo BooleanS
da trattarsi, per esempio, con una sintassi del tipo RS!MYBOOLS(15) a
indicare univocamente e chiaramente il bit 15 del campo (unico) MYBOOLS?
Ammetto la mia totale ignoranza a proposito di eventuali campi/vettore (pur
a una sola dimensione) nei database. Non so se sono possibili, nè come si
trattano.
Insomma un unico campo che sia, di fatto, un "insieme" con possibilità di
riferimento dei singoli "elementi".
Avete qualche idea/artificio in tal senso (valida sia per Access che per SQL
Server)? Grazie.

 indicare univocamente e chiaramente il bit 15 del campo (unico) MYBOOLS?
In realtà è una struttura del tutto prevista, e anche molto semplice. Sempre
che tu stia usando una modellazione relazionale del DB. In sostanza, la
modalità corretta di realizzare quanto chiedi è:
Tabella degli elementi: quella che adesso è la tua tabella, tranne i campi
che vuoi BooleanS
Tabelle dei Booleans: Contiene descrizione ed altro dei campi booleanS
Tabella [Relazione] dei valori booleans: contiene
ID_Elemento - ID_Booleans - Valore [as bit]
Questo ti consente una notevole rapidità di esecuzione, potendo utilizzare
inner join indicizzati.
E, soprattutto, immagina quanto sia comodo passare da una situazione in cui
hai 7 campi BooleanS, a 8, 9, 1000 campi Booleans.
In particolare con Sql-Server, hai anche la posibilità di crearti trigger
che ti gestiscano autonomamente l'eliminazione dalla tabella di relazione
dei record corrispondenti a elementi che vengano eliminati dalla tabella
principale, nonchè di effettuare insert 'di default' ad ogni insert nella
tabella degli elementi.
Ciao
Alberto

 hai 7 campi BooleanS, a 8, 9, 1000 campi Booleans.
Sì, ma così, mi sembra, anzichè ridurre il numero dei campi, li aumento,
ovvero li distribuisco, incrementandoli, su più tabelle... :-(
Allo stato non ho la benchè minima difficoltà nell'aggiungere campi (il
sistema adegua automaticamente gli archivi ad ogni aggiornamento), volevo
"semplicemente" ridurre il numero dei campi in una tabella per favorire il
lavoro del motore. Devo anche specificare che del valore di quei boolean io
ne ho praticamnte sempre bisogno, quindi, dovunque essi siano, li dovrei in
ogni caso caricare. In questo stava la malsana idea: Metto tutto in un solo
campo, poi lo tratto. Ovviamente i problemi sintattici cui accennavo mi
hanno posto la questione.

 hanno posto la questione.
Immaginavo che i vari campi boolean non fossero 'accessori', ma sostanziali.
Io, comunque, insisto (io faccio pressochè sempre così) sulla tabella delle
relazioni. L'ottimizzatore di query lavora molto bene sugli inner join, per
cui le performance vanno molto bene.
Considera che se hai un indice sull'ID degli elementi, una query ben
strutturata andrebbe prima sulla tabella delle relazioni, estrarrebbe i
record che soddisfano le condizioni sui booleani, e solo a questo punto,
operando quindi su un sottoinsieme generalmente molto ristretto degli
ID_Elementi, andrebbe sulla tabella elementi (la più grossa, quindi la più
frammentata sui cluster, quindi la più lenta), andando dritto all'obiettivo
usando l'indice.
Ciao
Alberto

 rapidissimo. Un campo testo, invece, è estremamente più complesso
Certo, comprendo perfettamente la differenza nei tempi di trattamento dei
vari tipi di campi.
Ho però la certezza (ri-farò delle prove precise) che una tabella di 10
campi interi sia molto più veloce (e non necessariamente in modo
direttamente proporzionale) della stessa con 100 campi interi. Anche questo,
se vogliamo, è logico, no?! ;-)
Grazie di tutto, Albe.

 se vogliamo, č logico, no?! ;-)
Direi di sě.
Ma il punto su cui mi esprimevo era fra una tabella con dieci booleani e una
con un integer che rappresenti binariamente i dieci booleani, o peggio
ancora con una stringa che contenga 10 char ognuno dei quali rappresenta un
boolean.
Le dimensioni del record causano rallentamento, perchč frammentano la
tabella in piů cluster. Questo č un motivo in piů, a mio parere, per forzare
l'accesso a tabelle piccolissime, per una preselezione dell'elenco dei
record da elaborare, e poi accedere alla tabella degli elementi 'pesanti'
con un accesso diretto e ben indicizzato.
Ciao
Alberto

 con un accesso diretto e ben indicizzato.
Sě, chiarissimo. Ed č anche il motivo per cui volevo ridurre la mia tabella.
;-)

 > Le dimensioni del record causano rallentamento, perchè...
Un po' di sana masturbazione mentale, con annessa pura accademia, ogni tanto
serve a dimenticarsi dei post fotocopia su Access2k.
Alberto

 serve a dimenticarsi dei post fotocopia su Access2k.
Oddio, credevo di aver capito e pensavo ti riferissi a quello di The FOG,
ora mi è venuto un dubbio... c'è un 2k di troppo che non mi torna... C'è
qualche post in giro che parla del problema per cui ho aperto (solo qui)
questo topic?

 questo topic?
Tranqui...
mi riferivo ai 512 post/giorno su come mai un sw fatto per Access97 non va
con Access2k.
Ciao
Alberto

 non va con Access2k.
*fiu!* per un attimo ho tremato vedendo access e 2k insieme ,  pensavo alla
mia cantonata che ho preso ^_^
cmq come al solito ritornando IT : Sono stupendi questi post , stupendi da
leggere il NG come se fosse un bel libro ... anche se poi giri pagina e
ritorni a topolino e alla dura realta' .. cmq spero un giorno di arrivare
anche io a dibattermi su argomenti + disparati come fate voi ! eh eh ..
massi' riesumiamo un termine che non vedo da un po .. siete voi GURU del ng
che mi fate rimanere sempre piu' ammaliato dal mondo della programmazione !
if Exist("YOU") then msg = "Grazzie ^_^"
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/