Newsgroup: it.comp.software.database
Titolo: Chiave primaria singola o composta?

Altra domanda: una tabella gestisce una specie di log delle operazioni
eseguite dagli utenti. Ogni utente ha un identificativo unico che viene
registrato in ogni record di sua appartenenza, in modo che possa,
interrogando, vedere solo i suoi "movimenti". Esiste anche in progressivo ID
che farebbe da chiave primaria, ma... ci sono tre possibilità:
1. utilizzo l'ID come chiave primaria (ogni riga un ID diverso) e
l'identificativo dell'utente come elemento di filtro
2. stesso che al punto 1, ma inserisco nella chiave primaria anche
l'identificativo dell'utente
3. uso progressivi diversi per ogni utente e la chiave primaria sarà sia il
progressivo che l'identificativo utente
Quale scegliere? L'ultima soluzione mi costringe ad avere una tabella per
memorizzare i progressivi dei singoli utenti (credo) e non mi sembra porti
grandi vantaggi. La due forse è più veloce nel momento del recupero dei
dati? Oppure va bene la prima magari con un indice sull'identificativo
utente?
Stefano.

 sarà sia il progressivo che l'identificativo utente
?? A che scopo ??
Davide
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ?? A che scopo ??
Effettivamente non ha senso nell'esempio che ho fatto. Altro caso: i dati
memorizzati sono, ad esempio, contatti di una immaginaria rubrica, ed ogni
utente ha i suoi contatti. Il progressivo potrebbe (anche se la cosa non mi
piace affatto) essere un elemento identificativo del contatto. Se uso un
progressivo globale un utente si trova con contatti che hanno dei numeri
identificativi esplosivi :-)
Anche questa è una bella domanda: come fare in modo di assegnare ad ogni
registrazione che fa un utente (nell'ipotesi della rubrica) un numero,
magari riutilizzando quelli già cancellati (tipo quello che avviene nei
cellulari). Ho l'impressione, però, che in un database crei problemi di
eccessivo numero di accessi...
Ciao, Stefano.

 che avviene nei cellulari).
Utilizzando un "pool" di numeri disponibili ed un contatore
progressivo, se il "pool" e' vuoto prendi dal contatore, altrimenti
prendi dal pool. Ogni volta che cancelli un record metti l'ID nel
pool.
Nota: il "riutilizzo" dei numeri e' una feature inutile in questo
contesto. Nel caso dei cellulari tu hai un numero limitato di
"slot", nel caso di un database il numero di record e' pressoche'
illimitato (il limite c'e', ma dubito che chiunque ci andra' mai
vicino).


 quindi non aggiungi nulla.
Certo, ma prova a pensarlo in questo modo: una bella applicazione web che
per recuperare i dati passa con un get l'id da recuperare. Tutto funziona
salvo la sicurezza: se un utente scrive a mano un id può recuperare
qualsiasi riga della tabella. Quindi è necessario filtrarla per
identificativo dell'utente.
Nel caso di chiave primaria con il solo id, il DB recupera il record, poi
controlla che il campo di identificazione utente corrisponda e agisce di
conseguenza.
Con l'identificativo utente nella chiave primaria, semplicemente non trova
la riga. Chiaramente l'identificativo utente viene memorizzato a livello
server.
?
Stefano

 Quindi è necessario filtrarla per identificativo dell'utente.
Se un utente e' tanto scafato da costruire ed inviare una richiesta
falsificata, puo' anche inventarsi/ipotizzare un'ID utente. Ma a questo
punto stiamo parlando di roba che non c'entra nulla con il database
in se' stesso (il controllo ID utente puoi farlo indipendentemente
dalla chiave primaria).
