Perché le query posizionali sono dannose?

Question

Sto leggendo CJ Date SQL e teoria relazionale:Come scrivere codice SQL accurato, e sostiene che le query posizionali sono negative, ad esempio questo INSERT:

INSERT INTO t VALUES (1, 2, 3)

Dovresti invece utilizzare query basate su attributi come questa:

INSERT INTO t (one, two, three) VALUES (1, 2, 3)

Ora, capisco che la prima query non è in linea con il modello relazionale poiché le tuple (righe) sono insiemi non ordinati di attributi (colonne).Ho difficoltà a capire dove sia il danno nella prima query.Qualcuno può spiegarmelo?

Answer 1

La prima query rompe praticamente qualsiasi momento le modifiche dello schema della tabella. La seconda query può ospitare qualsiasi modifica dello schema che lascia le sue colonne intatte e non aggiunge colonne defaultless.

Le persone che fanno domande SELECT * e poi si basano su notazione posizionale per estrarre i valori che stanno preoccupati sono software di manutenzione supercriminali per lo stesso motivo.

Answer 2

Mentre l'ordine delle colonne è definito nello schema, dovrebbe in genere non essere considerato importante perché non è concettualmente importante.

Inoltre, significa che chiunque legga la prima versione deve consultare lo schema per scoprire quali sono i valori sono destinati a significare. Certo questo è proprio come utilizzando argomenti posizionali nella maggior parte dei linguaggi di programmazione, ma in qualche modo si sente SQL leggermente diverso a questo proposito -. Mi piacerebbe sicuramente capito la seconda versione molto più facilmente (assumendo i nomi delle colonne sono sensibili)

Answer 3

Io non mi importa di concetti teorici a questo riguardo (come in pratica, una tabella ha un ordine di colonna definita). Il motivo principale io preferirei la seconda alla prima è un livello di astrazione ha aggiunto. È possibile modificare le colonne di una tabella senza rovinare le vostre domande.

Answer 4

Si dovrebbe cercare di rendere le query SQL dipendono l'esatto layout del tavolo il meno possibile.

La prima query si basa sulla tabella avendo solo tre campi, e in questo ordine esatto. Qualsiasi cambiamento a tutti al tavolo si romperà la query.

La seconda query basa solo sulla presenza di quei tre felds nella tabella, e l'ordine dei campi è irrilevante. È possibile modificare l'ordine dei campi nella tabella senza rompere la query, e si può anche aggiungere i campi, purché consentire valori nulli o ha un valore predefinito.

Anche se non riorganizzare il layout di tabella, molto spesso, l'aggiunta di più campi a una tabella è abbastanza comune.

Inoltre, la seconda query è più leggibile. Si può dire dalla query stessa quali sono i valori messi in record significa.

Answer 5

Qualcosa che non è stato ancora citato è che sarà spesso essere avere una chiave surrogata come PK, con auto_increment (o qualcosa di simile) per assegnare un valore. Con la prima, che avrebbe dovuto specificare qualcosa lì - ma che valore si può specificare se non è da utilizzare? NULL potrebbe essere un'opzione, ma che in realtà non inserirsi nel considerare la PK verrebbe impostato NOT NULL.

Ma a parte questo, l'intero "bloccato a uno schema specifico" è una ragione molto più importante, IMO.

Answer 6

SQL consente di sintassi per specificare il nome della colonna sia per INSERT e istruzioni SELECT. Si consiglia di utilizzare questo perché:

• Le query sono stabili alle variazioni l'ordinamento della colonna, in modo che la manutenzione richiede meno lavoro.
• L'ordinamento della colonna mappe di meglio da come la gente pensa, quindi è più leggibile. E 'più chiaro a pensare a una colonna come colonna "Nome", piuttosto che la seconda colonna.

Answer 7

Io preferisco usare la sintassi UPDATE simile:

INSERT t SET one = 1 , two = 2 , three = 3

Il che è molto più facile da leggere e mantenere rispetto entrambi gli esempi.

Answer 8

A lungo termine, se si aggiunge un altro colonna alla tabella, il vostro INSERT non funziona se non si specifica esplicitamente elenco delle colonne. Se qualcuno cambia l'ordine delle colonne, il vostro inserto può avere successo in silenzio l'inserimento di valori nelle colonne sbagliate.

Answer 9

Aggiungerò un'altra cosa, la seconda query è meno soggetta a errori originariamente anche prima che le tabelle vengano modificate.Perché lo dico?Perché con il secondo modulo puoi (e dovresti quando scrivi la query) controllare visivamente se le colonne nella tabella di inserimento e i dati nella clausola valori o nella clausola select sono effettivamente nell'ordine giusto per cominciare.Altrimenti potresti finire per inserire per sbaglio il numero di previdenza sociale nel campo Honoraria e pagare agli oratori il loro SSN invece dell'importo che dovrebbero pagare per un discorso (esempio non scelto a caso, solo che lo abbiamo colto prima che accadesse effettivamente grazie a quello controllo visivo!).