Warum sind Positionsabfragen schlecht?

Question

Ich lese CJ Datum SQL und relationale Theorie: Wie genau SQL-Code schreiben , und er macht den Fall, dass Positionsabfragen sind schlecht - zum Beispiel dieses INSERT:

INSERT INTO t VALUES (1, 2, 3)

Sie sollten stattdessen attributbasierte Abfragen wie folgt verwendet werden:

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

Jetzt verstehe ich, dass die erste Abfrage aus der Reihe mit dem relationalen Modell ist, da Tupel (Zeilen) sind ungeordnete Sätze von Attributen (Spalten). Ich habe Probleme beim Verständnis, wo der Schaden in der ersten Abfrage ist. Kann jemand mir dies erklären?

Answer 1

Die erste Abfrage bricht so ziemlich jeder Zeit die Tabellenschemaänderungen. Die zweite Abfrage empfängt jede Schemaänderung, die ihre Spalten intakt lässt und nicht defaultless Spalten hinzufügen.

Leute, die SELECT * Abfragen tun und setzen dann auf Stellenschreibweise für die Werte zu extrahieren sie sind besorgt über sind Software-Wartung supervillains aus dem gleichen Grund.

Answer 2

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

Auch bedeutet es, dass jemand die erste Version zu lesen hat, das Schema zu konsultieren, um herauszufinden, was die Werte bedeuten sollen zu. Zwar ist dies nur wie Positionsargumente in den meisten Programmiersprachen, aber irgendwie SQL fühlt sich etwas anders in dieser Hinsicht. - Ich sicherlich die zweite Version viel leichter verstehen würde (vorausgesetzt, die Spaltennamen sinnvoll sind)

Answer 3

Ich weiß nicht wirklich kümmern sich um theoretische Konzepte in diesem Zusammenhang (wie in der Praxis eine Tabelle hat eine definierte Spaltenreihenfolge). Der primäre Grund, warum ich die zweiten zum ersten bevorzugen würde, ist eine hinzugefügt Abstraktionsschicht . Sie können Spalten in einer Tabelle ändern, ohne Ihre Anfragen vermasseln.

Answer 4

Sie sollten versuchen, Ihre SQL-Abfragen über das genaue Layout der Tabelle so wenig wie möglich abhängig zu machen.

Die erste Abfrage stützt sich auf die Tabelle drei Felder nur mit, und in genau dieser Reihenfolge. Jede Änderung an alle an den Tisch wird die Abfrage brechen.

Die zweite Abfrage verlässt sich nur auf dort die drei felds in der Tabelle zu sein, und die Reihenfolge der Felder ist irrelevant. Sie können die Reihenfolge der Felder in der Tabelle ändern, ohne die Abfrage zu brechen, und Sie können sogar Felder hinzufügen, solange sie Nullwert zulassen oder einen Standardwert haben.

Auch wenn Sie nicht über das Tabellenlayout sehr oft neu zu sortieren, zu einer Tabelle mehr Felder hinzuzufügen, ist durchaus üblich.

Auch die zweite Abfrage besser lesbar. Sie können sich aus der Abfrage sagen, was die in der aktenkundig Werte bedeuten.

Answer 5

Etwas, das bisher noch nicht erwähnt ist, dass man oft einen Ersatzschlüssel als PK werden müssen, mit auto_increment (oder so ähnlich), einen Wert zuzuweisen. Mit dem ersten, dann würden Sie angeben müssen etwas gibt - aber welcher Wert können Sie festlegen, ob es nicht zu verwenden ist? NULL könnte eine Option sein, aber das ist nicht wirklich passt in die PK unter Berücksichtigung auf NOT NULL würde eingestellt werden.

Aber abgesehen davon, die ganze „zu einem bestimmten Schema gesperrt“ ist ein viel wichtigerer Grund, meine Meinung nach.

Answer 6

SQL gibt Ihnen die Syntax für die Angabe der Namen der Spalte für INSERT und SELECT-Anweisungen. Sie sollten diese, weil verwenden:

• sind Ihre Anfragen stabil auf Änderungen in der Reihenfolge der Spalten, so dass die Wartung weniger Arbeit nimmt.
• Die Reihenfolge der Spalten abbildet besser, wie Menschen denken, so ist es besser lesbar. Es ist mehr klar von einer Spalte als der Spalte „Name“ zu denken, anstatt die zweite Säule.

Answer 7

Ich ziehe die UPDATE-ähnliche Syntax zu verwenden:

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

Welche weit leichter zu lesen und zu warten ist als die beiden Beispiele.

Answer 8

Auf lange Sicht, wenn Sie eine weitere Spalte zu Ihrer Tabelle hinzuzufügen, wird Ihre INSERT nicht funktionieren, wenn Sie explizit Liste der Spalten angeben. Wenn jemand die Reihenfolge der Spalten ändert, Ihre INSERT leise gelingen kann Werte in falsche Spalten eingefügt wird.

Answer 9

Ich werde noch etwas hinzuzufügen, ist die zweite Abfrage weniger anfällig orginally auch auf Fehler vor Tabellen geändert werden. Warum sage ich das? Becasue mit dem seocnd Formular können Sie (und sollen, wenn Sie die Abfrage schreiben) visuell überprüfen, um zu sehen, ob die Spalten in der Tabelle einfügen und die Daten in der Werte-Klausel oder select-Klausel in der Tat in der richtigen Reihenfolge sind zu beginnen. Ansonsten können Sie durch Zufall die Sozialversicherungsnummer in der Honoraria Feld bis Ende setzen und die Zahlung Sprecher ihre SSN statt der Betrag, den sie für eine Rede halten sollte (Beispiel nicht zufällig gewählt, es sei denn wir haben es zu fangen, bevor es tatsächlich durch das passiert Sichtkontrolle!).