Newsgroup: it.comp.lang.visual-basic
Titolo: Costruire un db ben strutturato...x tutti

Salve,
ho deciso di aprire un nuovo thread perchè credo che l' argomento
interessi molti, e perchè penso che molti possano dire cose utili a
riguardo. Prendo in esempio la creazione di un db con un unica
tabella, e mi rifaccio a quella che stò utilizzando io, una tabella
dove archiviare mp3 :)) Supponiamo essere questa la nostra tabella:
| TITOLO | AUTORE | ALBUM | ANNO | GENERE | CD |
|               |                 |              |             |                 |       |
Quello che io ho fatto nel mio programma è utilizzare questa stessa
tabella, con in più un campo chiamato "indice" dove assegno ad ogni
record un numero. Quello che si discuteva nell' altro mio post, era l'
utilizzo o meno, di chiavi o indici. Le operazioni che mi interessa
prendere in considerazione su qesta tabella sono quelle di:
1) Ricerca
        |__totale (select * from xxx)
        |__parziale (select * from xxx where...
2) Cancellazione
3) Inserimento
Il problema è sorto perchè visualizzando il risultato delle varie
select fatte su questa tabella, in una listview, cancellando anche
solo un record, mi si sputtanava (mi si sfalzava l' indice della riga
selezionata sulla list, con quello all' interno della tabella) l'
indice dei record nella tabella. Nel mio db non c' era nessun
controllo in fase di inserimento, o meglio, io potevo inserire 100
volte la stessa cosa, e sulla 100 ci andava a finire volte quello che
gli dicevo, senza fregarsi minimamente che era sempre la setssa cosa.
Questo perchè non ho dichiarato nessun campo come chiave.
Io ho risoloto solo una parte dei problemi, vi spiego.
Lanciando sulla tabella una select * e caricando tutto in una list,
quando cliccavo (selezionavo) una riga per cancellarla, dopo la prima
cancellazione, gli indici delle righe della list, non corrispondevano
più con quelli all' interno del db. Questo perchè passavo da:
| INDICE | TITOLO | AUTORE | ALBUM | ANNO | GENERE | CD |
|     01     |     Xx      |      Xx       |     Xx     |    Xx     |     Xx        |  Xx |
|     02     |     Xx      |      Xx       |     Xx     |    Xx     |     Xx        |  Xx |
|     03     |     Xx      |      Xx       |     Xx     |    Xx     |     Xx        |  Xx |
a:
| INDICE | TITOLO | AUTORE | ALBUM | ANNO | GENERE | CD |
|     01     |     Xx      |      Xx       |     Xx     |    Xx     |     Xx        |  Xx |
|     03     |     Xx      |      Xx       |     Xx     |    Xx     |     Xx        |  Xx |
nella tabella, ma per la list, al succesivo caricamento, il record con
indice 03, era in realtà 02.
Io ho ovviato a questo problema prendo, prima di cancellare, quello
che c' era nelle colonne della riga selezionata sulla list, facendo
una select per qui valori e prendendomi l' indice sulla tabella del
record che avesse quei dati li. Solo dopo cancellavo, per essere
sicuro che mi levasse solo quello selezionato, il record che avesse
quell' indice (quello della tabella) e qui dati. In questo modo, se
avevo 10 righe uguale, ne levavo solo una e non tutte e 10!
Ancora peggio succedeva se io facevo una ricerca per un campo, dando
un qualcosa di generico, tipo:
select * from xxx where autore like....
Qui, gli indici della list, erano di certo diversi, anche di tanto,
rispetto a quelli che erano nella tabella, così mi salvavo facendo
sempre lo stesso giochetto.
L' inserimento. Prima di inserire un nuovo record, mi facevo una
select per vedermi quale fosse il valore dell' indide più alto, e
prima di aggiungere il record, all' indice ci aggiungevo uno. Se il db
era vuoto, allora partivo da 0, altrimenti incrementavo di uno. Così
facendo, non avevo mai due indici uguali, potevo però avere record
uguali ma con indici diversi.
Mi sono allora detto...ma non posso far far fare tutto questo lavoro
di controllo, incremento (del mio campo indice) direttamente al db, e
lanciare dal mio programma solo select/insert/delete sechhe?
Questo è un po il sunto...ora vorrei discutere con chiunque abbia un
idea, sul come sarebbe meglio strutturare questa tabella.
Saluti...

 Io ho risoloto solo una parte dei problemi, vi spiego.
allora...
<premessa>
-- il db qui sotto e' in formazione
-- i dati di vinili e cassette vanno a mano, come pure i tipi (tabellina:
lp, ep, 45, cd, cassetta...).
-- quelli dei cd audio forse riesco ad automatizzare smacchinando con cddb,
cdplayer.ini, cdmax & co.
-- quelli degli mp3 sono i dati, presi su via vb, dei file (con path _anche_
perche' stanno su piu' pc) piu' i tag che fornisce il bas di freddi (grazie
1000!), e su tutti e due i tipi di dato posso fare una query tipo select
where autore / fname / bitrate.
-- che il relazionale potrebbe andare avanti quasi all'infinito: il tag
genere e' numerico, dovrei aggiungere una tabella generi cui linkare il
codice di genere di ogni file. non fosse che i generi in musica, come in
letteratura, non esistono, sono una porcatina di comodo sempre troppo
stretta o troppo larga, sicche' ogni tanto si trova terry riley nel rock-pop
o robert wyatt nel jazz...
-- che a me (dal pdv della teoria del db, non della pratica), non creandone
a windows, non crea problemi avere due file identici, posto che stiano in
percorsi diversi. anzi: mi accorgo se un file e' giu' di posto, raddoppiato,
in versioni diverse, ecc.
...prova a guardare un po' le tabelle qui sotto, giusto per farti un'idea.
il cod / pcnum e' sempre un contatore. pcnum lo uso di solito perche' so
subito cos'e' anche con anagrafiche che prevedono un qualche campo cod.
fatto sta che sono sempre indeciso cosi' i miei db personali hanno i
contatori equamente distribuiti fra "cod" e "pcnum" :)
i campi testo li metto sempre a 255, non obbligatori. cosi' non mi creano
casini se me ne dimentico e al primo pack si recupera lo spazio.
in brani c'e' un contatore interno alla tabella e un disknum che punta al
cod dei dischi (se non sbaglio, +- una foreign key). l'idea sarebbe, per la
prossima vita o la lontana pensione, di metterci anche un mp3num,
replicabile, per sapere quali brani ho in mp3... il problema e' che su
napster opennap & co sto trovando praticamente tutto quello che ho in piu'
di 700 lp... grazie al cielo :)
</premessa>
...i casini ti derivano essenzialmente dal fatto che anziche' una dbgrid e
indici (puoi usarli in tutta beatitudine con dao, se il tuo db sara' come
suppongo in locale e monoutente. se invece prevedi di farlo crescere,
metterlo condiviso, o semplicemente vuoi studiare ado, temo di no, o con
molti piu' limiti) stai usando un listview, e speri di far combaciare
l'index del lv con quello che attribuisci tu alle schede della tabella.
con una griglia la connessione sarebbe automatica e pratica (con la dbgrid
dao; la datagrid mi sembra di aver capito non sia del tutto a punto). nel
momento in cui una riga e' selezionata, li' hai il bookmark, e quella
scheda, volendo, la fai secca con un tasto, senza doverla cercare.
se continui col listview, che ha in effetti altri pregi, suggerirei le
seguenti modifiche:
-- metti un campo cod o simili, contatore
-- visualizzalo nel listview
-- se devi cancellare una scheda, prendi su il cod (sara' un subitem,
subpongo) dell'item selezionato e fai un seek/delete (se usi indici) o un
delete where.
-- fregatene dei salti di numero. avrai il cod 1 seguito dal 258. embe' ? le
ruote non donano alla galleria del vento, ma un certo numero, in un'auto, e'
bene -- al livello tecnologico attuale -- che ci sia...
-- resta il problema dell'inserimento: qui solo tu puoi decidere cosa non
puo' essere raddoppiato. su quel qualcosa dovrai continuare a fare select,
visualizzare i risultati, e se gia' c'e' non inserire. ti assicuro che
delegare al filesystem l'operazione semplifica molto la vita. nb: io gli mp3
li rinomino praticamente tutti:
    riley, terry - in c
    barrett, syd + pinkfloyd - interstellar overdrive
    talking heads - big business + i zimbra
cioe' cerco di fare in modo che ci sia un solo [spazio trattino spazio], a
sx l'autore / gli autori in ordine alfabetico (il primo, senza articolo:
residents, non the residents), a dx il titolo / i titoli. in questo modo
fare poi lo split del fname e ricavare autore titolo ecc. si semplifica
parecchio, oltre che ci capisco qualcosa in gestione risorse. per non
scaricare lo stesso file 28 volte mi sembra il sistema piu' pratico...
bon, ragionaci un po' se credi.
ciao, a.
DB Structure - c:\vbprog\database\dischi\dischi.mdb - 04/01/2001 13.36.17
C:\VBPROG\DATABASE\DISCHI\DISCHI.MDB
===========================
TABLE: brani
------FLD: cod
------FLD: disknum
------FLD: diskord
------FLD: aut
------FLD: autore
------FLD: tit
------FLD: titolo
------IDX: cod
---------cod
------IDX: disknum
---------disknum
------IDX: disknum_diskord
---------disknum
---------diskord
===========================
TABLE: dischi
------FLD: cod
------FLD: collo
------FLD: aut
------FLD: autore
------FLD: tit
------FLD: titolo
------FLD: editore
------FLD: anno
------FLD: nd
------FLD: tipo
------FLD: note
------IDX: autore_titolo
---------autore
---------titolo
------IDX: collo_autore_titolo
---------collo
---------autore
---------titolo
------IDX: collo_titolo_autore
---------collo
---------titolo
---------autore
------IDX: pcnum
---------cod
------IDX: titolo_autore
---------titolo
---------autore
===========================
TABLE: mp3
------FLD: pcnum
------FLD: filepath
------FLD: filename
------FLD: filesize
------FLD: filedate
------FLD: mpegver
------FLD: layer
------FLD: crc
------FLD: bitrate
------FLD: cbr
------FLD: frames
------FLD: sample
------FLD: channelmode
------FLD: copyright
------FLD: original
------FLD: sec
------FLD: titolo
------FLD: autore
------FLD: album
------FLD: anno
------FLD: commento
------FLD: traccia
------FLD: genere
------IDX: filedate
---------filedate
------IDX: filename
---------filename
------IDX: filepath_name
---------filepath
---------filename
------IDX: filesize
---------filesize
------IDX: pcnum
---------pcnum
===========================
TABLE: tipi
------FLD: cod
------FLD: descri
------IDX: cod
---------cod
------IDX: descri
---------descri
===========================

lanciare dal mio programma solo select/insert/delete sechhe?
Se usi databases che supportano i triggers (come SQL Server), si, altrimenti
no (e' il caso di Access).
Ciao!
Luca Menegotto.
-- 
Posted from [62.110.78.40] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

===========================
idx sono indici? Ma scusa, alle 16.42 del 4 gennaio 2001 chiedo: che
differenza c'и tra indice e chiave?
Saluti...

univoco (possono anche non esserlo....)
Quello che invece dici qui, mi interessa...se io creo una chiave
primaria, e la associo al campo titolo, se in inserimento metto un
qualcosa che ha lo stesso titolo di un altro record, anche il visdata
mi blocca e mi dice che stò cercando di duplicare la chiave, quindi
qui ho già un controllo in inserimento. E' per questo che la chiave
primaria deve essere univoca. Io era questo che volevo.
Per quanta riguarda gli indici...bhè, credo che li userò, se mi
velocizzano la ricerca, ben venga :))
L'unico errore concettuale, potevo averlo fatto qui, mi hai
riallineato, grazie :)
Saluti...

 differenza c'è tra indice e chiave?
alle 01.04 del 5 rinnovo l'invito di roal: un po' di sintassi dei db. guarda
la guida di access, di dao, di ado, quello che vuoi. anzi, me le (ri)guardo
anch'io, e intanto passo la palla a chi vuole rispondere :)
ciao, a.

 primaria deve essere univoca.
La chiave primaria ha lo scopo di definire in modo univico il record. Io
normalmente la associo all'indice univoco, altri preferiscono altri
approcci, credo sia una questione di gusto. Se ragioni per singole colonne,
tu puoi imporre la stessa regola di univocita' anche a altri indici che non
siano la chiave primaria. Se stiamo parlando di Access, il vantaggio che ha
la chiave primaria e' che puo' essere composta da piu' campi.
Ciao!
Luca Menegotto


la chiave primaria e' che puo' essere composta da piu' campi.
Bene, alla fine arriavo sempre a quello che mi interessa :)) Io ho
questo db access, per ora lo creavo da codice, ma sono adesso per fare
queste prove concettuali, sono passato direttamente sul programma (a
dire il vero ho provato un paio di cose col visdata...). chiave
primaria = campo_1 + campo_2 + n campi_n? Questo vuol dire che io
posso dichiarare la mia hciave primaria composta dai campi che mi
interessa verificare, giusto?
Saluti...

> Provo a dare una risposta a quanto hai scritto tu...
]zac[

 ha scritto

bentornato dbg
in realta' quello che mi servirebbe soprattutto in questo momento e':
1. alcuni soldi (sto guardando le varie flat in sostituzione
dell'agonizzante wind, e bisogna solo decidere sa darsi una martellata sulla
tempia sinistra, sulla destra o...)
2. alcuni dischi da 75gb --> torna al punto 1.

 Certo ci son le coliche da sopportare ma niente e' a grattiss
ghhhghhh
lo affermi pure tu?
sono ben fatte e sembrano robuste, ma sono davvero complicate
che ne dite di scomodare l'intero ng (compreso Jimi e *Alessandro*)
per interpretarle :ppp
--
Fibia "Sakamoto" FBI
URL: 
www.geocities.com/fibiafbi
E-Mail: 
fibi...@hotmail.com
ICQ UIN 63586057
Membro #25 delle Brigate Takahashi Sez. Sud

 Saluti...

Certo ci son le coliche da sopportare ma niente e' a grattiss
Cioč cioč? Spiegami bene che a me interessa...con queste classi che
riuscirei a fare? Aspetto news (č parecchio che non lo dicevo :) ).
Grazie
Saluti...

2. alcuni dischi da 75gb --> torna al punto 1.
E un bel masterizzatore per DVD?
E' un salasso ma poi sei apposto per una sfracello di tempo.
Salve
                Dbg
P.S. Presenta il conto al nipotino, 1M£ per consulenza, 2M£ per supporto
morale, 3M£ per difesa da lingiaggio ....

Affermo che tu e Pal siete una manica di pigroni eheheh.
Ti ricordo che abbiamo in piede delle sfide tra le mie classi e vossia che
eviti da tempo ehehe.
Le classi sono scritte per risolvere casi reali, quindi sono per forza
complesse come struttura, ma come uso sono abbastanza semplici.
Per interpretarle prova a usare un compilatore eheheh
Salve
                    Dbg
P.S. Sto sito si sposta o non si sposta? gia' pubblicato il clona dbg ops
controlli o sono in tempo per modifiche?
Fibia FBI ha scritto nel messaggio
Dbg


Mah, secondo Pal e Fibia e' meglio starne alla larga e in fondo qualche
ragione c'e' l'hanno.
Diciamo che per mia natura tendo sempre ha risolvere i problemi che incontro
usando le classi.
E' un buon sistema per avere codice affidabile (i dati dentro alla classe
sono al sicuro da modifiche erratiche), riutilizzo nello stesso progetto
della stessa soluzione n volte senza problemi, la soluzione col tempo viene
migliorata fino a raggiungere le alte vette segnalate da Fibia (ghghh).
Cmq fai un salto su 
http://www.redangel.it
 vai alla sezione Vb e cerca
FlexAgenda.
Ah importante, non farlo a stomaco pieno heheeh.
Se sopravvivi ne riparliamo.
Salve
                Dbg
skunk ha scritto nel messaggio
Dbg


interessa verificare, giusto?
Ne piu' e ne meno. Come? Nella gestione della struttura, seleziona piu'
campi, e poi clicca sulla famosa chiavetta.... :))


 che supportava DAO nella versione 5 di VB
obsoleto sara' lei !! :))
la dbgrid e' felicemente supportata anche in vb6, e se ms non vuole mollare
il mercato standalone a filemaker, 4th d ecc., sara' bene la supporti anche
in vb9, vb10, ..., vbnetc. :)
salvo esercizi di scrittura, ho l'impressione che pochini possano fare con
ado un db locale con mdb piu' funzionale (efficiente, rapido, compatto nel
codice) di uno con dao.


Se sopravvivi ne riparliamo.
Spetta, parliamone subito...non voglio entarare nel merito del tuo
programma, ho dato uno sguardo al volo (saltellando un po qua e un po
la nel tuo codice per vedere tu come lo scrivi, oh, non lo stavo
controllando eh!!). Leggendo la descrizione nel sito da te indicato
ero rimasto un perplesso, l' ho scaricato ma...ancora non ho ben
capito a che dovrebbe servirmi. Riporto una del testo del file
leggimi.txt che è nel tuo zip:
FlexAgenda e' una agenda-rubrica-diario-ecc. configurabile.
Attraverso un file di testo viene stabilito quali campi di un database
vengono utilizzati, a che controlli sono associati i campi, in che 
posizione vengono visualizzati i controlli, ecc....
A parte che continuo a non capire l' utilità ma...soprattutto, in
fuzione della mia discussione con Pal, che c' entra? Aspetto news.
Grazie.
Saluti...
PS: ti ho inviato lo stesso messaggio anche via mail...ho sbagliato
pulsante, scusa.

 controlli o sono in tempo per modifiche?
io l'articolo l'ho gia' preparato, ma se vuoi fare qualche modifica
fammi sapere e manda pure. (siamo leggermente OT)


pulsante, scusa.
Non credo che hai potuto, visto che zac zac sono antispamming
(
be...@adria.it
).
Salve
            Dbg

(siamo leggermente OT)

 Se sopravvivi ne riparliamo.
،__،


 hihihi.
classi parlanti?
il programmatore ibm di cui ti ho parlato aveva 'inventato' un
meccanismo che lui chiama "chiave parlante".. delle grosse
risate!


E' un salasso ma poi sei apposto per una sfracello di tempo.
Non mi sembra tutto questo salasso: si parla di 1 milione e mezzo
neanche... Sono i DVD RAM che costano dei soldi: si parla di 100k lire
e rotti per i piu' scarsi --che non userei--. Parlo di 5.2GB.
Saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 Opel/ECC Calibrezio EVO-IV --- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD

Non credo che hai potuto, visto che zac zac sono antispamming
Esatto, la mial che hai indicato qui non esiste :))
Saluti...

 senso dire che in alcuni casi è meglio utilizzare una cosa o l' altra.
non sono d'accordo.
IMHO la buona programmazione si fonda sul concetto delle classi
in un modulo globale le variabili stanno li' appese e pare che non
abbiano vita loro. all'interno di una classe i membri sono come
parti di un oggetto. in pratica una proprieta' e' strettamente legata
alla sua istanza, mentre una variabile globale e' soggetta a molti
rischi ed errori di programmazione.
certo, e' possibile scrivere moduli con variabili private ben fatti,
ma per natura la classe si presta piu' facilmente ad una buona
scrittura di codice.
non mi azzarderei mai a scrivere una classe solo per stampare
una pagina di valori, ma quando e' necessario scrivere una
struttura dati robusta (e soprattutto riutilizzabile) la classe e'
d'obbligo.
[ZAC ZAC ZAC]
P.S. e vai DBG... torna polemico piu' che mai


No, non hai toppato, diciamo che ci siamo.
Toh, devo essermi sbagliato allora eheheh.
Salve
            Dbg

P.S. e vai DBG... torna polemico piu' che mai
P.S. quando mai io fussi polemico? rompi sfere, pedante, virulento, utopista
(la pista per gli uto?) va' bene .... ma polemico, quanno mai?
Salve
                Dbg

 ma polemico, quanno mai?
confermo tutto...
ti volevo stuzzicare na' picca


 testo (provala, e' carina).
molto carina, ma parecchio complicata
[ZAC++]
