Warum beginnen Zeichenfolgenfunktionen auf SQL-basierten Datenbankservern an Position 1 anstelle von 0? [geschlossen]


7

Das hat mich immer gestört. Es scheint, dass Zeichenfolgenfunktionen in SQL-basierten Servern immer an Position 1 beginnen (zumindest ist dies bei MySQL, SQL Server, Oracle und Postgres der Fall). Beispielsweise würde die folgende Abfrage verwendet, um den ersten Buchstaben einer Spalte mit dem Namen first_name in der Namensdatenbank auszuwählen:

SELECT SUBSTRING(first_name,1,1) FROM names;

Warum beginnt die Position für String-Funktionen nicht bei 0, wie es in fast jeder Programmiersprache üblich ist?

Ich suche mehr als nur das ist der ANSI-Standard. Warum ist der Standard?

EDIT: Okay, also ist 0 nicht die "Norm in fast jeder Programmiersprache", wie unten ausgeführt wurde. 1 wird ebenfalls verwendet.


1
Ich finde die nullbasierte Indizierung äußerst seltsam. Nach all dem zähle ich im wirklichen Leben. Ein Wort beginnt mit dem ersten Zeichen, nicht mit dem Zeichen "Null".
a_horse_with_no_name

Antworten:


8

Wenn man bedenkt, dass es in einer Zeichenfolge außerhalb von Computern keine nullte Position gibt, sollte die Frage nicht wirklich lauten: Warum basieren Zeichenfolgen in einigen der gängigsten Programmiersprachen auf 0? (Ich bin mir nicht sicher über die Aussage von "fast jeder Programmiersprache", da es viel mehr Sprachen gibt, als die meisten Menschen kennen)

Zeichenfolgen in C und anderen Sprachen sind einfach eine Reihe von Zeichen (dh char[]), die beendet werden null. Aus diesem Grund können Sie einzelne Zeichen mithilfe der Indexnotation (dh stringVariable[index]) referenzieren . Variablen sind eine Adresse an einen Ort im Speicher. Der Index ist der Versatz zur Startadresse des Arrays. Wenn man also davon ausgeht, dass Strings ein Array sind, ist es sinnvoll genug, mit ihnen auf 0-Basis zu interagieren, da es zumindest konsistent ist, auch wenn es manchmal etwas umständlich ist.

Warum ist das in SQL anders? Ich würde vermuten, dass es bei SQL mehr um physischen Speicher als um Speicherzuweisung geht. Während einige RDBMS Arrays unterstützen (wie PostgreSQL), ist dies kein Standard. SQL ist auch eine deklarative Hochsprache, die die betrieblichen Besonderheiten der tatsächlichen Abfrage-Engine verbirgt, sodass die Konzepte von Adressen und Zeigern einfach nicht vorhanden sind. Daher ist es nicht wirklich sinnvoll, bei der Arbeit mit SQL in 0-basierten Indizes zu denken.

Wie ein anderes Poster feststellt, ist die Quelle der nullbasierten Indizierung die Adressierung. Die erste Adresse in einem Datenblock endet mit Null (unabhängig davon, ob sie die letzte Ziffer im physischen Speicher belegt oder nicht). Und es sind nicht nur Computer - die Adresse des ersten Hauses in Ihrem Nachbarschaftsblock ist wahrscheinlich eine Zahl wie 300 - nicht 301.

Wenn Sie iterative Funktionen programmieren, bei denen Module verwendet werden (um alle 5 Iterationen etwas zu bewirken usw.), ist es praktisch - und schneller -, mit nullbasierten Arrays zu arbeiten.

Bitte beachten Sie auch:


1
Danke srutzky. Ich denke, basierend auf den Sprachen, die ich kenne (was nicht "fast jede Programmiersprache" ist), habe ich fälschlicherweise angenommen, dass 0 die Norm ist. Ich habe das nie wirklich in Frage gestellt ... aber du hast recht. Warum beginnen manche Sprachen bei 0, ist eine faire Frage? ... und der Punkt über Arrays macht Sinn. In vielerlei Hinsicht ist 1 intuitiver.
VKK

Unsinn, wenn die Mehrheit der Programmiersprachen 0 als Beginn der Indizes übernommen hat, hat SQL absolut kein Recht, diese Konvention aus dem Fenster zu werfen.
Metabuddy

@metabuddy Natürlich hat SQL und jede andere Sprache das Recht, alles auf eine Weise anzugehen, die für diese bestimmte Weltanschauung am besten erscheint. Es gibt viele Programmiersprachen mit großen Unterschieden in Bezug auf Syntax, variablen Umfang usw. Vielleicht war es eine schlechte Wahl, dass sich eine Sprache überhaupt auf 0-basierte Indizes festgelegt hat (es ist nicht sehr intuitiv). .
Solomon Rutzky
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.