2009-07-07 12 views
6

Modifica: quando dico "SQL Server", sto parlando davvero di Management Studio. Scusa se questo è stato confuso.SSMS consente record duplicati in una tabella, ma non aggiornamenti successivi

Oh, odio quando succedono cose del genere. Ieri stavo lavorando con SQL Server e ho provato il comando PIVOT per cercare di capire come funzionava. Così ho creato una nuova tabella con quattro colonne e la prima colonna avrebbe avuto lo stesso valore per le prime poche righe.

Ho aggiunto il "valore1" alla prima riga, prima colonna e ho premuto invio. Non sono state ancora aggiunte chiavi o vincoli, mi ha permesso di entrare nella riga successiva con NULL per le altre colonne sul primo riga (che va bene). Con mia sorpresa, mi ha anche permesso di inserire "value1" nella seconda riga e inserire down - questo dovrebbe essere impossibile dato che ora ci sono due righe identiche. Tuttavia, dato che stavo solo scherzando, questo non mi ha infastidito. Così procedo per creare quattro righe in quanto tale:

Tabella 1

Col1  Col2  Col3  Col4 
--------------------------------- 
Value1  NULL  NULL  NULL 
Value1  NULL  NULL  NULL 
Value1  NULL  NULL  NULL 
Value1  NULL  NULL  NULL 

Ovviamente questo è strano e si rompe teoria relazionale, ma non mi importa davvero dal momento che questo è solo una tabella che ho creato per scherzare con. Tuttavia, ho quasi tirato i miei capelli a quello che è successo dopo. Dopo che ho avuto questi dati, non potrei fare nulla al tavolo. Se ho provato a compilare col2, col3 o col4 su una delle righe, SQL Server mi urlerebbe per avere righe duplicate: "Nessuna riga è stata aggiornata. I dati nella riga 1 non sono stati commessi .... Il valore della riga (s) aggiornati o eliminati o non rendono la riga univoca o alterano più righe (4 righe). "

Quindi in altre parole, SQL Server mi ha consentito di immettere righe duplicate, ma quando ho provato ad aggiornare le righe per renderle univoche, non mi avrebbe permesso, citando che ci sono righe duplicate come motivo. La parte peggiore è che non sono nemmeno riuscito a cancellare nessuna riga (ottengo lo stesso messaggio di errore). L'unica soluzione che ho trovato una volta in questo scenario è stata quella di eliminare la tabella e ricominciare da capo - il che è ridicolo.

La mia domanda è, come può esistere questo tipo di comportamento in un programma ben noto che si è evoluto in un decennio? Sono io che sono senza cervello e dovrei accettare il comportamento di SQL Server? Per me questo è inaccettabile e SQL Server non dovrebbe mai permettermi di inserire righe duplicate in primo luogo, o avrebbe dovuto permettermi di aggiornare le righe duplicate fino a quando non erano tutte uniche e quindi provare a salvare.

Questo non significa in alcun modo essere una sorta di post di odio per SQL Server. È relativamente raro che mi imbatto in un comportamento del genere, ma quando lo faccio, può davvero mettermi alla prova e farmi impazzire. Semplicemente non capisco perché il programma abbia un comportamento costruito in questo modo. Per quale motivo nel mondo mi ha permesso di inserire le righe duplicate in primo luogo se non avesse intenzione di farmi aggiustare?

Ricordo di aver lavorato con MS Access nel corso della giornata e mi sarei imbattuto in uno strano comportamento arcaico. Alcune volte ho dovuto copiare grandi quantità di dati, ricreare la tabella e ricrearla solo perché Access mi permetteva di fare qualcosa che non avrebbe dovuto, e ora mi sta bloccando da eventuali modifiche per risolverlo - producendo efficacemente un punto morto.

Quindi cosa sta succedendo qui? Ho bisogno di una sorta di cambiamento di paradigma quando ci si avvicina a SQL Server? Sono io o SQL Server questo è il problema? (Puoi dire che sono io, posso prenderlo.)

risposta

9

Tutto lo studio di gestione ha sempre fornito un'interfaccia utente per creare un po 'di SQL per te e eseguirlo sul DB.

Nel tuo caso, ogni volta che hai aggiunto una riga, ha prodotto una dichiarazione INSERT. Questo è perfettamente valido.

Quando si è tentato di utilizzare l'interfaccia utente per eliminare o aggiornare un singolo record di tutti questi record duplicati, non è stato possibile produrre l'SQL per farlo. Il motivo è che, non essendoci alcuna chiave sul tavolo, non c'è modo di produrre una clausola WHERE che rappresenterebbe il record che stavi cercando di AGGIORNARE o CANCELLARE.

I messaggi di "errore" sembrano perfettamente chiari e validi per me.

quanto per i vostri commenti:

Con mia grande sorpresa, mi ha anche permesso di immettere "valore1" in seconda fila e entrare giù - questo dovrebbe essere impossibile dato che ora ci sono due identici filari. Tuttavia, dato che ero solo a , questo non mi dava fastidio.

Ovviamente questo è strano e rompe teoria relazionale, ma non ho davvero cura dal momento che questo è solo un tavolo ho creato a pasticciare con.

Non c'è niente di male ad avere una tabella di database che consente duplicati, è una cosa perfettamente valida per farlo se è quello che vi serve. Per quanto riguarda non "prendersi cura" o essere "infastidito" di aver permesso i duplicati. Ecco dove si trova l'errore. È allora che ti saresti reso conto che ti sei dimenticato di aggiungere una chiave primaria.

+0

Grazie per aver effettivamente spiegato i motivi che hanno consentito di inserire gli inserti ma non aver consentito gli aggiornamenti/eliminazioni. Questo è stato molto utile. – JoeCool

+1

Ah, capisco il messaggio di errore molto meglio ora. All'inizio pensavo che l'errore fosse una realizzazione latente delle righe duplicate, poiché in quel SSMS si stava "svegliando" e vedendo che se avessi cancellato una riga, ci sarebbero ancora tre duplicati e non potrebbe consentire duplicati. Ma no, non era in grado di cancellare la riga perché non sapeva quale dei quattro eliminare. – JoeCool

1

L'editor di record in Sql Server Management Studio è una piccola (e relativamente poco importante) parte dell'offerta di prodotti SQL Server.Penso che tu possa tranquillamente accettare le peculiarità dell'editor senza preoccuparti della qualità relativa del server stesso.

Dietro le quinte, Management Studio sta eseguendo istruzioni SQL per eseguire le tue azioni, proprio come se tu stessi scrivendo tu stesso quell'SQL. Quindi se infrangi una regola, paghi la multa.

+0

Sì, penso che sia il mio problema. Sto immaginando nella mia testa che SSMS sia strettamente associato al server attuale, ma in realtà sta inviando e ricevendo istruzioni SQL proprio come qualsiasi app che scrivo per il mio database. – JoeCool

1

Una stranezza sì, ma un difetto, no. È perfettamente legittimo disporre di una tabella senza chiave univoca, ma non è possibile eliminare una riga da essa con l'editor di tabelle in SSMS (o Enterprise Manager prima di esso) se ci sono righe identiche.

Non è SSMS che ti consente di creare le righe duplicate, sei tu che l'hai consentito quando hai creato la tua tabella senza chiave primaria. È sempre possibile creare una colonna di identità con incremento automatico che risolva il problema.

Non userei l'editor di tabelle per questo tipo di cose, vorrei scrivere istruzioni INSERT.

+0

Se SSMS consente di inserire righe duplicate, ma non di eliminarle, ciò mi sembra pericoloso. Non vedo ragioni per permetterlo. Secondo me, dovrebbe consentire entrambi o nessuno dei due. – JoeCool

+3

Ma un DELETE FROM mytable senza una condizione rimuoverà i record, quindi non è come se non avessi un modo per rimuoverli. SSMS sembra assumere un certo livello di competenza minima; non necessariamente controllerà tutto per te. Benvenuto nella programmazione. –

+2

Se aggiungi una chiave primaria, l'intero problema scompare. –

1

Non sono sicuro di come ci si aspetterebbe che lo strumento sappia quale riga eliminare se non si dispone di una chiave univoca. Vorresti che cancellasse solo uno dei duplicati o entrambi? se solo uno, qual è la chiave che dovrebbe usare.

Lo studio di gestione è uno strumento . Il suo compito non è quello di imporre il design perfetto della tabella o il database di base 101, che include la presenza di alcune chiavi univoche per la maggior parte del tempo. E se avessi un modello aziendale pazzo che ha richiesto righe duplicate? La lamentela non sarebbe quindi che lo strumento ha impedito ruoli duplicati?

La riga inferiore è quella 1.Non dovresti comunque modificare o eliminare i dati con lo strumento. Dovresti scrivere le dichiarazioni per la maggior parte delle cose.
2. È necessario disporre di una chiave univoca

Impossibile dare la colpa a qualsiasi strumento per non avere quelle cose in atto.

+1

Ho già sentito questa affermazione. Si dovrebbe sempre usare lo scripting per tutto e non usare mai un editor. Perchè è questo? Masochismo? –

+1

@Robert Harvey, so che questo è un commento molto vecchio, ma i motivi per cui dovresti usare gli script sono: prima la GUI spesso fa le cose in un modo molto inefficiente causando blocchi di tabelle che non sarebbero accaduti se si usasse uno script. Successivamente tutte le modifiche ai database devono essere programmate e inserite nel controllo del codice sorgente in modo da avere gli script disponibili per l'esecuzione in altri ambienti quando è ora di passare da dev a QA a prod. Terzo, ci sono cose che la GUI ti dirà che non puoi farlo è possibile se scrivi lo script SQL. – HLGEM

Problemi correlati