60 messaggi dal 21 aprile 2006
Salve a tutti,
Ho avuto una doccia fredda, ma devo arrendermi alla realta'.
Ho sempre creduto che la definizione Identity sottintendesse a campo a valori univoci, ma ho scoperto che non e' cosi'.
Avevo impostato un campo in una tabella (in cui erano gia' stati definiti dei campi a PK) come IDENTITY ed impostatoci un indice come univoco. Questo in un database MSDE. Devo dire che nel tempo la tabella si e' sempre comportata correttamente, il sottinteso campo si e' sempre comportato come univoco. Nel corso del tempo questo DB ha subito delle trasformazioni, da SQL2005 fino a SQL2012. Improvvisamente, nell'eseguire uno script di aggiornamento, dove veniva usata la suddetta tabella, ho scoperto un errore di vincolo sull'univocita' dell' indice sul campo identity. Cosa e' successo? In quale passaggio il campo ha subito la duplicazione nei suoi valori? Gli script di modifica sono sempre stati quelli generati da SQL Server Management Studio; non sono mai stati forzati degli inserimenti "manuali" di valori nel campo implicato, tutto e' sempre stato lasciato alla gestione di SQL Server.

Dopo questa amara constatazione, devo cambiare la pratica di assegnare alle tabelle la chiave primaria su un campo Identity? Qual'e' allora la pratica migliore? Come assegnare ad una tabella una chiave primaria univoca automaticamente?
Grazie.
1.953 messaggi dal 27 luglio 2005
Contributi
salve,
se ho ben interpretato, la tua analisi non e' completamente corretta... la proprieta' identity garantisce un numero progressivo (non univoco) da associare ad una colonna... se sulla relativa tabella, ad esempio, viene effettuato un reseed dell'identity, la valorizzazione potrebbe generare duplicati... quindi, comunque, l'unico modo per garantire l'univocita' e' la generazione di un vincolo in tal senso, sia esso un indice o la chiave primaria stessa, in quanto la sola imputazione di proprieta' identity NON genera automaticamente un vincolo cosi' impostato...
ovviamente una colonna associata ad una valorizzazione tramite proprieta' identity e' un'ottima candidata quale chiave non naturale, sia per la sua compattezza che per l'automaticita' di valorizzazione da parte del sistema, e proteggendola come chiave primaria in effetti la proteggi da possibilita' di duplicati oltre che correttamente perseguire una corretta implementazione a livello di design di basi di dati...
saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
60 messaggi dal 21 aprile 2006
Ciao, grazie per la risposta.
Dunque, se ho capito, un campo Identity di per se non garantisce una serie univoca di valori, ma se il campo e' implicato in una chiave primaria oppure una chiave univoca, allora i valori generati sono univoci, giusto? Cosa che, per altro, ho sempre perseguito nei miei DB.
Il mio dubbio e' nato da questo: ho una serie di database, tutti omologhi e disposti sulle più svariate versioni (da MSDE a SQL EXPRESS 2012), questo campo e' rimasto univoco fino al suo approdo su 2012, allorche' mi sono accorto che la modifica di un campo, operata tramite script generato da SQL Server Management su un DB MSDE, causava una eccezione nel ricostruire la chiave univoca sul campo Identity sul DB su 2012. Nelle altre istanze invece nessun problema. E' sempre stata mia abitudine impostare un PK su un campo identity, ma in questo caso ho ereditato il db cosi' come era stato impostato. Riassumendo, puo' l'esecuzione di uno script duplicare il contenuto di un campo identity preesistente? L'esecuzione della SELECT INTO (da tabella originaria a tabella d'appoggio) puo' duplicare nella tabella di destinazione dei valori che non lo erano nella tabella d'origine?
Saluti
1.953 messaggi dal 27 luglio 2005
Contributi
salve,
fededi ha scritto:

Dunque, se ho capito, un campo Identity di per se non garantisce una serie univoca di valori, ma se il campo e' implicato in una chiave primaria oppure una chiave univoca, allora i valori generati sono univoci, giusto?


corretto :)

Riassumendo, puo' l'esecuzione di uno script duplicare il contenuto di un campo identity preesistente? L'esecuzione della SELECT INTO (da tabella originaria a tabella d'appoggio) puo' duplicare nella tabella di destinazione dei valori che non lo erano nella tabella d'origine?


tecnicamente, un'operazione
SELECT INTO tabella_con_identity FROM altra_tabella
NON puo' generare problemi, sempre che non venga proiettata anche una valorizzazione per la colonna identity, cosa che tra l'altro richiede anche l'impostazione di SET IDENTITY_INSERT ON/OFF prima della sua esecuzione...

poi dipende come si opera... parli di una tabella temporanea di staging...
se anche questa contiene una colonna con identity, la tua operazione
SELECT INTO tabella_staging_con_identity
FROM tabella_originale_con_identity
WHERE x = y;
ovviamente i tuoi dati originali saranno inseriti nella nuova tabella temporanea con degli Id potenzialmente diversi, sia per l'eventuale filtro applicato, sia per l'eventuale parallelizzazione della proiezione del risultato... tu non proietti anche l'ID, e questa viene assegnata al momento dell'effettivo nuovo inserimento... quindi... dipende cosa fa lo script "incriminato" :)

saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.