-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Italian db & SQL
- Thread starter maXim
- Start date
- Similar Threads Similar Threads
Primary Key
Rispondo a Gianni che mi chiedeva in un'altro thread dell'importanza delle PRIMARY KEY.
Una chiave primaria (PRIMARY KEY) è una colonna di una tabella (TABLE) che permette di identificare in modo univoco gruppi di record all'interno della stessa tabella. Si può operare anche con una combinazione di colonne, in questo caso si tratta di chiavi primarie composte. Quando si definisce una colonna come chiave primaria si tenga conto che il campo che la identifica non può avere mai lo stesso valore in più record e che lo stesso valore deve essere, sia per tipo che per contenuto, valido e quindi non nullo.
Quindi l'importanza delle chiavi primarie e il loro uso nella gestione dei dati è presto detta. Supponiamo, per esempio, un sistema di integrità referenziale che assicuri che le relazioni definite tra le tabelle in uso non possano essere mai violate. Supponiamo che questo sistema coinvolga due tabelle: una tabella referenziata (REFERENCED TABLE) che contiene la chiave primaria e una tabella referenziante (REFERENCING TABLE) che si lega ad essa attraverso una chiave esterna (FOREIGN KEY). Per essere precisi va detto che la chiave esterna può far riferimento ad una o più colonne su cui è definito un vincolo di unicità (UNIQUE CONSTRAINT), ed in ogni caso occorre che il tipo di dato delle colonne in relazione sia identico. Un esempio? Si pensi ad un qualsiasi gestionale aziendale dove è necessario relazionare un cliente presente nella tabella nominativi (anagrafica) con i relativi movimenti di magazzino o contabili, ebbene: si percepisce l'importanza dell'utilizzo di chiavi uniche?.
Altra cosa da dire è che nello standard ANSI SQL92, oltre a tutti gli atri comandi o azioni possibili sia sulle singole tabelle che su i gruppi di record (INSERT, DELETE, ecc.), si parla di azioni referenziali anche al verificarsi degli aggiornamenti della tabella referenziata e se ne definiscono quattro tipi dalle quali si evince ancor di più l'importanza della presenza delle chiavi primarie:
Rispondo a Gianni che mi chiedeva in un'altro thread dell'importanza delle PRIMARY KEY.
Una chiave primaria (PRIMARY KEY) è una colonna di una tabella (TABLE) che permette di identificare in modo univoco gruppi di record all'interno della stessa tabella. Si può operare anche con una combinazione di colonne, in questo caso si tratta di chiavi primarie composte. Quando si definisce una colonna come chiave primaria si tenga conto che il campo che la identifica non può avere mai lo stesso valore in più record e che lo stesso valore deve essere, sia per tipo che per contenuto, valido e quindi non nullo.
Quindi l'importanza delle chiavi primarie e il loro uso nella gestione dei dati è presto detta. Supponiamo, per esempio, un sistema di integrità referenziale che assicuri che le relazioni definite tra le tabelle in uso non possano essere mai violate. Supponiamo che questo sistema coinvolga due tabelle: una tabella referenziata (REFERENCED TABLE) che contiene la chiave primaria e una tabella referenziante (REFERENCING TABLE) che si lega ad essa attraverso una chiave esterna (FOREIGN KEY). Per essere precisi va detto che la chiave esterna può far riferimento ad una o più colonne su cui è definito un vincolo di unicità (UNIQUE CONSTRAINT), ed in ogni caso occorre che il tipo di dato delle colonne in relazione sia identico. Un esempio? Si pensi ad un qualsiasi gestionale aziendale dove è necessario relazionare un cliente presente nella tabella nominativi (anagrafica) con i relativi movimenti di magazzino o contabili, ebbene: si percepisce l'importanza dell'utilizzo di chiavi uniche?.
Altra cosa da dire è che nello standard ANSI SQL92, oltre a tutti gli atri comandi o azioni possibili sia sulle singole tabelle che su i gruppi di record (INSERT, DELETE, ecc.), si parla di azioni referenziali anche al verificarsi degli aggiornamenti della tabella referenziata e se ne definiscono quattro tipi dalle quali si evince ancor di più l'importanza della presenza delle chiavi primarie:
- NO ACTION che impedisce le modifiche alla chiave primaria referenziata da una chiave esterna
- SET NULL consente la cancellazione e la modifica e produce un aggiornamento del valore della chiave primaria al valore NULL
- SET DEFAULT imposta il valore della chiave esterna al suo valore di DEFAULT
- CASCADE consente la cancellazione e la modifica della chiave primaria, producendo, nel primo caso, la cancellazione di tutte le istanze in relazione della tabella referenziante, e nel secondo caso l’aggiornamento del valore della chiave esterna
Last edited:
frena Massimo, frena...
ok, calma, un lungo respiro ...
Bene!
devo DEVO realizzare una applicazione 'TENTATA VENDITA' su PDA.
Al momento ho realizzato due programmi per gestire rispettivamente le anagrafiche dei clienti(PROG1) e gli articoli(PROG2).
Premessa: gli articoli verranno sempre importati dal DB aziendale(e quindi e' solo consultabile), mentre i clienti saranno inseriti sul PDA dagli agenti/venditori e successivamente trasferiti nel DB aziendale.
PROG1 sembra funzionare abbastanza bene; se vuoi posso inviartelo per meglio capire se sto procedendo bene!
In ogni caso non ho fatto uso di PRIMARY KEY.Certo adesso dovro' gestire gli ORDINI quindi presumo con due tabelle: MAIN-ORDINE e RIGA-ORDINE.
in MAIN-ORDINE ci sara' un campo che fara' riferimento alla tabella CLIENTI, mentre in RIGA-ORDINE, oltre al campo che si lega a MAIN-ORDINE anche un campo CODICE-ARTICOLO che fara' riferimento ad ARTICOLI.
Ma di PRIMARY KEY e FOREIGN KEY cosa me ne faccio?
Sono duro di comprensorio !?!?
scusa ma dopo 25 (venticinque) anni di programmazione mi sfugge qualcosa!!!
Grazie,
Gianni
ok, calma, un lungo respiro ...
Bene!
devo DEVO realizzare una applicazione 'TENTATA VENDITA' su PDA.
Al momento ho realizzato due programmi per gestire rispettivamente le anagrafiche dei clienti(PROG1) e gli articoli(PROG2).
Premessa: gli articoli verranno sempre importati dal DB aziendale(e quindi e' solo consultabile), mentre i clienti saranno inseriti sul PDA dagli agenti/venditori e successivamente trasferiti nel DB aziendale.
PROG1 sembra funzionare abbastanza bene; se vuoi posso inviartelo per meglio capire se sto procedendo bene!
In ogni caso non ho fatto uso di PRIMARY KEY.Certo adesso dovro' gestire gli ORDINI quindi presumo con due tabelle: MAIN-ORDINE e RIGA-ORDINE.
in MAIN-ORDINE ci sara' un campo che fara' riferimento alla tabella CLIENTI, mentre in RIGA-ORDINE, oltre al campo che si lega a MAIN-ORDINE anche un campo CODICE-ARTICOLO che fara' riferimento ad ARTICOLI.
Ma di PRIMARY KEY e FOREIGN KEY cosa me ne faccio?
Sono duro di comprensorio !?!?
scusa ma dopo 25 (venticinque) anni di programmazione mi sfugge qualcosa!!!
Grazie,
Gianni
Caro Gianni,
:sign0013:
mi dispiace di non essere stato chiaro in precedenza ma non credo che esistino molti modi per descrivere le funzionalità (e quindi la sua importanza) di una chiave primaria assegnata ad una tabella di un database.
Ma non mi arrendo: una chiave primaria serve a rendere univoche le righe della tabella ove essa è definita: due righe distinte non potranno avere lo stesso valore sui campi scelti come PRIMARY KEY. In questa condizione, per esempio, non è possibile rimuovere record che sono referenziati e tanto meno si potrà modificare direttamente il contenuto dei campi relativi alle colonne identificate come chiavi univoche.
Non so se sono stato più chiaro ma ti rammento che, se fai una semplice ricerca, nel web trovi tante spiegazioni ben fatte e con altrettanti buoni esempi... Comunque sono sempre a tua disposizione...
A presto,
Massimo
:sign0013:
mi dispiace di non essere stato chiaro in precedenza ma non credo che esistino molti modi per descrivere le funzionalità (e quindi la sua importanza) di una chiave primaria assegnata ad una tabella di un database.
Ma non mi arrendo: una chiave primaria serve a rendere univoche le righe della tabella ove essa è definita: due righe distinte non potranno avere lo stesso valore sui campi scelti come PRIMARY KEY. In questa condizione, per esempio, non è possibile rimuovere record che sono referenziati e tanto meno si potrà modificare direttamente il contenuto dei campi relativi alle colonne identificate come chiavi univoche.
Non so se sono stato più chiaro ma ti rammento che, se fai una semplice ricerca, nel web trovi tante spiegazioni ben fatte e con altrettanti buoni esempi... Comunque sono sempre a tua disposizione...
A presto,
Massimo