2009-05-17 6 views
10

Mi sembra un gioco da ragazzi. Ho sentito innumerevoli storie su persone che dimenticano la clausola WHERE in un UPDATE o DELETE e rovinano un'intera tabella. So che le persone incuranti non dovrebbero rilasciare query direttamente e tutto questo ... e che ci sono casi legittimi in cui si desidera influenzare tutte le righe, ma non avrebbe senso avere un'opzione per impostazione predefinita che richiede tali query deve essere scritto come:Perché SQL Server non ha reso obbligatoria una clausola WHERE di default?

UPDATE MyTable SET MyColumn = 0 WHERE * 

O senza cambiare la lingua,

UPDATE MyTable SET MyColumn = 0 WHERE 1 = 1 -- tacky, I know 
+4

stai assumendo la morte cerebrale non sarebbe sufficiente aggiungere un WHERE 1 = 1 a memoria e potrebbe iniziare a pensare, invece. Non penso che succederà: dopotutto sono morti nel cervello. Nel frattempo, ogni azienda richiederebbe l'opzione "Josh" da impostare in ogni momento per "sicurezza" e il mondo pensante ti darebbe la caccia e ucciderti. IMHO, ovviamente, YMMV. –

+1

Quindi intendi dirmi che è normale rilasciare intenzionalmente aggiornamenti e cancellazioni che non hanno una clausola where e il "mondo del pensiero" sarebbe così infastidito da questa opzione che mi vorrebbe morto? – Josh

+5

Non compro l'argomento che le persone imparerebbero a digitare 'WHERE 1 = 1' dove non lo vogliono veramente. Per sviluppare questa abitudine, dovevano avere situazioni frequenti in cui volevano davvero che l'aggiornamento colpisse ogni riga, e ciò sembra molto meno comune della situazione in cui non lo * vuoi *. Il punto di richiedere qualcosa come 'WHERE 1 = 1' non è di proteggere contro le persone che * pensavano * volessero colpire ogni riga, è proteggere contro le persone che hanno colpito per sbaglio F5 troppo presto o selezionato tutto tranne la clausola WHERE . –

risposta

5

Non è possibile impostare il commit automatico su falso nella sessione client come predefinito?Devi emettere un "commit" per vedere le tue modifiche in questo modo, in un quasi "sei sicuro di volerlo fare?" moda.

Credo che fosse l'impostazione predefinita per tutti i client Oracle TOAD presso un ex datore di lavoro.

+0

Bello! Non lo sapevo ma si chiama SET IMPLICIT_TRANSACTIONS {ON | OFF} e, come notato, causa comandi che richiedono il commit esplicito. Mentre lavorerò quasi certamente con questa opzione da ora in poi, mi sembra ancora sbagliato che SQL abbia come impostazione predefinita tutte le righe. – Josh

+0

Se è "bello", perché non votare e accettare la risposta? Dovrai avvisare il corpo degli standard SQL per fargli sapere che non approvi la loro decisione. – duffymo

+0

Ho votato ma qualcuno è arrivato e ha votato tutte le risposte concordanti. Non l'ho contrassegnato come la risposta perché stavo aspettando di vedere se qualcuno fosse venuto con qualche spiegazione sul motivo per cui non poteva o non doveva essere fatto. Ma sembra che "siamo programmatori e quindi non dovremmo sbagliare" la risposta è la più popolare. Segnerò i tuoi. – Josh

10

Perché il spec non lo richiede, e non si dovrebbe essere in esecuzione SQL ad hoc direttamente nei confronti dei dati di produzione in ogni caso.

+5

"non dovrebbe eseguire comunque sql ad hoc direttamente sui dati di produzione". lol. Inoltre, le persone non dovrebbero superare il limite di velocità sull'autostrada, ma lo fanno e le persone sono costrette a indossare le cinture di sicurezza per evitare lesioni. L'OP si chiede perché le cinture di sicurezza non sono richieste in terra SQL. – TheSoftwareJedi

+6

Le cinture di sicurezza dovrebbero essere almeno un'opzione – rpetrich

+2

Mentre le cinture di sicurezza dovrebbero essere un'opzione, IMHO, non ce n'è bisogno. Siamo programmatori e abbiamo ricevuto un grande potere e potere per causare l'ascesa e la caduta dei database; dobbiamo usare grande responsabilità e attenzione nel nostro lavoro quotidiano. L'amministratore può abilitare una cintura di sicurezza se ne è disponibile una, ma non credo che dovremmo aspettarci che ci sia uno. –

4

Fare questo errore è un lungo rito di passaggio per i programmatori. Tutti ce l'abbiamo fatta e siamo riusciti a rovinare i dati di produzione, imparando molto nel processo di correzione. Fai questo errore solo una volta, quindi è divertente guardare uno sviluppatore entrare nei ranghi quando succede.

Prevenire che succeda rovinerebbe tutto il divertimento!

:)

+0

In tutta serietà, il mio primo lavoro al liceo lavorando nel supporto tecnico per un .com ci avrebbe letteralmente fatto usare tecnologie come "aggiorna gli utenti set lockedout = 0 dove ..." mentre un'app era perennemente "in sviluppo" . poi urlavano quando qualcuno dimenticava la clausola where. :) Ma mi sono sempre chiesto perché avrebbero permesso la sintassi e ancora non vedo una ragione valida. – Josh

4

Joel, penso che il punto di domanda di Josh è il motivo per cui non le specifiche lo richiedono, o contratto di locazione hanno un'impostazione opzione che renderà il database specifico lo richiedono?

Poiché la specifica non lo richiede come dici tu, c'è un'opportunità per una query errata (ad hoc o semplicemente un bug programmatico) per modificare le righe nel database che non intendevi modificare.

Un implicito "TUTTI I RIGHE" sembra molto più pericoloso di un implicito "NO ROWS".

+2

Sarei d'accordo sul fatto che probabilmente sarebbe nel migliore interesse di tutti se fosse implicito NO ROWS. –

0

So per esperienza che lo fai solo una volta ... dopo che succede quando ti assicuri sempre di non farlo mai più !!!

5

Basta andare sul sicuro si può sempre essere eseguito in una transazione:

BEGIN TRAN 

UPDATE MyTable SET MyColumn = 0 

Poi, se il conteggio delle righe sembra buono:

COMMIT TRAN 
+0

Questo è un ottimo suggerimento. Lo faccio quasi sempre, se non altro per assicurarsi che i miei criteri siano buoni. – Josh

4

dal mio punto di vista questa è una domanda retorica, Voglio dire che è una specie di suggerimento ...

In realtà, trovo che sia davvero buono, potrebbero esserci alcune impostazioni come "SAFE_UPDATE" o qualcosa del genere ...

quello che faccio di solito, oltre a punta di robin (ALLWAYS aprire una transazione), è quello di eseguire la query con select, solo per avere uno sguardo ai record che verranno aggiornati, qualcosa di simile

update mytable set column = xx 
-- select * from mytable 
where mycondition = mycondition 

prima l'aggiornamento mi basta selezionare il da selezionare e vedere cosa restituisce ...

in ogni caso, si dovrebbe allways avere un backup (ho sentito SQL 2005 istantanee sono piuttosto fresco troppo) e il lavoro all'interno di una transazione ...

0

Josh in realtà non è così insolito voler eliminare o aggiornare tutte le righe in una tabella.

1

MySQL fornisce tale opzione per le query ad hoc. Si chiama --safe-updates (o --i-am-a-dummy). Come altri hanno sottolineato, abbiamo già commesso l'errore . Quelli di noi che eseguono query ad hoc tutte le volte, a volte alle 1 del mattino, hanno commesso l'errore più di una volta.

Anche se normalmente odio i sistemi "a prova di idiota" e "sei sicuro", mi piace questa opzione. Devi sempre stare attento, ma anche facendo attenzione creerai forse un errore ogni mille ore. Se trascorri 50 ore alla settimana come utente root sui sistemi di produzione, un errore ogni mille ore è di 2 1/2 maggiori avvitamenti all'anno. Per questo motivo, e un altro, troviamo - gli aggiornamenti sicuri sono molto utili.

ci sono due ragioni che è più utile di quanto la maggior parte degli SM di conferma messaggi. Innanzitutto rileva qualcosa che è più probabile che sia un errore, a differenza di "sei sicuro di voler eliminare quel file?". La maggior parte dei file elimina davvero desiderati, quindi la conferma è un fastidio. La maggior parte "elimina dagli utenti ", se manca una clausola where, è davvero un errore. In secondo luogo, punta allo esattamente quale è il probabile problema - la clausola missing where. È come se la conferma dell'eliminazione del file fosse abbastanza intelligente da dire "quella è la nuova copia aggiornata del marchio , non la vecchia copia che pensi di eliminare. Sei davvero in grado di eliminare la nuova copia, o hai intenzione di eliminare?" quello vecchio invece? "

In ogni caso, in genere odio "prova idiota", ma mi piace - aggiornamenti sicuri, e se è un'opzione chi non lo desidera non è necessario usarlo. La mia preoccupazione è che se lavori costantemente su un sistema che ha la funzione, qualcuno potrebbe diventare sciatto e avere problemi quando passa a un sistema senza di esso, come passare da MySQL a MSSQL.

Gratta e l'ultimo avvertimento - che nessuno sano di mente avrebbe passare a MS dopo familiarizzare con l'open source. :)

Problemi correlati