Newsgroup: it.comp.lang.delphi
Titolo: Chiavi duplicate

Cia a tutti,
Stň realizzando un piccolo applicativo il quale deve reppresentare su di una
tabelle il contenuto di alcuni file testo.
La struttura della tabella deve essere la seguente:
Titolo | Autore | Genere | Partizione | ........ ecc.
Io ho creato una tabella Paradox 7 con il Database DeskTop del mio Delphi
3.0 e seguendo passo passo le indicazioni di alcuni libri ho costruito un
applicativo nel quale riesco ad accedere ai dati, riesco a visualizzarli,
navigare con il DbNavigator, ecc.
Sin qui tutto OK.
Premetto che l'ordinamento principale deve essere fatto per il Titolo ed io
ho definito cone chiave tale campo.
A questo punto ho realizzato una procedura che legge i file testo contenenti
le informazioni relative ai vari campi e le carica in maniera ordinata in un
nuovo record che viene inserito nel DB.
Problema !!!
Il programma in fase di caricamento dei dati, spesso si blocca in quanto
esistono record che hanno il campo Titolo uguale e questo per definizione di
chiave non č accettato.
Come posso evitare ciň?
Nella mia tabella non esistono colonne che sicuramento hanno tutti i campi
diversi e quindo non riesco a definire un campo "Chiave" sicuro.
A me andrebbe al limite anche bene cercare di intercettare l'errore di
violazione della chiave e memorizzare il record che ha causato tale errore
con un nome differente tipo:
Titolo        |
-------------
Anna        |
Anna01
Anna02
ecc...
Grazie mille per la gentile attenzione
--
**************************************
Giorgio Marinangeli
E-Mail 
mgio...@cronosnet.com
ICQ 12941403
*************************************

diversi e quindo non riesco a definire un campo "Chiave" sicuro.
Assegna un codice univoco ad ogni libro ed utilizza quello come chiave
primaria. Il titolo del libro deve essere una chiave secondaria con
duplicati ammessi.

 diversi e quindo non riesco a definire un campo "Chiave" sicuro.





diversi e quindo non riesco a definire un campo "Chiave" sicuro.
E' sufficiente aggiungere un campo progressivo e definirlo come Primary Key.

E' sufficiente aggiungere un campo progressivo e definirlo come Primary Key.
E' bene non usare mai campi autoincrementanti.
Meglio un campo "codice", da definire come chiave primaria e gli altri
come chiavi secondarie a cui consentire la duplicazione.
Anche in Paradox si puo' fare.

>
[...]
La struttura della tabella deve essere la seguente:
Titolo | Autore | Genere | Partizione | ........ ecc.
[...]
Premetto che l'ordinamento principale deve essere fatto per il Titolo ed
io
ho definito cone chiave tale campo.
A questo punto ho realizzato una procedura che legge i file testo
contenenti
le informazioni relative ai vari campi e le carica in maniera ordinata
in un
nuovo record che viene inserito nel DB.
Il programma in fase di caricamento dei dati, spesso si blocca in quanto
esistono record che hanno il campo Titolo uguale e questo per
definizione di
chiave non è accettato.
Come posso evitare ciò?
[...]
<<
Esistono diverse possibilità:
a) rinunci ad avere una chiave primaria.
b) cambi la definizione delle tabelle ed inserisci un campo "ID_Libro",
intero, chiave primaria; crei una tabella appoggio con due campi:
NomeChiave, UltimaChiaveInserita (intero); quando inserisci un record,
vai a vedere il valore di UltimaChiaveInserita, lo incrementi e posti,
assegni il valore a ID_Libro nella tabella, posti il record.
c) come sopra, ma con ID_Libro di tipo autoinc (sconsigliato).
d) non trasferire i dati in tabelle Pdx ma tienili nei file di testo,
vedi articolo di Cantù sui "Datasets without databases" su Borland
Community (
community.borland.com
).
Suggerirei in particolare la b); oppure, se nelle tabelle di testo hai
l'ISBN puoi usare quello (dovrebbe essere univoco).
Per l'ordinamento, puoi creare una chiave non primaria sul campo che ti
interessa, anche se non è indispensabile: basta popolare il datasource
attraverso una query invece che una table (sempre consigliabile e più
flessibile) (v. ORDER BY in LocalSQL.hlp).
hth
Paolo Arosio


Non parlavo di campi autoincrementanti, ma di un campo contenente un
progressivo 'manuale', visto che non è possibile individuare chiavi base o
composte..
Ciao,
-=SIMO=-

 duplicati ammessi.
c'e' da dire che la tabella Giorgio viola la seconda forma normale,
sarebbe meglio avere due tabelle, una con i titoli e l'altra con gli
autori, la soluzione del contatore e' solo un palliativo che
aggira un problema di logica, sarebbe meglio inserire in chiave
primaria titolo e autore insieme; anche questa soluzione
potrebbe non essere  corretta se si devono gestire le ristampe
ad esempio... ma diventa un discorso troppo lungo...
HIH
Carlo

 > duplicati ammessi.
Il codice univoco potrebbe essere un campo autoincrementante, oppureil codice isbn
del libro, diciamo che non è corretto fare chiave primaria un campo descizione.
Bye
--
Massimo
l.sky...@iname.com
------------------------------------------
PER ME SI VA NELLA CITTA' DOLENTE
  PER ME SI VA NELL'ETTERNO DOLORE,
  PER ME SI VA TRA LA PERDUTA GENTE.
GIUSTIZIA MOSSE IL MIO ALTO FATTORE:
  FECEMI LA DIVINA POTESTATE,
  LA SOMMA SAPÏENZA E 'L PRIMO AMORE.
DINANZI A ME NON FUOR COSE CREATE
  SE NON ETTERNE, E IO ETTERNA DURO.
   LASCIATE OGNI SPERANZA, VOI CH'ENTRATE.
------------------------------------------