Newsgroup: it.comp.software.database
Titolo: chiave primaria su due colonne

Ciao a tutti.
Ho una tabella con una chiave primaria doppia.(su due colonne)
capita che io debba fare l'update sui record coinvolgendo a volte una
colonna che fa parte della chiave primaria.
In tale campo devo inserire la data di sistema.(corrente con ore minuti e
secondi), al verificarsi di una particolare condizione .
Oracle me lo lascia tranquillamente fare ma alcuni miei colleghi dicono che
un campo chiave non dovrebbe mai essere toccato, che quindi sono costretto
prima a fare il delete e poi l'update del record.
A me sembra assurdo, in fondo con un update risolverei il problema in un
lampo.
Voi che ne pensate?
grazie anticipatamente

 In tale campo devo inserire la data di sistema.
*Pessima* progettazione del sistema!
Davide

 ha scritto:

L'operazione che stai tentando di fare è pericolosissima e viola la 
principale regola di una tabella che è quella della sua integrità. In 
questi casi la cosa migliore da fare è stabilire per il record una 
Primary Key di tipo Seequence (contatore). Il tuo famoso campo, 
attualmente adibito a primary key, diventa un normale campo di 
tabella che può subire modifiche.
Un problema che non so se ti sei posto, con la tua attuale 
gestione, è quello di ristabilire poi le eventuali relazioni con altre 
tabelle . Infatti la primary key è anche il campo con il quale 
vengono poi fatti i collegamenti con latre tabelle.
Allo stato attuale , quando fai un update sei costretto a fare 
attenzione anche a non duplicare il campo chiave.
Se vuoi un consiglio da parte di un analista programmatore  ti dico 
che devi impostare una seequence e definire come campo primary 
key il campo legato alla seequence.
Cioa da Pennarelli
 
Inviato da 
www.mynewsgate.net

 tabella che può subire modifiche.
Dalla padella nella brace...
Un campo sequence è solo una chiave primaria fisica, se esiste un
campo identificativo (il classico ID) deve esistere anche la chiave
logica della tabella, o chiave alternativa.
Quello che consigli tu è concettualmente sbagliato...
/G

 Voi che ne pensate?
Che forse, come già ti ha suggerito Davide, il disegno del tuo DB
non è proprio fatto a dovere... Analizza meglio il problema da un
punto di vista logico, e cerca di levarti dalla mente le chiavi
primarie e gli ID...
In linea generale, la chiave primaria è appunto un identificativo
che non dovrebbe essere mai aggiornato, a meno che forzatamente
da input esterni... (leggi: uso la PIVA di una azienda come PK e
sbaglio ad inserirla...3 alternative o il SW mi permette di
modificare la PK o lo fa il DBA o cancello quella azienda con tutti
i dati in cascata e ne rifaccio un'altra con la PK corretta...)
In altre parola se la logica (e non il flusso delle operazioni)
del tuo applicativo prevede che una PK debba essere aggiornata,
beh allora probabilmente "hai toppato" il disegno...
se invece aggiorni la PK per tuoi comodi etc etc... allora fallo
ma tieni in mente che puoi creare un putiferio nel db...
/G

 ha scritto:

Caro Giorgio..
credo proprio che hai interpretato male il mio suggerimento perchè 
ti garantisco che il'informazione da me data è frutto di una mia 
esperienza fatta per un progetto analizzato mediante gli standard 
UML credo quindi che non si possa passare DALLA PADELLA ALLA 
BRACE con queste cose di riferimento!!
Mi spiego meglio:
--esempio--
tabella CIVICI
chiave PK_SEQU_CIVICO =seequence
altra chiave logica UK_CODI_CIVICO (composta da 4 campi che nel 
tempo subiscono variazioni, come quella di Paolo).
Se devo stabilire una relazione, con la tabella dell'anagrafe la 
faccio con UK_CODI_CIVICO, ma se devo fare un update del record 
della tabella CIVICI la faccio con PK_SEQU_CIVICO.
Inviato da 
www.mynewsgate.net

 ha scritto nel messaggio
news:bl10fc$2mb7$1...@newsreader1.mclink.it...


 presentasse l'eventualita'?
Le due cose mi sembrano leggermente contraddittorie.
Se vuoi che gli update e i delete vadono a cascada devi per forza
referenceare le tabelle da coinvolgere, salvo ricorrere a una serie di
queries.
Ciao, Angelo