Warum sind Positionsabfragen schlecht?

Question

Ich lese CJ Datum SQL and Relational Theory: How to Write Accurate SQL Code, und er macht den Fall, dass Positionsabfragen schlecht — zum Beispiel sind diese INSERT:

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

:

INSERT INTO t VALUES (1, 2, 3) 

Stattdessen sollten Sie attributbasierte Abfragen wie folgt nutzen

Nun verstehe ich, dass die erste Abfrage nicht mit dem relationalen Modell übereinstimmt, da Tupel (Zeilen) ungeordnete Gruppen von Attributen (Spalten) sind. Ich habe Probleme zu verstehen, wo der Schaden in der ersten Abfrage ist. Kann mir das jemand erklären?

Answer 1

Die erste Abfrage bricht jedes Mal, wenn sich das Tabellenschema ändert. Die zweite Abfrage berücksichtigt jede Schemaänderung, die ihre Spalten intakt lässt und keine standardmäßigen Spalten hinzufügt.

Menschen, die SELECT * Abfragen tun und setzen dann auf Stellenschreibweise für die Werte zu extrahieren sie im Begriff sind, sich Sorgen software maintenance supervillains aus dem gleichen Grund.

Answer 2

Ich interessiere mich nicht wirklich für theoretische Konzepte in dieser Hinsicht (wie in der Praxis hat eine Tabelle eine definierte Spaltenreihenfolge). Der Hauptgrund, warum ich die zweite der ersten bevorzugen würde, ist eine hinzugefügte Abstraktionsebene. Sie können Spalten in einer Tabelle ändern, ohne Ihre Abfragen zu verfälschen.

Answer 3

Während die Reihenfolge der Spalten ist im Schema definiert, soll es in der Regel nicht als wichtig angesehen werden, da es nicht konzeptionell wichtig.

Es bedeutet auch, dass jeder, der die erste Version liest, das Schema konsultieren muss, um herauszufinden, was die Werte bedeuten sollen. Zugegeben, das ist so, als würde man in den meisten Programmiersprachen Positionsargumente verwenden, aber irgendwie fühlt sich SQL in dieser Hinsicht etwas anders an - ich würde die zweite Version sicherlich leichter verstehen (vorausgesetzt, die Spaltennamen sind vernünftig).

Answer 4

Sie sollten versuchen, Ihre SQL-Abfragen so wenig wie möglich vom genauen Layout der Tabelle abhängig zu machen.

Die erste Abfrage beruht darauf, dass die Tabelle nur drei Felder in dieser Reihenfolge enthält. Jede Änderung an der Tabelle wird die Abfrage unterbrechen.

Die zweite Abfrage beruht nur darauf, dass es diese drei Felder in der Tabelle gibt, und die Reihenfolge der Felder ist irrelevant. Sie können die Reihenfolge der Felder in der Tabelle ändern, ohne die Abfrage zu unterbrechen, und Sie können sogar Felder hinzufügen, solange sie Nullwerte zulassen oder einen Standardwert haben.

Obwohl Sie das Tabellenlayout nicht sehr oft neu anordnen, ist das Hinzufügen weiterer Felder zu einer Tabelle durchaus üblich.

Auch die zweite Abfrage ist besser lesbar. Sie können anhand der Abfrage selbst erkennen, was die im Datensatz angegebenen Werte bedeuten.

Answer 5

SQL gibt Ihnen die Syntax für die Angabe des Spaltennamens für INSERT- und SELECT-Anweisungen. Sie sollten Folgendes verwenden:

• Ihre Abfragen sind stabil gegenüber Änderungen in der Spaltenreihenfolge, so dass die Wartung weniger Arbeit erfordert.
• Die Reihenfolge der Spalten ist besser zu verstehen, wie die Leute denken, also ist es lesbarer. Es ist klarer, sich eine Spalte als die "Name" -Spalte und nicht als die zweite Spalte vorzustellen.

Answer 6

Ich ziehe die UPDATE-ähnliche Syntax zu verwenden:

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

die weit leichter zu lesen und zu pflegen als die beiden Beispiele ist.

Answer 7

Langfristig, wenn Sie eine weitere Spalte zu Ihrer Tabelle hinzufügen, wird Ihre INSERT nicht funktionieren, wenn Sie explizit die Liste der Spalten angeben. Wenn jemand die Reihenfolge der Spalten ändert, fügt Ihr INSERT möglicherweise automatisch Werte in falsche Spalten ein.

Answer 8

Etwas, das noch nicht erwähnt wurde, ist, dass Sie oft einen Ersatzschlüssel als Ihre PK haben, mit auto_increment (oder etwas Ähnliches), um einen Wert zuzuweisen. Mit dem ersten, müssen Sie etwas dort — angeben, aber welchen Wert können Sie angeben, wenn es nicht verwendet werden soll? NULL könnte eine Option sein, aber das passt nicht wirklich in Anbetracht der PK würde auf NOT NULL festgelegt werden.

Aber abgesehen davon ist das ganze "an ein bestimmtes Schema gebunden" ein viel wichtigerer Grund, IMO.

Answer 9

Ich werde noch eine Sache hinzufügen, die zweite Abfrage ist weniger anfällig für Fehler orginally, noch bevor Tabellen geändert werden. Warum sage ich das? Aufgrund des Seocnd-Formulars können Sie (und sollten beim Schreiben der Abfrage) visuell prüfen, ob die Spalten in der Einfügetabelle und die Daten in der Klausel values ​​oder select tatsächlich in der richtigen Reihenfolge liegen. Andernfalls könnte es passieren, dass Sie die Sozialversicherungsnummer versehentlich in das Honorarfeld eingeben und ihren Sprechern statt des Betrags, den sie für eine Rede leisten sollten, ein SSN-Wort geben (das Beispiel wurde nicht willkürlich gewählt, außer dass wir es vorher eingefangen haben) Sichtprüfung!).