Diskussion:SQL

komplizierte Syntaxdefinition

SWAGetti YOLOnese Ich als Informatiker ;-) finde die Syntax Definition in dieser From (Stand 02.07.2007):

INSERT INTO Relation ['(' (Attribut)+ ')'] VALUES ( '('(Konstanten)+')' )+

unübersichtlich, besse wäre:

INSERT INTO Relation [(Attribut,..)] VALUES (Konstanten,...)

oder gar

INSERT INTO Relation [(SpaltenName,..)] VALUES (Wert,...)

Und für die, die es Formal lieben:

Die verwendeten Meta Elmente (* das wort hab ich grad erfunden*), also kurz die Zeichen ' ) und + die eigentlich garnicht zum SQL gehören stören! Als Informatiker mag man ja verstehen was gemeint ist, aber man müsste auch erkennen, dass es Falsch und zu kompliziert ist. Aber bevor jetz den ganzen Artikel umschreibe frage ich lieber mal.

So ganz am Rande erwähnt: Ich bin froh das die DQL hier endlich einen Platz bekommen hat *freu*.

Ich finde es sehr sinnvoll, die Syntax als reguläre Ausdrücke darzustellen. --84.132.244.150 17:36, 17. Jun. 2009 (CEST)

Ich nicht. --80.153.250.36 11:30, 15. Jun. 2016 (CEST)

Umgangssprachliche Einführung für Nicht-Informatiker

Hallo, ich wurde gerade von einer (intelligenten!) Nicht-Informatikerin gefragt was denn nun SQL sei, NACHDEM sie sich an diesem Wikipedia-Artikel versucht hatte. Das ist doch nicht gut, oder? Ich schlage daher vor, eine umgangsspachliche Einführung zu SQL in einem Satz irgendwo am Anfang dieser Seite zu platzieren. Etwas wie "Mit SQL kann man Fragen an eine Datenbank stellen wie 'Gib mir alle Menschen die 57 Jahre alt sind, ein rotes Auto besitzen und jemanden kennen der ein blaues Auto besitzt' und die Datenbank gibt einem dann eine Liste mit allen Einträgen auf die dies zutrifft.". Danach kann man auch gerne weiter ins Detail gehen und diese schwammige Definition präzisieren, aber ich finde dass eine kurze nicht-technische Einführung sehr wichtig ist. Dies wird leider von uns Informatikern viel zu oft ignoriert.

Finde ich sehr sinnvoll. Über dem Artikel sollte meiner Meinung nach eine kurzgefasste Allgemeinbeschreibung stehen. Für den Interessierten kann man die Details und Fachbegriffe im Artikel selbst erklären. Solche Texte wie "...SQL (im allgemeinen Sprachgebrauch als Abkürzung für „Structured Query Language“ aufgefasst, obwohl laut ANSI-Standard ein eigenständiger Name) ist aus SEQUEL ([ˈsiːkwəl], Structured English Query Language) hervorgegangen, das von IBM in ..." sind denke ich zu kompliziert verfasst um als Einleitung in einem Nachschlagewerk zu dienen. Cattleyard 12:29, 2. Mai 2007 (CEST)

Ich finde es zu dem auch nicht gut, wie in einem Tutorial, spezieller auf die Programmierung mit SQL einzugehen. Wenn man bei Wikipedia nach SQL sucht, erwartet man eher eine einfache Erklärung. Für ein Tutorial ist Wikibooks eher das Richtige. Ansonsten kann ich euch voll zustimmen. --Rollinkarl 19:23, 13. Mai 2007 (CEST)

Habe den Text etwas überarbeitet, ich hoffe, dass der einleitende Absatz jetzt verständlicher ist. --20:08, 26. Mai 2007 (CEST)

Ich habe ein Beispiel in die Einleitung gepackt und einige weniger wichtige Fachbegriffe und Links entfernt. Ich denke dadurch ist die Einleitung auch für Laien verständlich geworden. --Traxer 10:01, 18. Jan. 2010 (CET)

SQL3

Der SQL3 Standard hat viele wesentliche Erweiterungen gebracht. (Objekt-relationale Erweiterungen, prozedurale Sprachelemente) Ich fände es gut, wenn die kurz hier skizziert würden. Ich schreibe gerade an einem Artikel über eingebettete Datenbanksysteme, die nicht den SQL3-Umfang unterstützen, sondern nur den SQL1-Umfang oder nur Ausschnitte davon. Es wäre gut, wenn der SQL-Artikel die Unterschiede der einzelnen SQL-Standards deutlich machen würde.

Sind die ANSI-Dokumente eigentlich im Internet verfügbar? Wenn ja, dann wäre ein Link darauf ganz gut. -- 82.135.37.138 12:13, 28. Feb. 2007 (CET)

ANSI oder ISO Normen stehen unter Copyright und sind grundsätzlich vergütungspflichtig (und ziemlich teuer). Ein Link darauf wäre ein Link auf eine illegal in das Netz gestellte Kopie. --EFR 20:58, 28. Feb. 2007 (CET)

Ein Link auf irgendwelche unter Copyright stehende Dokumente muss ja auch nicht sein. Trotzdem fände ich es für diesen Artikel wichtig zu beschreiben, worin sich die einzelnen SQL-Standards unterscheiden, bzw. in welchen Bereichen die Erweiterungen in den letzten Jahren neue Definitionen geschaffen haben. In dem Artikel wird der zweifellos wichtige Teil der Abfragen mit SELECT sehr ausführlich beschrieben, während die anderen Bereiche noch nicht einmal vollständig benannt werden. --Julius-m 21:00, 29. Apr. 2010 (CEST)

Erweiterungen

Es gibt noch mehr ISO- bzw. ANSI-Erweiterungen des SQL-Standards:

• SQL/OLAP (neue Gruppierungs-Funktionen, Window-Konstrukt, Bucket-Funktion, Pivot-Operator)
• Wie sieht es aus mit LOB-Verarbeitung? Ist das nicht auch Gegenstand der ANSI- und ISO-Normen?
• Objektrelationale Erweiterungen ?

Die Beschreibung dieser (neueren) Erweiterungen ist in dem Artikel bis jetzt sehr dürftig im Vergleich zur Beschreibung des SQL2 Standards. Es ist lediglich erwähnt, dass es eine 'Vielzahl von Erweiterungen des SQL-Standards' gibt. --Julius-m 21:21, 3. Jan. 2008 (CET)

Kaskadierung

Kann mir jemand erklären was genau Kaskadierung ist. Hab das zwar gelesen das durch Kaskadierung ein datensatz & ein dazugehöriger Datensatz durch eine Fremdschlüsselbeziehung gelöscht werden kann. Aber was ist die Definition von einer Kaskade? --Skia 12:29, 7. Jan. 2007 (CET)

Das ist beschrieben in Referenzielle Integrität -- 77.176.218.244 20:58, 2. Mär. 2007 (CET)

Lemma SQL vs Structured Query Language

Habe für SQL auch schon des öfteren "Standard Query Language" statt oder neben "Structured Query Language" gelesen. Mir wurde gesagt, dass beides richtig, "Standard" dabei aber der neuere Begriff wäre. Wer kennt sich genau aus? Vielleicht sollte in dem Artikel auf die andere Begriffsdeutung hingewiesen werden.

MfG, Franz

 Hab' ich auch im Hinterkopf: 'structured' ist die veraltete Abkürzung.
 Allerdings habe ich keine stichhaltige Quelle gefunden.
 -- 195.37.188.211 10:26, 15. Apr 2005 (CEST)

SQL ist gar kein Akronym sondern ein eigenständiger Name. SQL hat sich aus der 1974/75 bei IBM entwickelten Datenbank-Abfragesprache SEQUEL entwickelt. Dieser Name stand für Structured English QUEry Language. SEQUEL wurde als Impementation von E.F.Codds relationalem Datenbankmodell entwickelt, das er 1970 in dem Artikel 'A Relational Model of Data for Large Shared Databanks' veröffentlichte.

Im Artikel steht zur Zeit nur, wofür SQL nicht stünde: "Oftmals wird SQL fälschlicherweise für eine Abkürzung für Structured Query Language bzw. Standard Query Language gehalten, ...". Aber leider ist nicht erklärt, für was es denn nun steht. Und sei es, dass es kein Akronym sei (was wirklich seltsam wäre). --Daniel Wimpff 23:21, 18. Sep 2005 (CEST)

In der Diskussion zu en:SQL ist zu lesen, dass laut ANSI der Name SQL keine Abkürzung ist, aber häufig für eine gehalten wird. Der Vorgänger SEQUEL war hingegen eine Abkürzung, konnte aber aus markenrechtlichen Gründen nicht mehr verwendet werden. Die Aussprache von SQL ist demnach ess-ku-ell. -- MfG Doodee 01:19, 25. Sep 2005 (CEST)

Habe jetzt die Aussprache ess-ku-ell eingesetzt. en:SQL: "ANSI has declared that the official pronunciation for SQL is ess kyoo ell, although many English-speaking database professionals still pronounce it as sequel."

Der Optimizer ist eine datenbankinterne Funktionalität moderener DBMSe, die nicht nur bei statischem SQl zur Anwendung kommt. Für jedes SQL-Statement berechnet der Optimizer einen optimalen Ausführungsplan, sofern dieser nicht explizit vorgegeben wird oder der Ausführungsplan des Statement explizit ohne Einsatz des Optimizers (regelbasiert) erstellt werden soll.

MfG, Freedt

Hallo, Der Artikel heisst Structured_Query_Language, und im ersten Absatz steht "Oftmals wird SQL fälschlicherweise für eine Abkürzung für Structured Query Language...gehalten" - das macht keinen Sinn. Entweder Artikeln in SQL umbenennen oder diesen Absatz revidieren. --Snooper77 11:49, 3. Okt 2005 (CEST)

Dem schließe ich mich an. Ich finde das auch höchst verwirred und bin auch über dieses ersten Absatz gestolpert! --Gast

Hallo, Hab ne Quelle gefunden, IT-Handbuch IT-Systemelektroniker/-in Fachinformatiker/-in vom Westermann Schulbuchverlag GmbH in Braunschweig, aktuelle Ausgabe des Buches 4. Auflage 2005. Auf der Seite 226 dieses Buchen ist eine kurze Zusammenfassung über SQL und der Hinweis das die Abkürzung SQL mittlerweile für Standart Query Language steht. Westermann ist ein vertrauenswürdiger Verlag, da die Westermann Schulbücher auch von den IHK-Schulungen empfohlen werden denke ich das diese Quelle ok is.

Gruß Klaus

Also, um das hier mal alles festzuhalten: Beides ist richtig! Sowohl Standard Query Language als auch Structured Query Language , wobei ich sagen muss, dass Structured Query Language aussagekräftiger & noch immer der ofizielle Name ist. MfG --Skia 13:36, 7. Jan. 2007 (CET)

Hallo,

um das einfach mal klar zu stellen - im SQL Standard (ISO/IEC 9075) ist keine Langform aufgezeichnet. Ich sitze im DIN Gremium und habe letztes Jahr die amerikanischen Herren, die den SQL Standard damals bei ANSI ins Leben gerufen haben, zur Sicherheit nochmal gefragt. SQL ist ein eigenständiger Name und keine Abkürzung. Es wird Es-Kuh-El ausgesprochen und nicht Sie-Quell. Da können noch so viele Amerikaner anderer Meinung sein. MfG --miracee 16:44, 19. Jul. 2013 (CEST)

---

Wie schon gesagt wurde, offiziell bedeutet SQL gar nichts und wird Ess Ku Ell ausgesprochen. So wird die nicht-Abkürzung auch im Buch "Webdatenbank-Applikationen mit PHP und MySQL" vom O'REILLY Verlag beschrieben. Auch in "Einführung in SQL" von O'Reilly ist dem so.

mfg, Gast :P

---

Da ich mich gerade auf meine DB1-Klausur vorbereite, bin ich über diesen Artikel gestolpert und habe dabei erhebliche Diskrepanz zu den Ausführungen meines Prof. entdeckt. Der mir gelehrte geschichtliche Hintergund von SQL geht auf E.F. Codd zurück, der 1970 seinen Artikel "A Relational Model of Data for Large Data Banks" veröffentlichte. Man begann dann im IBM San Jose Research Laboratory über einer Sprache zu forschen, die dazu geeignet wäre, dieses Modell zu implementieren. Diese Sprache wurde SEQUEL genannt, ein Akronym für Struktured English QUEry Language. Nach 1975 wurde eine überarbeitete Version SEQUEL/2 entwickelt. Diese Version wurde in SQL umbenannt. Damit geht SQL durchaus aus SEQUEL hervor, der Name SQL ist jedoch kein Akronym (steht deshalb auch nicht für "Structured Query Language") und wird auch nicht "sequel" ausgesprochen. Als Quelle hierfür dient mir das Skript "Datenbanken I", Kurseinheit 2 der FernUniversität in Hagen von G. Schlageter, D. Becking, P. Rosenthal und W. Wilkes auf Seite 25 und folgend. Wobei natürlich die Ausführungen der ANSI nicht weniger Wert sein sollten :) Außerdem widerspricht der erste Satz dem Abschnitt "Name". Da hier irgendwie kaum einer unterschreibt, weiß ich nu nich genau, wie alt das hier alles ist, aber falsch ist es auf jeden Fall. Wenn keiner Einwände hat, werde ich das demnächst umformulieren. --Felbion 20:34, 11. Sep. 2009 (CEST)

Gibt's das Script wohl online zu lesen, oder kanst Du auszugsweise zitieren? --Traute Meyer 22:38, 11. Sep. 2009 (CEST)

Das Skript ist keine Freeware, kann also nicht einfach so heruntergeladen werden. Kannst es dir aber bestimmt bestellen. Frag einfach mal bei der FernUni nach. Hast du dabei Interesse an dem Skript oder willst die Behauptung überprüfen? Das mit dem ANSI-Standard läßt sich bestimmt ergooglen. Und die anderen Bücher kann man bestimmt auch bestellen. Und da sich der Artikel sowie so selbst widerspricht: Der erste Satz vs. dem Abschnitt Name, denke ich, dass eine konsequente (und richtige) Korrektur sinnvoll und wichtig ist. --Felbion 10:11, 16. Sep. 2009 (CEST)

So stelle ich mir den Kopf des Artikels vor:

SQL (offizielle Aussprache [ɛskjuːˈɛl]) ist eine Datenbanksprache zur Definition, Abfrage und Manipulation von Daten in relationalen Datenbanken. SQL ist von ANSI und ISO standardisiert und wird von fast allen gängigen Datenbanksystemen unterstützt. SQL umfasst die folgenden Datenbanksprachen: Data Manipulation Language, Data Definition Language, Data Control Language.

Die Syntax von SQL ist relativ einfach aufgebaut und semantisch an die englische Umgangssprache angelehnt. Abfragen wie: "finde alle Kunden, die im letzten Monat keine Bestellung aufgegeben haben!" sind sehr einfach zu realisieren. SQL stellt eine Reihe von Befehlen zur Definition von Datenstrukturen nach der relationalen Algebra, zur Manipulation von Datenbeständen (Einfügen, Bearbeiten und Löschen von Datensätzen) und zur Abfrage von Daten zur Verfügung. Durch seine Rolle als Quasi-Standard ist SQL von großer Bedeutung, da eine weitgehende Unabhängigkeit von der benutzten Software erzielt werden kann.

Der Dritte Absatz bleibt so wie er ist erhalten, der vierte ist redundant, da die hier aufgeführten Daten bereits in einem eigenen Abschnitt "Geschichte..." enthalten sind, fällt also weg. --Felbion 10:24, 16. Sep. 2009 (CEST)

Da es keine Einwände gibt, werde ich wohl diese Woche den Artikel ändern. -- Felbion 23:09, 2. Nov. 2009 (CET)

Hallo Felbion, es war nicht zu erwarten, daß du hier irgendwelche Kommentare zu deinem Änderungsvorschlag bekommst, da er unter ein längst veraltetes Diskussionsthema "druntergeklemmt" wurde. Das Lemma wurde bereits geändert, es heißt nicht mehr "Structured_Query_Language" sondern "SQL" und dein Änderungsvorschlag hat nichts mit dem Titel bzw. der Überschrift des Artikels oder dem Suchbegriff, sondern mit dem Inhalt des Artikels zu tun, geht also am Thema dieser langen alten Diskussion glatt vorbei.

Bitte leg ein neues Thema (ganz unten auf dieser Seite !) an, wenn du etwas neues zur Diskussion stellen willst, und beachte, daß du dich auf die aktuelle Version des Artikels beziehen solltest. Bitte kopier auch nicht ganze Absätze aus dem Artikel - ohne jede Hervorhebung - hierher, sondern kennzeichne deine Änderungen deutlich (durch Unterstreichen neuer Inhalte und Durchstreichen alter Inhalte - bitte nicht einfach "wegschneiden"), sodaß man nicht Wort für Wort mit dem bisherigen Artikel vergleichen muß, um die Änderungen zu finden - DANKE !

Einen "3. und 4. Absatz" kann ich im Anfang des Artikels nicht finden (es gibt nur 2 erkennbare Absätze) und somit dein (sinngemäß) behauptetes "4. Absatz redundant" auch nicht nachvollziehen.

Dein Beispiel ("finde alle Kunden ...") gehört eigentlich nicht in die Einleitung, weil es redundant zu mehreren weiter unten stehenden Beispielen ist. Wie die Formulierung in SQL konkret aussehen würde, sollte in unmittelbarer Nähe zum englischen Frage-Satz stehen, sonst hilft das Beispiel nicht weiter.

Ob man SQL als "einfach" oder "schwer" ansieht ist eine Meinung (kein NPOV) und du selbst relativierst diese auch sofort (mit "relativ einfach"). Die vielen (inzwischen) entstandenen Dialekte machen manche Implementierung von SQL sehr "gewöhnungsbedürftig" für Leute, die (wie ich) schon Jahre in SQL programmieren und erschweren die Übertragung (Portierung) von "fertigem SQL" von einem "Dialekt" (einer Implementierung) zu einem/einer anderen erheblich. --PhChAK 14:27, 3. Nov. 2009 (CET)

Referentielle Integrität

Im Abschnitt über referentielle Integrität ist offenbar etwas verloren gegangen:

" ... Da eine Datenbank die allen Anforderung der 3. oder sogar 5. Normalform entspricht in der Praxis bedingt durch Performanceprobleme nicht zu verwenden wäre, werden nachträglich Redundanzen bewußt in Kauf genommen, um zeitaufwändige und komplexe kommt, dieses nicht nochmal parsen zu müssen und so Zeit zu sparen.

Beide Arten von SQL haben ihre Vor- und Nachteile. ..."

Leider weiß ich auch nicht, was der Autor damit meint.

Viele Grüße Jürgen

Da fehlte offenbar ein ganzer Textblock vom 4.4.05, habs repariert -- Pumuckl2 21:39, 13. Apr 2005 (CEST)

Semikolon

Unter

     Befehle zur Datenmanipulation: INSERT, UPDATE, DELETE

sind in den Beispielen keine Semikolon am Ende eines Befehls gesetzt. Bsp.:

     * insert into Adressen (Name, Vorname, Ort) values ('Schroeder', 'Kurt', 'Köln')
   
     Fügt eine Zeile mit den geg. Werten für die Spalten Name, Vorname und Ort in die Tabelle  
     Adressen hinzu. 

So wie ich gelernt habe, müsste es wie folgt heissen:

     * insert into Adressen (Name, Vorname, Ort) values ('Schroeder', 'Kurt', 'Köln');

Sollte dies korrekt sein, so sollte es auch so (mit Semikolon) in den Beispielen stehen.

Das sehe ich auch so. Habe mir erlaubt das zu ändern und beiläufig aus "Schroeder" 'Schroeder' gemacht. Drei bis vier einfache Beispiele zu DQL wären nicht schlecht, schließlich ist das die häufigste Anwendung. Sicher fällt dazu jemandem was ein, mir fallen erstmal die Augen zu.

Jürgen

Sehe ich nicht so ... MySQL braucht das, aber SQL-89 zumindest benötigt kein Trennzeichen für die Sequenz von Anweisungen, es ist ja ziemlich klar, wo in der Anweisungsfolge SELECT * FROM Adressen DROP TABLE ADRESSEN die Anweisungen aufhören. Ich kann morgen kucken, ob Oracle und PostgreSQL das brauchen, AFAIK nicht. Mit unserem MS-SQL-Server kenne ich mich leider nicht genug aus, um irgendwo SQL-Statements auf einer Kommandozeile eingeben zu können ... Die Sequenz (Anweisung1; Anweisung2) kommt ja eh nur in Stored Procedures vor. Fragment 01:15, 8. Aug 2005 (CEST)

Korrektur: Ich habe nachgeschaut, die Clients sqlplus (Oracle) und mysql (MySQL) möchten beide Semikolons. psql (Postgres) möchte auch eines, das Trennzeichen ist aber auf newline umschaltbar. Fragment 13:37, 9. Aug 2005 (CEST)

Quellen:

mysql-Dokumentation: "A command normally consists of an SQL statement followed by a semicolon."

http://www.w3schools.com/sql/sql_intro.asp: "Some database systems require a semicolon at the end of the SQL statement. We don't use the semicolon in our tutorials."

D.h. das Semikolon ist gar nicht Teil der SQL-Anweisung, sondern wird lediglich von Befehlszeilentools verwendet, um mehrere SQL-Anweisungen nacheinander eingeben zu können.

Übrigens sind Semikolons auch anderswo absolut unüblich: in Programmen, die SQL-Anweisungen absetzen, und in Webclients wie phpmyadmin.

Ich würde sie daher in den Beispielen weglassen und ggf. erwähnen, dass manche Programme für die Eingabe ein Semikolon erwarten.

Joachim Durchholz [[1]]

Das Semikolen ist nur für das API oder den Präcompiler, dass/der die SQL-Befehle entgegennimmt. Bei einigen Tools kann man auch andere Anweisungstrenner wählen. Für die Definition von Triggern in DB2 muss man sogar ein anderes Anweisungstrennzeichen auswählen, um zwischen dem Anweisungsende eines Statements innerhalb des Triggers und dem Ende der Triggerdefinition selber unterscheiden zu können.

Das Semikolon ist jedenfalls kein Bestandteil eines SQL-Statements. -- 82.135.37.138 12:19, 28. Feb. 2007 (CET)

Standards

SQL ist nicht nur ein Quasistandard, sondern es ist ein Standard, den es in verschiedenen Versionen gibt. Dazu gehören unter anderem nach ANSI SQL86, SQL89 und SQL92, welchem mySQL zum Beispiel annähernd befolgt. Jedoch hält keins der Datenbanksysteme einen SQL-Standard zu 100% ein.

SQL ist inzwischen ein ISO Standard, die neueste Version ist : ISO/IEC 9075-1:2003, zu Beziehen unter http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=34132&ICS1=35&ICS2=60&ICS3=&scopelist=

MySQL (Version 3 zumindest) ist das schlechteste Beispiel, das Du nehmen konntest: Keine Integrität (primary key etc. wird schlicht ignoriert), keine Orthogonalität (keine SFW-Blöcke in FROM oder WHERE). MySQL lehnt sich bestenfalls an SQL an. Ich persönlich benutze selbst übrigens auch MySQL, aber das Lob hat es wirklich nicht verdient. Fragment 01:25, 8. Aug 2005 (CEST)

Hallo Fragement, koenntest Du kurz erlaeutern, was mit Orthogonalitaet udn SFW-Bloecke gemeint ist? -- Gruss sparti 19:03, 8. Aug 2005 (CEST)

Ja, das muss ich wohl können, wenn ich die Prüfung überleben will ;-) SFW-Block = "Select-From-Where-Anweisung". Othogonal ist eine Abfragesprache, wenn Abfragen beliebig ineinander eingesetzt werden können, also Abfragen auf dem Ergebnis von Abfragen (sog. Unterabfragen) definiert werden können (ohne dabei Sichten zu benutzen). SFW-Block im FROM-Teil:

  SELECT *
  FROM ( (SELECT Vorname, Nachname FROM Professoren)
         UNION
         (SELECT Vorname, Nachname FROM Studenten)) Elfenbeinturmbewohner

SFW-Block im WHERE-Teil (arbeitslose Studenten):

  SELECT *
  FROM Studenten s
  WHERE NOT EXISTS (SELECT * FROM HIWIS WHERE Matrikelnr = s.Matrikelnr)

Ich glaube, dass SQL ohne Unterabfragen nicht streng relational vollständig (Relationale Algebra) ist. Ich muss aber gleich weg, deshalb belasse ich es beim Glauben ;-) Grüße, Fragment 19:22, 8. Aug 2005 (CEST)

1. Ich habe nachgegoogelt, und ich glaube inzwischen das Gegenteil, aber einen Beweis oder eine plausible Aussage habe ich immer noch nicht gesehen. In den Abfragen kann man anscheinend WHERE NOT EXISTS durch ein OUTER JOIN mit WHERE ISNULL(...) abbilden, und damit alle Existenzquantoren (ALL formel = NOT EXISTS (NOT(formel)) etc., WHERE EXISTS ist sowieso implizit). Über Unterabfragen im FROM-Teil gibt's was in der Orakel-Anleitung unter "inline view", sonst weiß google auch nix. Was angeblich nicht geht, ist ein Ersatz von Unterabfragen mit Aggregationsfunktionen im WHERE-Teil (wie in SELECT MatrikelNr FROM Prüfungen WHERE Note > (SELECT AVG(Note) FROM Prüfungen) ). Aggregationsfunktionen sind aber nicht Teil der normalen Relationenalgebra. Doh. Ich frag meinen Prof mal.

2. MySQL kann ab Version 4.1 SELECT-Anfragen zumindest im WHERE-Teil. Über FROM-Teil oder "inline views" oder - bewahre! - SFW-Blöcke im SELECT-Teil habe ich nirgends was gelesen. Fragment 23:36, 9. Aug 2005 (CEST)

Hallo Fragment,

kannst Du nochmal etwas zu den verschiedenen Standards schreiben? Vorallem fehlt der Objektrelationale Teil im Augenblick vollstaendig, was sehr schade ist. -- Gruss sparti 10:21, 4. Okt 2005 (CEST)

Hallo,

ein paar Anmerkungen habe ich: 1. es wäre schön, wenn erwähnt würde, dass auch Deutschland (vertreten durch ein DIN Gremium) aktiv am SQL Standard beteiligt ist. 2. Die bereitgestellten Arbeitsdokumente von 2008 sind die Entwurfsdokumente der USA (des ANSI Gremiums). Diese Dokumente sind mit großer Vorsicht zu genießen. Nicht alles was dort zu finden ist, ist auch tatsächlich im ISO Standard umgesetzt worden.

3. Neben DDL, DML und DCL gibt es noch DQL (Data Query Language (SELECT)) und TCL (Transaction Control Language (START TRANSACTION, SAVEPOINT, ROLLBACK, COMMIT)) 16:31 19. Jul 2013 (CEST)

Hallo,

ich würde gerne die Liste der Standards aktualisieren. Seit ein paar Tagen gibt es den neuen Teil:

ISO/IEC 9075-15:2019 Information technology database languages -- SQL -- Part 15: Multi-dimensional arrays (SQL/MDA)

Weiterhin gibt es eine Reihe technischer Reports zu einzelnen Funktionalitäten:

ISO/IEC TR 19075-1:2011 Information technology -- Database languages -- SQL Technical Reports -- Part 1: XQuery Regular Expression Support in SQL

ISO/IEC TR 19075-2:2015 Information technology -- Database languages -- SQL Technical Reports -- Part 2: SQL Support for Time-Related Information

ISO/IEC TR 19075-3:2015 Information technology -- Database languages -- SQL Technical Reports -- Part 3: SQL Embedded in Programs using the JavaTM programming language

ISO/IEC TR 19075-4:2015 Information technology -- Database languages -- SQL Technical Reports -- Part 4: SQL with Routines and types using the JavaTM programming language

ISO/IEC TR 19075-5:2016 Information technology -- Database languages -- SQL Technical Reports -- Part 5: Row Pattern Recognition in SQL

ISO/IEC TR 19075-6:2017 Information technology -- Database languages -- SQL Technical Reports -- Part 6: SQL support for JavaScript Object Notation (JSON)

ISO/IEC TR 19075-7:2017 Information technology -- Database languages -- SQL Technical Reports -- Part 7: Polymorphic table functions in SQL

ISO/IEC TR 19075-8:2019 Information technology -- Database languages -- SQL technical reports -- Part 8: Multi-dimensional arrays (SQL/MDA)

Die würde ich auch gerne in den Artikel aufnehmen. --Dbspezi (Diskussion) 00:24, 28. Jun. 2019 (CEST)

Verwirrender Code

• SELECT a.Name, a.Vorname, a.Plz, a.Ort FROM Adressen a, Namenliste n WHERE a.Name = n.Name;

Das ist doch verwirrend! Müsste es nicht eher heissen:

• SELECT a.Name, a.Vorname, a.Plz, a.Ort FROM a, n WHERE a.Name = n.Name;

Die darunterliegende Beschreibung sollte ebenfalls angepasst werden.

Nein, der Code ist so richtig. a und n sind hier nur Aliase für die Tabellen Adressen respektive Namenliste. Ebenso stimmt auch die Beschreibung unter der Abfrage. --Herr Schroeder 16:53, 14. Jun 2005 (CEST)

Besser wäre der Code IMHO nur, wenn man den JOIN auch per JOIN-Statement definiert hätte. Aber falsch ist dadurch der Code natürlich nicht, jedoch kann man so besser zwischen JOIN-Bedingungen und Selektionsbedingungen unterscheiden. --MadMetzger 22:14, 14. Jun 2005 (CEST)

• SELECT a.Name, a.Vorname, a.Plz, a.Ort FROM Adressen a NATURAL JOIN Namenliste n ON a.Name = n.Name;

Ich habe — mit Verlaub gesagt — Mühe mit dem Niveau dieser Diskussion um SQL-Trivia — wollt Ihr das Verfassen des SQL-Artikels nicht jemand überlassen, der SQL kann?! Was ist denn ein "NATURAL JOIN"?! — Nol Aders 11:40, 15. Jun 2005 (CEST)

Das ist SQL und ich vermute, dass die Leute hier SQL können. Es gibt halt Datenbanken, welche die NATURAL JOIN Schreibweise nicht beherrschen. Von daher bin ich gegen diese Schreibweise oder allenfalls als Alternativschreibweise. Die Schreibweise davor versteht jedoch jede Datenbank. --Herr Schroeder 14:15, 15. Jun 2005 (CEST)

Das macht schon Sinn. Ich denke man sollte zum Thema Join einen eigenes Kapitel machen. Die Kritik von Nol Aders bezog sich wahrscheinlich auf die falsche Verwendung von "Natural Join". Das nachfolgende "ON" fuhert diesen ad absurdum.

-- Sparti 14:40, 15. Jun 2005 (CEST)

Das kann sein, dass ich den "Natural Join" falsch verwandt habe. Was ich eigentlich meine, ist wahrscheinlich ein "Normal Join". Werde mal das "NATURAL" rausnehmen, jedoch vorher noch mal in meinen Unterlagen nachschauen, da ich mir da nicht zu 100% sicher bin. --MadMetzger 16:03, 15. Jun 2005 (CEST)

Ich meinte im allgemeinen, dass die Join-Semantik nicht von allen Datenbanksystemen verstanden wird. Besonders ist hier eine große Datenbank namens Oracle zu nennen. --Herr Schroeder 17:30, 15. Jun 2005 (CEST)

Da wirst du bestimmt recht haben, jedoch ist dann die Frage, ob man versucht einen gemeinsamen Nenner der RDBMS zu finden, oder zu versuchen den ANSI-Standard auszuleuchten. Und in einem der Standards ist garantiert die JOIN-Syntax enthalten. --MadMetzger 21:11, 15. Jun 2005 (CEST)

Ja, dieser Join stammt aus SQL-92 afaik... Eine Schreibweise dagegen, welche jede Datenbank versteht ist:SELECT a.Name, a.Vorname, a.Plz, a.Ort FROM Adressen a, Namenliste n WHERE a.Name = n.Name;. Von daher sollte diese Schreibweise auf jeden Fall genannt werden. Ich habe gerade gesehen, dass Oracle seit 9i auch den NATURAL JOIN unterstützt. --Herr Schroeder 08:35, 16. Jun 2005 (CEST)

Der NATURAL JOIN führt automatisch einen JOIN über alle Felder gleichen Namens der verknüpften Tabellen aus, ein ON ist daher überflüssig. Passend währe hier ein INNER JOIN, wobei man das INNER auch weglassen kann. Das Beispiel sähe dann so aus: SELECT a.Name, a.Vorname, a.Plz, a.Ort FROM Adressen a JOIN Namenliste n ON a.Name = n.Name; Diese Syntax sollte jedes DBMS verstehen. Zu bedenken wäre auch, das die Performance bei einem JOIN je nach DBMS besser sein kann als bei einem JOIN per WHERE-Statement.

Ein eigenes Kapitel zu dem Thema waere schoen. Schon allein wegen der Bedeutung von Joins macht das Sinn. -- Sparti 08:59, 16. Jun 2005 (CEST)

TODO

• Beispiele noch mal durchsehen, ggfs. sinnvoll aufeinander aufbauend strukturieren
• Syntax nochmal kontrollieren, und dann nochmal (HILFE)
• Geschichte von SQL aus Büchern und der en: zusammenklauben
• JOIN-Absatz machen, wie oben gefordert

Anmerkung: Der JOIN gehört zur Relationalen Algebra und ist dort auch schon ausführlich in einem eigenen Absatz beschrieben. Hierher gehört nur wie eine JOIN Operation in SQL umgesetzt wird, z.B. WHERE Klausel u.s.w. --213.6.179.82 14:39, 26. Okt 2005 (CEST)

• Verweise auf andere Abfragesprachen einbauen
• Standardisierungs-Wirrwarr ein bisschen darstellen
• ggfs. SQL-Erweiterungen einzelner Hersteller darstellen (HILFE)

Anmerkung: Ich denke hier geht es um SQL und nicht um die einzelnen Implementierungen der Hersteller. Ich denke das Spränkt bei weitem den Artikel. Würde also eher sagen Herstellerspezifische sachen entfernen. Das MySQL Subselects in den 3.x Versionen nicht unterstützt gehört hier nicht rein Jnandreae 20:09, 22. Mär 2006 (CET)

• Orthogonalität SQL-89 vs. SQL-92 erläutern

Ich benutze das hier als meine persönliche TODO-Liste, lasst Euch nicht verwirren ;-) Fragment 00:54, 8. Aug 2005 (CEST)

Ich benutze sie mal einfach mit, ok? :)

• Habe die Geschichte von SQL hinzugefügt, lässt sich aber sicher noch erweitern...
• Ausserdem finde ich es erwähnenswert, dass es sich bei SQL um eine (die wohl bekannteste) 4GL Sprache handelt. Das müsste noch irgendwo eingebaut werden. (In der Einführung)

Ist es nicht. SQL ist keine vollständige Programmiersprache, z.B. die Ackermann-Funktion geht damit nicht. (Siehe 4GL: "Gemeinsames Hauptziel aller 4GL ist es jedoch, im Vergleich mit Drittgenerationssprachen dieselbe Funktionalität mit weniger Code zu erreichen." SQL ist beschränkte Funktionalität.) Joachim Durchholz [[2]]

• In der Einführung sollte auch erwähnt werden, dass es sich um eine mengenorientierte Sprache handelt, da dies ein wesentliches Merkmal von SQL ist

--Andoro 03:09, 26. Okt 2005 (CEST)

• Ich habe mal einen Tippfehler bei den Untergruppen korrigiert und die DQL auch als solche benannt. Leider landet der Link immer noch bei der DML (das war der Fehler). Kann das bitte jemand ändern, der weiß wie das geht, bzw. woran das liegt? --84.175.231.69 06:39, 7. Mai 2007 (CEST)

Siehe Diskussion:Datenbanksprache und Data Manipulation Language --EFR 12:01, 8. Mai 2007 (CEST)

Wikibooks und Wikipedia

Ich finde ein grossteil davon gehrt nicht in die WIkipedia, sondern in die Wikibooks. Das ist mehr eine ANleitung als ein Lexikonartikel.

Nur so, in meinem Informatik-Duden stehen 7 1/2 Seiten dazu. Grüße, Fragment 20:04, 23. Aug 2005 (CEST)

Soll das hier ein Fachbuch werden oder was?

Habe nur kurz gesucht, seit wann es das SQL gibt, doch leider nichts gefunden. Die Wiki En ist da auskunftsfreudiger. Nur als Anregung für die Fachleute ;-)

Dem schließe ich mich an. Vielzu viele Fachwörter bzw. Fremdwörter werden hier benutzt, so dass erstmal diese nachgeschlagen werden müssen. Sofern ich weiß, widerspricht das den Ansprüchen der Wikipedia. Das geht doch bestimmt anders ;-)

Fremdschlüssel

---

Fremdschlüssel (auch Foreign Key genannt) bezeichnen im Bereich der relationalen Datenbanken ein Attribut einer Relation (Tabelle), das auf den Primärschlüssel einer anderen Relation verweist.

---

Meines Wissens nennen sich Relationen auch Entitätsbeziehungen - also sind dieses die Verbindungen zwischen Entitäten und somit Verbindungen zwischen Tabellen, die auf der Verbindung von PK mit FK beruhen. Relationen können zwar Attribute aufweisen, Fremdschlüssel sind jedoch keine Attribute einer Relation!

Folgerichtig sollte der zitierte Satz lauten:

Fremdschlüssel (auch Foreign Key genannt = FK) bezeichnen im Bereich der relationalen Datenbanken ein Attribut einer Tabelle, das auf den Primärschlüssel(Primary Key = PK) der referenzierten Tabelle verweist.

---

Ein Fremdschlüssel kann, muss aber nicht Primärschlüssel seiner Relation sein.

---

Na was nun? Ist das gemeinte Feld nun PK oder FK? Auch hier die Verwirrung - Ein Fremdschlüssel kann, muss aber nicht der Primärschlüssel (oder Teil des PK) seiner TABELLE sein!

Programmierschnittstelle

Hier wird ODBC erwähnt. Gehört ADO nicht auch in diesen Kontext? -- 82.135.37.138 13:57, 8. Mär. 2007 (CET)

Folgender Satz ist unglücklich formuliert: SQL ist keine Turing-vollständige Programmiersprache.

1. ist SQL überhaupt keine Programmiersprache, sondern eine Abfragensprache. Structured Query Language.

2. wurde SQL mit dem SQL-3 Standard um viele impreative Sprachelemente erweitert, die aus SQL eine vollumfängliche Programmiersprache machen, die auch Touring-vollständig ist. --Julius-m 12:44, 24. Dez. 2007 (CET)

Also eine Abfragesprache ist eine spezielle Programmiersprache, um Datenbanken mitzuteilen, welche Daten man haben will. Somit ist eine Abfragesprache durchaus eine Programmiersprache.

Der Punkt 2 ist moeglicherweise wahr - ich habe mich mit dem Thema nicht befasst. Aber da SQL-3 bis heute nicht etabliert ist, sollte man wenigstens darauf hinweisen, dass SQL bis Version 2 nicht Turing Vollstaendig ist. -- sparti 22:49, 24. Dez. 2007 (CET)

PL/SQL ist die Realisierung des SQL3-Standards von Oracle. PL/SQL ist doch eine weit verbreitete Programmiersprache. Die meisten anderen Server-Datanbanksysteme bieten ähnliche Lösungen, die sich nur wenig voneonander unterscheiden. --Julius-m 21:12, 3. Jan. 2008 (CET)

Wenn eine Abfragesprache eine Programmiersprache wäre, so stünde das im entsprechenden Wikipedia-Artikel. Tut es aber nicht. --80.153.250.36 11:40, 15. Jun. 2016 (CEST)

Sprachschichten??

Mir gefällt der Ansatzpunkt Sprachschichten aus mehreren Gründen nicht so gut:

• Die Unterscheidung zwischen DML, DDL und DCL ist eine von SQL unabhängige Unterteilung, die es bereits in den 1960ern gab. In der deutschen Wikipedia wird sie immer ausschließlich mit SQL in Verbindung gebracht, vgl. DCL.
• Die SQL Norm selbst verwendet diese Unterteilung meiner Recherche nach nicht.
• Hersteller handhaben es mal so, mal so, so wird bei Oracle z.B. das GRANT als DDL bezeichnet.
• Das Akronym DQL und die damit eingeführte zusätzliche eigenständige Sparte "reine Abfrage" geht mir persönlich zu weit. Die SQL-Norm kategorisiert die Abfrage ebenfalls als Manipulations-Teil (obwohl Manipulation wortwörtlich natürlich über Abfragen hinaus geht). Außerdem ist DQL meiner Recherche nach ein nicht gängiger IT-Begriff (bitte jetzt nicht mit GOOGLE-Treffern kommen!).
• Die Formulierung "eigenständige Sprachschichten" stimmt so nicht.
  • Das SELECT ist ein möglicher Bestandteil von UPDATE, DELETE und INSERT.
  • Es gibt faktisch keine Schnittstelle, in der man z.B. nur die DCL oder nur die DDL einsetzen kann, was das Wort eigenständig ja impliziert. Nebenbemerkung: Das war der Ursprung der früheren Unterscheidung zwischen DML, DDL und DCL: Bei IMS konnte man z.B. DDL nur in Assembler und DML nur mit Call-API einsetzen, DCL nur mittels RACF o.ä..
  • Der Begriff Schicht hat in der Softwaretechnik eine eindeutige Bedeutung im Sinne einer Schichtung von Ebenen. Das macht im Zusammenhang DDL, DML und DCL keinen Sinn.
• Befehle zur Transaktionskontrolle passen nicht in das Schema und fehlen (deshalb?) ganz im Lemma "Sprachschichten".
• Detail bei DCL: 'Control' heißt in diesem Zusammenhang nicht "Kontrolle".

Vorschlag: Die Unterteilung der Sprache in unterschiedliche Sparten macht Sinn und sollte unbedingt so beibehalten werden. Nur sollte man meiner Meinung nach den Zusammenhang zu den Akronymen DML, DDL und DCL berichtigen und diese Akronyme aus den Lemmata rausnehmen. Der Begriff Schicht sollte ganz entfallen, ebenso das Akronym DQL.

Aus "Data Query Language: SELECT" wird so z.B. "Abfragen: SELECT", aus "Data Definition Language: CREATE ..." wird "Datendefinition: CREATE ...". Wie immer interessiert mich eure Meinung. --EFR 13:10, 15. Jan 2006 (CET)

Heuer/Saake, Datenbanken: Konzepte und Sprachen, verwenden die Kürzel wie hier geschrieben für den allg. Teil, im SQL-Teil habe ich beim kurzen Durchblättern 1 Stelle gesehen, dort aber auch eine "Übersetzung" wie Du sie vorgeschlagen hast. Ich bin durchaus dafür, die Akronyme aus dem Text raus zu optimieren, also wenn's jemand anders macht ... ;) Ahoi Fragment 20:56, 28. Mai 2006 (CEST)

Ich habe gerade mal in der Oracle-Dokumentation nachgeschaut. Auch Oracle spricht von DDL und DML. Der Begriff DQL kommt dagegen selten vor. Ich wäre auch dafür den Begriff Sprachschichten zu entfernen, jedoch sollten zumindest die Begriffe DDL und DML erhalten bleiben, da diese wirklich weitgehend benutzt werden. --Herr Schroeder 09:56, 30. Mai 2006 (CEST)

Nach einem halben Jahr hab' ich mich dann doch "erbarmt" und den Absatz umgestellt ;) . Den Oracle-Hinweis möchte ich noch ergänzen: Oracle spricht bei Grant und Revoke auch von DDL, was gemäß Sprachverständnis der Fachliteratur definitiv falsch ist (richtig wäre DCL), aber Hersteller sind halt manchmal etwas sorglos ... --EFR 14:50, 3. Jun 2006 (CEST)

ich fand die Unterscheidung zwischen DQL und DML besser. Die Zusammenfassung mag zwar gebräuchlich sein ist aber meiner Meinung nach nicht korrekt:

• 1. Sie sehr wohl ein gängiger IT-Begriff, war bei mir Teil des Lehrstoffs in der FH Konstanz und davor in der Ausbildung (Max-Weber-Konstanz)
• 2. DQL ist einer der umfangreichsten und bedeutenten Teile von SQL.
• 3. Die DQL einfach zu verschweigen wäre Unvollstädig in irgendeiner Form gehört sie erwähnt.
• 4. Die Namensgebung DML deutet auf Manipulation hin, passt deshalb sprachlich schon nicht mit abfragen zusammen und ist deshalb zu vermeiden.
• 5. Zitat von der englischen wikipedia Seite: [

The most common operation in SQL databases is the query, which is performed with the declarative SELECT keyword. SELECT retrieves data from a specified table, or multiple related tables, in a database. While often grouped with Data Manipulation Language (DML) statements, the standard SELECT query is considered separate from SQL DML, as it has no persistent effects on the data stored in a database. Note that there are some platform-specific variations of SELECT that can persist their effects in a database, such as the SELECT INTO syntax that exists in some databases.[15] ]

• 6. Die DQL war schonmal bestand Teil einer Wikipedia diskussion wurde schon mal hinzugefügt, entfernt und letzlich wieder hinzugefügt

Aussprache

Ich habe die Aussprache am Anfang des Dokuments geändert ("ess kju ell"). Siehe en.wikipedia.org. Ich höre auch sehr selten jemanden die alte "siekwel"-Aussprache reden.

Die Seite ist super geworden. --Wiki007 18:35, 21. Mär 2006 (CET)

Auf deutsch höre ich nur Es-Kuh-El und gelegentlich Sequel. es kju el als einzige Ausspracheangabe ist irreführend. --08-15 10:33, 26. Aug 2006 (CEST)

Wäre

(offizielle Aussprache [ɛskjuːˈɛl], oft aber auch [ˈsiːkwəl])

nicht teffender statt

(offizielle Aussprache [ɛskjuːˈɛl] oder [ˈsiːkwəl])

-- MarkusWinand 10:50, 3. Sep. 2011 (CEST)

"oder" hat den Vorteil, dass man für "oft" eigentlich Quellen haben sollte, die diese Häufigkeit belegen. Ich denke "oder" und "gelegentlich" sind da eher unstrittig. --87.174.30.197 13:15, 24. Sep. 2011 (CEST)

"ACL"-Entfernung bei GRANT

Ahoi, im Abschnitt Data Control Language wurde die Behauptung, dass GRANT und REVOKE Access Control Lists manipulieren mangels fachlicher Referenz (Literaturnachweis) entfernt.

... hat jemand eine?

Grüße, Fragment 22:03, 30. Mai 2006 (CEST)

Seite für Laien nicht geeignet

ich wollte nur mal kurz nachlesen, was SQL ist und was man damit machen kann. Ich hab rudimentäre Programmierkenntnisse, aber von dem, was auf dieser Seite steht verstehe ich fast gar nichts. Ich habe das Gefühl, dass nur Leute die Seite verstehen, die auch schon vorher wussten, was SQL ist. Das ist aber nicht der Sinn der Wikipedia.

Gruß - Patrick 29.08.06

Vorangestellt, ich weiß was SQL ist und kann es ausreichend anwenden. Vielleicht bin ich deshalb schon der Falsche um die Verständlichkeit zu beurteilen. Aber ich finde die Erklärung verständlich. Natürlich ist nicht der ganze Artikel für Leser ohne Vorwissen (in Programmierung im Allgemeinen und Datenbankaufbau im Besonderen) gedacht. Meines Erachtens geht er für einen Artikel in einem Nachschlagewerk sogar zu sehr ins Detail. Aber wenn jemand nicht weiß was SQL ist und für was es da ist, langt es dann nicht, die Einleitung (bis zum Inhaltsverzeichnis) zu lesen?

Aber gut, Artikel werden (bzw. sollten) von Leuten geschrieben werden, die sich im Thema auskennen, ansonsten steht nachher Blödsinn drin. Allerdings ist es fast schon normal, daß sich solche Leute schwer in die Lage von Laien zu versetzen und daher die grundlegenden Fragen nicht versehen.

Um aus dieser Zwickmühle herauszukommen ist eine Diskussion zum Thema wertvoll. Was also ist Deiner Meinung nach unverständlich und worauf wird gar nicht eingegangen? Und nein, Begriffe wie deklarative Datenbanksprache und relationale Datenbanken zählen nicht zur unverständlichen Sprache, zur Klärung dieser Begriffe gibt es ja eigene Artikel. --jailbird 22:13, 29. Aug 2006 (CEST)

Ich kenne das Thema und finde den Artikel auch verständlich, allerdings verwirrt mich die Optik und die Länge. Vorschlag: In Teilartikel aufsplitten und unter diesem Lemma eine allgemeinverständlichere Einführung geben. Damit will ich nicht sagen, dass der Text, so wie er ist, schlecht ist. Er ist aber sehr lang und behandelt sehr viele unterschiedliche Teilaspekte, z.B. dass einzelne Befehle (INSERT, SELECT, ...) mit Beispielen ausführlich vorgestellt werden: Meiner Meinung nach eignen sich diese längeren Absätze auch für eigene Artikel, die eventuell nicht mehr SQL-zentrisch wären, aber den SQL-Beispielcode weiterhin verwenden könnten. -- daf_? 12:57, 4. Sep 2006 (CEST)

Dateninkonsistenz durch mehrere Transaktionen auf selben Wert möglich?!

Beispiel:
Transaktion A liest Wert x
Transaktion B verringert Wert x um 10
Transaktion A erhöht den gespeicherten Wert von x um eins und schreibt zurück
Ergebnis x' = x+1
Die Änderung von B ist verloren gegangen

Das ist meiner Erfahrung nach eigentlich gar nicht möglich. Habe das mit SQLite ausprobiert. Ergebnis: Transaktion B kann erst gar nicht durchgeführt werden, da die Datenbank bereits für write-Zugriff gesperrt wurde, als Transaktion A den Wert abfragte.

Ich bitte um eure Meinung/Erfahrung und eventuelle Korrektur des Artikels. Danke, MfG --Metzi3 18:02, 17. Jan. 2007 (CET)

Die Inkonsistenz ist sehr wohl möglich, z.B. wenn A mit einem SELECT ohne FOR UPDATE liest und den Wert applikatorisch behandelt, also den UPDATE in einer Folgeanweisung innerhalb der Transaktion durchführt. SELECT-Anweisungen ohne FOR UPDATE sperren gemäß SQL-Standard die Zeile(n) nicht für andere Transaktionen.

Anders sieht das natürlich aus, wenn A direkt einen UPDATE durchführt.

Gruß --EFR 22:28, 17. Jan. 2007 (CET)

Achso sorry, das wusste ich nicht. Ich hatte von SQLite auf SQL geschlossen. Danke, --Metzi3 00:41, 18. Jan. 2007 (CET)

Dieses Problem ist in Verlorene Updates genau beschrieben -- 82.135.37.138 11:45, 28. Feb. 2007 (CET)

Präzision von numeric

Könnte jemand, der es weiß, vielleicht noch ergänzen, um was für eine Art von "Stellen" es sich bei den numerischen Datentypen handelt? Sind das Ziffern im Dezimal-, Binär- oder sonst einem System? --82.135.90.39 15:53, 6. Mai 2007 (CEST)

NUMERIC- oder NUMBER-Angaben kann man nur auf Zehnerpotenzebene angeben, daher Antwort: Im Dezimalsystem. Wenn es sich um maschinennähere Typen wie INT4 handelt, dann sind die Grenzen natürlich in binärer Form angegeben. --Leuchuk 09:25, 23. Feb. 2012 (CET)

Herstellerspezifische Funktionen unklar

Ich finde den Satz

"Die meisten SQL-Implementierungen bieten darüber hinaus allerdings noch herstellerspezifische Erweiterungen, die nicht dem Standard-Sprachumfang entsprechen, was zur Folge hat, dass von den Herstellern parallel entwickelte gleiche Funktionen unterschiedliche Sprachelemente benutzen."

sehr unklar. Was sind "von den Herstellern parallel entwickelte gleiche Funktionen"? Wahrscheinlich die gleiche Datenbankfunktionalität von verschiedenen Herstellern parallel entwickelt, oder gleiche SQL-Funktionen? Und diese Funktionen benutzen Sprachelemente? Wie das? Oder werden Datenbankfunktionen von unterschiedlichen Sprachelementen implementiert? Unterschiedliche SQL-Sprachelemente? Oder was für eine Sprache? Wäre schön, wenn da mal jemand, der sich mit diesen Unterschieden auskennt, ein bisschen Klarheit reinbringen könnte. --Supaari mail 21:21, 14. Jun. 2007 (CEST)

MS Access ist ein Datenbanksystem

Hinweis zum Revert:

Microsoft Access wird als DBMS bezeichnet. Es greift nicht auf eine externe Datenbank zu, sondern arbeitet mit einem eigenen Format (*.mdb), damit ist bzw. hat es sein eigenes Datenbanksystem, wovon in diesem Absatz die Rede ist. Access kann als DBS mit umfangreichem GUI bezeichnet werden. --Fackt0r 00:33, 24. Jun. 2007 (CEST)

Links

Also der Link zu www.sql-referenz.de ist doch echt erbärmlich. Den sollte man lieber rausnehmen, denn das ist keine Refernz sondern nur für alle möglichen Befehle ein Beispiel genannt und fertig. Keinerlei Erklärung was der Befehl selbst nun eigentlich bewirkt.

SQL Join Visualisierung

Hallo obwohl ich die Ausführungen zu den SQL Joins schon recht übersichltich fidne habe ich letztens das hier gesehen: http://www.codinghorror.com/blog/archives/000976.html Wären die Grafiken ( in SVG) zu den Tabellen eine gute Ergänzung?!

SQL,DDL,DML,DCL

Soweit ich weiß sind DDL,DML, und DCL eigene Sprachen die auf gleicher Ebene zu SQL stehen. Meiner Meinung nach ist die Behauptung falsch, daß DDL,DML und DCL Teile von SQL wären, da ja SQL lediglich die Sprache für die Abfrage der Daten darstellt. Sie müssten somit eigene Sprachen sein und nicht Teile von SQL.

Weblinks

SQL-Referenz (deutsch) entfernt, da IE erforderlich (liefert mit Opera Fehler) und außerdem Informationsgehalt relativ dünn. Gibt es da als (einigermaßen komplette, dennoch übersichtliche) Referenz des Standards nichts besseres? -- WolfgangRieger 10:18, 14. Feb. 2008 (CET)

"Rechte"

Ich bin mir uneins, ob man nicht besser das Wort "Recht" in "Berechtigung" oder "Privileg" ändern sollte. Für mich sind Rechte solche Dinge, die mir ein Gesetz o. ä. einräumt. Währenddessen sind Berechtigungen/Privilegien Dinge, die einem Nutzer im Rahmen eines Nutzersytems zugeordnet werden, also wie bei einem DBMS. Um es anders auszudrücken, man kann nicht das Recht haben, ein Insert durchzuführen, sondern höchstens die Berechtigung.--Sixot 20:58, 25. Feb. 2008 (CET)

--217.110.173.74 10:23, 27. Mär. 2009 (CET)== Beispiel "Student - hört - Vorlesung - liest - Professor": Inkonsistent? ==

Mir ist aufgefallen, dass die Relation "liest" aus dem ER-Diagramm in der darunterliegenden Tabelle nicht explizit aufgeführt ist. Sie ist in der Entity "Vorlesung" mitenthalten. Ist das eine Inkonsistenz oder verstehe ich es einfach nicht? (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von AndiFant (Diskussion • Beiträge) 11:20, 2. Okt. 2008 (CET))

Das liegt daran, weil keine "liest" Tabelle benötigt wird. Das grundsätzliche Konzept von Relationen zwischen Datenbanktabellen sieht drei unterschiedliche Typen vor:

• 1 zu 1: Das heißt einem Datensatz der Tabelle A kann ein Datensatz der Tabelle B zugeordnet werden. Ein Datensatz der Tabelle B kann dementsprechend auch nur einem Datensatz der Tabelle A zugeordnet werden (d. h. 1x A und 1x B)
• 1 zu n: Das heißt einem Datensatz der Tabelle A können mehrere Datensätze der Tabelle B zugeordnet werden. Ein Datensatz der Tabelle B kann aber nur ein Datensatz der Tabelle A zugeordnet werden (d. h. 1x A und nx B).
• n zu m: Das heißt einem Datensatz der Tabelle A können mehrere Datensätzen der Tabelle B zugeordnet werden, gleichzeitig können einem Datensatz der Tabelle B mehrere Datensätze der Tabelle A zugeordnet werden (d.h. nx A und mx B).

n wie auch m steht für eine beliebige natürliche Zahl (größer 0). Zwischen Student und Vorlesung existiert eine n zu m Verbindung, da sich diese Art der Verbindung nicht aus dem Stegreif realisieren lässt, ist eine zusätzliche Tabelle notwendig, in welcher die beiden Primärschlüssel der Datensätze die verbunden werden sollen enthalten sind. Zwischen Vorlesung und Professor besteht eine 1 zu n Beziehung, dementsprechend reicht es aus, wenn in Vorlesung der Primärschlüssel des Professors enthalten ist. Was der Primärschlüssel der Tabellen ist, erkennst du im Artikel an der Unterstreichung der Spalte. Ich hoffe ich konnte helfen ;) --Vanger ^!–!? 14:30, 2. Okt. 2008 (CEST)

In der Tabelle hört ist kein Primärschlüssel gekennzeichnet. Das wäre hier doch ein zusammnengesetzter PS aus beiden Attributen, oder?! --217.110.173.74 10:23, 27. Mär. 2009 (CET)

Da ein Student mehrere Vorlesungen hören kann und eine Vorlesung von vielen Studenten besucht werden kann und es keine weiteren Schlüsselkandidaten gibt: ja. Alauda 21:19, 27. Mär. 2009 (CET)

P.S.: Da es sich hierbei um eine reine Zuordnungstabelle handelt, bei der eine N:M-Relation über zwei 1:N-Relationen realisiert wird, vermute ich mal, dass man hier den Primärschlüssel nicht unterstreicht. Alauda 21:43, 27. Mär. 2009 (CET)

Was ist denn SQL für eine Sprache?

Ganz am Anfang des Artikels lese suche ich verzweifelt nach einer Klassifikation von SQL. Ist denn SQL nun

Imperativ, Objektorientiert, Prozedural, Strukturiert (sowieso), Logisch, Funktional, Aspektorientiert, ...?

Gruß(nicht signierter Beitrag von 88.69.165.96 (Diskussion | Beiträge) 21:40, 27. Jan. 2009 (CET))

„SQL [...] ist eine Datenbanksprache [...]“; SQL ist keine Programmiersprache also erfolgt auch keine Einteilung in Klassifizierungen von Programmiersprachen. --Vanger ^!–!? 22:54, 27. Jan. 2009 (CET)

SQL enhält eine Deklarative Programmierung Programmiersprache zur Abfrage. Gruss -- sparti 09:16, 28. Jan. 2009 (CET)

Gruppierungsfunktionen im SELECT unvollständig

Ich vermisse im Abschnitt "Abfrage: SELECT" beim Group-by-Attribut die Funktion Zählen (COUNT). Vorschlag: Den Abschnitt so erweitern: [...] Addition ("SUM"), Durchschnitt ("AVG"), Minimum ("MIN"), Maximum ("MAX"), Zählen ("COUNT") o.ä. [...] --NETsroht 12:13, 4. Feb. 2009 (CET)

Ein Count-Beispiel ist doch vorhanden. Ansonsten ist Wikipedia keine SQL-Anleitung.Alauda 21:26, 27. Mär. 2009 (CET)

SFW-Blöcke

Das Kuezel ist mir nicht bekannt. Kannt jemand eine Uebersetung? Traute Meyer 20:28, 27. Mär. 2009 (CET)

Select-From-Where-Block Alauda 21:23, 27. Mär. 2009 (CET)

Statisches und dynamisches SQL

Was bedeutet in diesem Abschnitt "Statisches SQL" genau?

Sind damit VIEW's oder gespeicherte Prozeduren gemeint? Eine an dem SQL Server gesendete SQL-Abfrage, fest formuliert oder dynamisch "on the fly" erstellt , muss doch immer vom Server zuerst interpretiert werden, um dann ausgefuehrt werden zu koennen; nach meinem Verstaendnis.

Der 2. Begriff, den ich im Abschnitt nicht einordnen kannn ist der "Zugriffspfad".

Traute Meyer 19:39, 28. Mär. 2009 (CET)

Hallo Traute Meyer, nach meiner Kenntnis wird "statisch" überwiegend für ein SQL ohne Parameter gebraucht und "dynamisch" für SQL mit Parameter(n). Statisches SQL liefert - unveränderte Daten vorausgesetzt - immer dasselbe Ergebnis. Eine dynamische Anfrage wäre z.B. "Finde Kunden, die mehr als X (Währung) Umsatz im Zeitraum von Y (Datum) bis Z (Datum)" gemacht haben, während "Finde Kunden, die mehr als 500 Umsatz im Zeitraum von 1.1.2009 bis 31.12.2009" eine mögliche statische Formulierung wäre.

Der Nachteil von statischem SQL ist, daß man entweder die Abfragen immer wieder von Hand korrigieren muß oder schnell viele hundert Abfragen "im Bestand" hat. Die Implementierung, Programmierung und Dokumentation von dynamischem SQL ist aber wesentlich schwieriger. Daher benutzt man für das sog. "fast prototyping" meist statische Abfragen, in Bereichen, die nicht dokumentiert werden müssen (z.B. MIS - Management Informations-Systeme) hingegen eher dynamische. In Bereichen mit Dokumentation (Buchhaltung/Controlling) werden manchmal "Templates" (ein Mittelding zwischen statisch und dynamisch weil die zwar dynamisch formuliert aber nicht selbst auf dem Server ausgeführt werden) verwendet, aus denen dann die statischen Anfragen generiert werden, weil man die Abfrage zusammen mit dem Ergebnis dokumentieren muß und eine dynamische Abfrage läßt sich schlechter dokumentieren.

Ich hoffe, das hilft ein wenig weiter. Ich werde vielleicht mal versuchen, das in einen lesbaren Artikel-Text umzuwandeln, wenn das nicht nur dich interessiert. --PhChAK 14:52, 3. Nov. 2009 (CET)

Für deine zweite Frage mußte ich erstmal prüfen, was im Artikel dazu behauptet wird. Das ist auch mir so nicht verständlich, was da steht und dürfte zu den Teilen des Artikels gehören, die eine ganz bestimmte Implementation von SQL betreffen aber nicht (Standard-)SQL an sich. Ob eine Optimierung überhaupt erforderlich ist, hängt von der Größe der Datenbanken ab. Da heute auch "Minidatenbanken" mit weniger als 1000 Zeilen bzw. Datensätzen und weniger als 10 Spalten bzw. Feldern je Tabelle und insgesamt weniger als 10 Tabellen mit SQL bearbeitet werden, gibt es "SQL-Light" Varianten, die keinerlei Optimierungen machen sondern einfach SQL in eine "proprietäre Sprache" übersetzen und dann sequentiell in der Reihenfolge der Abfrage abarbeiten.

Bei sehr großen Datenbanken kann es aber sinnvoll sein die Reihenfolge der Abarbeitung zu optimieren - insbesondere wenn dadurch Teile auf Mehrprozessorsystemen parallel erledigt werden können und dann nur noch die Ergebnisse der Teiloperationen zusammengeführt werden müssen.

Meiner Meinung nach gehört soetwas aber in einen eigenen Abschnitt (oder sogar Artikel) über die Implementierungsprobleme von SQL und nicht an die Stelle, wo es jetzt steht. Es darf auch nicht als Selbstverständlichkeit für alle Implementierungen dargestellt werden, weil es nicht zur SQL-Sprachebene sondern zur Implementierungsebene gehört und die ist nicht standardisierbar, weil sie ja die Schnittstelle zur "proprietären Sprache" des jeweiligen Datenbanksystems ist und die sind nun einmal fast alle verschieden.

Wie bereits weiter oben geschrieben, habe ich vor, diesen Artikel in den nächsten Wochen und Monaten grundlegend zu überarbeiten - falls kein anderer schneller ist ... --PhChAK 15:12, 3. Nov. 2009 (CET)

Andere Joins?

Sollte man vielleicht noch die anderen Joins hinzufuegen, wie z.B. Right [Outer] Join, Thetajoin und Antijoin? Dasselbe gilt fuer truncate, was ja mehr oder weniger dasselbe wie DELETE FROM <table> darstellte (abgesehen von auto_increment zuruecksetzen etc.) Bevor ich da jetzt dran rumbastel, frage ich hier erstmal (nicht signierter Beitrag von Kai1337 (Diskussion | Beiträge) 19:55, 25. Aug. 2009 (CEST))

Allgemeinverständlichkeit!!

Es wurde bereits in manchen Einzeldiskussionssträngen angesprochen, ich versuche es einfach noch einmal.

Meines Erachtens gehört 90% des Textes in die Tonne. Er wurde offenbar von Informatikern für Informatiker geschrieben und verfehlt völlig seinen Zweck. Ich habe selbst eine umfangreiche und am Markt erfolgreiche SQL-Datenbankanwendung geschrieben und verstehe im Artikel größtenteils nur Bahnhof.

Natürlich mag es korrekt sein, von Relationen, Attributen und Tupeln zu reden, aber wenn man dasselbe auch mit Tabellen, Zeilen und Spalten erklären kann, sollte dem doch der Vorzug gegeben werden. (nicht signierter Beitrag von JoachimG (Diskussion | Beiträge) 14:33, 27. Dez. 2009 (CET))

Ich habe eben eine Änderung bei der Schlüsseldefinition rückgängig gemacht. War bestimmt super-genial der Text, aber es soll hier verständlich sein und kein Informatikerjargon! Im übrigen hat der anonyme Verfasser nicht einmal den Kontext begriffen. (nicht signierter Beitrag von JoachimG (Diskussion | Beiträge) 20:44, 28. Dez. 2009 (CET))

Fehlende Allgemeinverständlichkeit ist keine Begründung dafür korrekte Informationen aus dem Artikel zu streichen sondern ein reines Qualitätsproblem. Abgesehen davon, ich sehe zwar durchaus Probleme des Artikels hinsichtlich der Verständlichkeit, das heißt aber nicht dass der Artikel für Laien verständlich sein muss. SQL ist eine Datenbankbeschreibungssprache, der Artikel befasst sich überhaupt nicht mit den Grundlagen einer Datenbank - und soll es auch nicht, dafür sind andere Artikel da die der Leser ggf. vorher lesen muss. Diese Grundlagen, das schließt auch Fachbegriffe mit ein, müssen nun mal vorausgesetzt werden um sich überhaupt sinnvoll mit der Thematik auseinandersetzen zu können. Das ist das Selbe wie wenn man versuchen würde die Quantenmechanik zu erklären wenn der Leser des Artikels sich noch nie mit Physik beschäftigt hat - der Artikel würde ausarten und sich mit Dingen beschäftigen um die es eigentlich nicht geht. --Vanger ^!–!? 22:25, 28. Dez. 2009 (CET)

Ich verstehe Ihre Logik nicht. Als wäre ein Qualitätsproblem kein Grund für die Streichung korrekter Informationen! Es geht hier darum, dass hier völlig überflüssigerweise mit Fachbegriffen um sich geworfen wird. Der Zweck solcher Ausführungen ist kein enzyklopädischer, sondern einfach nur Selbstdarstellung. Die jetzt eingefügten Texte beim Schlüssel sind ein gutes Beispiel dafür. Tut bloß nicht so, als wäre Datenbanktechnik eine Geheimwissenschaft, die man mit einem Mantel von Fachchinesisch umgeben muss. Sprache und Datenbanktechnik haben eines gemeinsam: die größte Herausforderung besteht darin, für eine komplexe Aufgabenstellung eine einfach strukturierte Lösung zu finden. Kompliziert kann jeder.-- JoachimG 22:49, 28. Dez. 2009 (CET)

Wie ich bereits sagte: Es ist nicht das Ziel einer Enzyklopädie dass jeder Artikel für sich alleine stehend für jeden Menschen verständlich ist. Die Artikellandschaft muss als Gesamtes verständlich sein, das heißt jedem Leser muss die Möglichkeit gegeben werden sich über für den Artikel vorausgesetzte Umstände die er noch nicht versteht zu informieren und sich das notwendige Wissen zum Weiterlesen in anderen Artikeln anzueignen. Datenbanksysteme sind ein derart komplexes und großes Thema dass es nicht in einem Artikel behandelt werden kann, schon gar nicht im Artikel einer Datenbanksprache unter Vielen - dafür sind andere, allgemeine Artikel zu Thema Datenbanken da. Dass ein spezifischer und nicht allgemeiner Artikel mit Begriffen arbeitet die für das jeweilige Themengebiet üblich sind - Primärschlüssel/Primary Key und Fremdschlüssel/Foreign Key ist in der Datenbankentwicklung Alltagssprache, ja eher sogar absolute Grundbegriffe - ist normal und gehört dazu um sich mit einem Thema überhaupt sinnvoll auseinandersetzen zu können. Nachvollziehen wie "Fachchinesisch" in einem System in dem der jeweilige Autor eines Textes nur mit sehr viel Aufwand erkennbar ist der "Selbstdarstellung" dienen soll kann ich aber leider nicht. --Vanger ^!–!? 23:22, 28. Dez. 2009 (CET)

Der Text war auch falsch, da jeder Schlüssel, der Datensätze einer anderen Tabelle identifiziert, ein Fremdschlüssel ist. Mit dem Primärschlüssel hat das nichts zu tun, der Primärschlüssel kann sogar selbst gleichzeitig ein Fremdschlüssel sein. Das ist im Folgenden auch erklärt, daher ist der eingefügte Text ausserdem redundant. Alauda 23:51, 28. Dez. 2009 (CET)

Erstmal sorry wenn ich gestern etwas drastisch war! Ich denke, es wäre schon ein großer Schritt, wenn man folgende sprachliche Vereinfachungen verwendet:

Tabelle statt Relation,

Datensatz oder Zeile statt Tupel,

Feld, Spalte oder "Angabe" anstelle von Attribut

Primärschlüssel statt Primary Key

Bearbeitung statt Manipulation

Den Mehrfachschlüssel würde ich zB wie folgt erklären: "Der Primärschlüssel kann auch aus einer Kombination mehrerer Angaben bestehen. Die Teilnehmer einer Vorlesung können z.B. durch die naturgemäß eindeutige Kombination von Vorlesungs- und Studentennummer identifiziert werden, so dass die doppelte Anmeldung eines Studenten zu einer Vorlesung ausgeschlossen ist."--JoachimG 18:01, 29. Dez. 2009 (CET)

Alauda: Etwas anderes wurde im Text auch nicht behauptet - dass das letzte "Primary Key" wohl Schlüssel hätte heißen müssen war vermutlich ein Tippfehler. Ansonsten sind die Aussagen der Änderung aber korrekt. Unabhängig davon hast du natürlich Recht, die Informationen sind redundant und das hatte ich nicht berücksichtigt.

JoachimG: Das sind doch sehr konkrete Verbesserungsvorschläge, ich kann mir nicht vorstellen dass jemand ernsthaft an diesen Vorschlägen etwas auszusetzen gehabt hätte wenn du sie einfach umgesetzt hättest - und falls doch hätte man über diese einzelnen Punkte diskutieren können. Wie schon immer: Feel free to improve the article ;-) --Vanger ^!–!? 21:43, 29. Dez. 2009 (CET)

Die Allgemeinverständlichkeit zu verbessern, finde ich grundsätzlich löblich. Aber wo ist die Grenze dessen, was man allgemeinverständlicher haben möchte? Konsequenterweise müsste man dann auch bspw. das Lemma Schlüssel umschreiben. Denn es kann eigentlich nicht zum Inhalt des Lemmas SQL gehören, ein Kapitel „Schlüssel ohne Fachchinesisch“ bereitzustellen. Zur momentanen Version: Das Kapitel „Fremdschlüssel“ enthält das Wort Fremdschlüssel nicht mehr, aber den vorher im Lemma noch nie benutzten Begriff „Primärindex“. Bitte geeignet ändern. Danke und Gruss --Toni am See 19:20, 2. Jan. 2010 (CET)

ok, verstanden, akzeptiert und hoffentlich berücksichtigt. Offen gestanden kenne ich den Unterschied zwischen "Schlüssel" und "Primärindex" gar nicht, vielleicht kann einer der Profis hier weiterhelfen?--JoachimG 23:54, 2. Jan. 2010 (CET)

Darf ich mal einen Vergleich ziehen, ich meine es nicht böse, sondern gut: Ich bin kein Koch, aber ich fühle mich in der Lage, auch mal was zu kochen. Da kann ich sicher auch ein Kochrezept schreiben. Was die anderen immer von „abschmecken“ und „ziehen lassen“ schreiben, ist für mich Fachchinesisch, ich schreibe allgemeinverständlich, denn ich schreibe für Nichtköche. Die Köche gucken sich das an, denken sich, lass ihn nur machen, mal sehen wie es wird. Wie wirkt es dann auf die Köche, wenn ich sie frage: „kann mir noch mal jemand den Unterschied zwischen Esslöffel und Teelöffel erklären?“

Du hast Dir viel vorgenommen, vielleicht mehr als Dir selber bewusst ist. „Kompliziert kann jeder (Experte)“, hast Du richtig gesagt. Aber „Kompliziert“ auf einfache Weise darstellen, braucht entweder einen besonders begabten Experten, oder einen längeren Prozess in einem heterogenen Team mit einer extrem guten Kommunikation zwischen den Mitgliedern. Das heisst auch Kompromisse von allen Seiten, z.B. eingestehen von fachlichen Hochnäsigkeiten oder dazulernen von Fakten und Begriffen.

Zur Sache: Ich würde den Begriff „Primärindex“ an dieser Stelle nicht benutzen. Denn ein Datenbankindex ist nun mal nicht das gleiche wie ein Datenbankschlüssel. Die gebräuchlichen Begriffe Primärschlüssel (Primary Key) und Fremdschlüssel (Foreign Key) werden im Lemma Schlüssel (Datenbank) erklärt. Das wird Dir wegen Fachjargon nicht gefallen. Aber jenes Lemma komplett umzuschreiben, da bin ich doch sehr skeptisch. Hoffe Dich nicht entmutigt, sondern ermutigt zu haben, Gruss --Toni am See 06:54, 3. Jan. 2010 (CET)

Geht in Ordnung, wenn ich auch darauf hinweisen möchte, dass mir vermutlich nur der terminologische Unterschied unbekannt ist und nicht der technische. Mein Essen schmeckt nämlich ganz gut. Darf ich dann einfach mal das "Feel free to improve the article" zurückgeben, bloß eben mit der Bitte, das Brauchbare an meinem Ansatz nicht gleich über Bord zu werfen?--JoachimG 09:43, 3. Jan. 2010 (CET)

Dass der Ansatz brauchbar sein könnte, ist unbestritten. Nur ist es eben nicht so einfach, wie es zuerst scheint. Ich kann mal was versuchen, kann aber nur Teilaspekte abdecken. Es wird Ergänzungen, Dialog und Feedback brauchen. Gruss --Toni am See 17:16, 3. Jan. 2010 (CET)

Bitte nimm das jetzt nicht irgendwie übel, aber: ich geb's auf.--JoachimG 22:06, 5. Jan. 2010 (CET)

Die Standpunkte der vorangegangenen Diskussion -Allgemeinverständlichkeit versus fachliche Komplexität- halte ich beide für wohlbegründet.Aus Nutzersicht habe ich in der Regel e i n e dieser beiden möglichen Erwartungen. Könnte der Zielkonflikt lösbar sein, wenn komplexe Themen in z w e i V e r s i o n e n (allgemeinverständlich u n d wissenschaftlich) dargestellt werden? Gruss --Thluck 12:08, 15. Jan. 2010 (CET)

Hört sich gut an. Vielleicht könnte man eine Überschrift voranstellen, die eine leicht-fassliche Einleitung enthält?--JoachimG 13:48, 15. Jan. 2010 (CET)

(2 Jahre später)

Der Text ist ja schon wieder voll von Tupeln und Relationen! Das versteht kein Mensch (oder höchstens Informatiker!), ist jedenfalls nicht allgemeinverständlich. Hatten wir doch alles schon an dieser Stelle diskutiert. Irgendwelche Einwände, dass ich das wieder ändere?--85.183.86.135 14:44, 17. Jan. 2012 (CET)

Ja. Wie es klingt, willst du größere Umbauarbeiten/Reverts vornehmen. Es wäre gut, wenn du hier vorher konkret sagen könntest, was dich stört, bzw. was du gern ändern möchtest. Gerade als Nichtregistrierter Benutzer riskierst du sonst, dass deine Änderungen von einem Dritten ohne viel Federlesen als Vandalismus eingestuft wird und revertiert wird. Das willst du doch nicht, oder? --RokerHRO 16:28, 17. Jan. 2012 (CET)

Algemeinverständlichkeit um jeden Preis ??!

Nichts gegen verständlichere Formulierungen. Der Artikel soll aber nicht zu "SQL für Dummies" werden. Beispiele, was man mit SQL wie abfragen kann, stehen weiter unten im Artikel reichlich und sind dort ausführlich kommentiert. In der Einleitung sollte daher kein weiteres Beispiel stehen.

Die Abkürzung "SQL" als "Structured Query Language" ist unter Fachleuten völlig unbestritten und hat vor allem markenrechtliche Gründe. Der Name des Vorgängers "SEQUEL" (dessen "Bedeutung" unklar ist) durfte nicht weiter benutzt werden. "SQL" wird aber in Fachkreisen heute nicht (mehr) "SEQUEL" oder "SKUILL" ausgesprochen sondern "ES KU EL" womit es als Abkürzung deutlich zu erkennen ist.

Ob das Fachchinesisch mit "Datenmanipulation" u.a. da stehen muß, ist aber unklar weil SQL in erster Linie als Universelle "Metasprache" für die Benutzung von Datenbanken Verwendung findet. So muß man nicht jedes Programm für jede Datenbank anpassen sondern kann einfach jede DB verwendet, die SQL versteht oder sich einen Interpreter besorgen, der die Datenbank SQL-fähig macht. --PhChAK 15:21, 18. Jan. 2010 (CET)

Diese vermeintlich rethorische Frage geht nach hinten los, denn die Antwort lautet zweifelsfrei: ja! Es geht allgemeinverständlich! Und wenn es nicht allgemeinverständlich ginge, dann gehört es nicht in die Wikipedia, siehe http://de.wikipedia.org/wiki/Wikipedia:Laientest. Ich bin davon überzeugt, dass es geht. Man muss es nur wollen. Verschluckt mal für ein Weilchen eure Tupel.--JoachimG 22:01, 18. Jan. 2010 (CET)

Der Artikel soll zwar nicht zu "SQL für Dummies" werden, aber im Moment ist er "SQL für Profis". Die ersten Beispiele kommen nach der Vorstellung der Syntax von SELECT; zu diesem Zeitpunkt haben wir wahrscheinlich schon den größten Teil der Leser verloren. Das Beispiel, das ich gebracht habe, ist auch mit den vorhandenen Beispielen nicht zu vergleichen. Die vorhandenen Beispiele verdeutlichen exemplarisch die Syntax und Semantik von SQL, während mein Beispiel den Unterschied zwischen der Datenorganisation im persistenten Speicher und der Art des Zugriffs über eine benutzerorientierte Abfragesprache aufzeigt. Für jemanden, der von Abfragesprachen keine Ahnung hat ist das die zentrale Information, die er braucht um SQL einzuordnen. --Traxer 12:08, 19. Jan. 2010 (CET)

Das SQL im allgemeinen Sprachgebrauch oft als Abkürzung für Structured Query Language angesehen wird, steht bereits in einem eigenen Abschnitt. Kann in der Einleitung auch stehen, aber IMHO nicht unbeding im ersten Abschnitt. --Traxer 12:08, 19. Jan. 2010 (CET)

Im Kommentar zum Revert schreibst du: "aber teilweise falsch bzw. enthält Formulierungen, die schonmal entfernt wurden". Hier in der Diskussion hast du nicht darauf hingewiesen, das etwas teilweise falsch ist. Was erachtest du als teilweise falsch? Welche Formulierungen wurden schonmal entfernt? --Traxer 12:08, 19. Jan. 2010 (CET)

Es gibt m.W. keinerlei Beleg für den angeführten Zusammenhang zwischen SQL (das nebenbei nicht nur "oft" als Abkürzung verstanden wird, sondern eindeutig eine Abkürzung ist und auch immer schon war) und das immer grundsätzlich von allen Fachleuten "ES-KU-EL" ausgesprochen wird und der Aussprache des Rechts-Vorgängers "SEQUEL" (meist ähnlich "SÄCK-WEL" gesprochen). Wer "Sequel" sagt, obwohl er SQL meint, begeht eindeutig einen Fehler, der in der WP nichts zu suchen hat, weil die WP sonst zur Verbreitung von Fehlern beiträgt.

Abkürzungen werden in der WP generell im ersten Satz des Artikels entschlüsselt, das ist ein wichtiger Grundsatz. Er ist hier umso wichtiger, als der ausgeschriebene Name der Sprache bereits einen ersten Erklärungsansatz liefert - für alle, die Englisch können. Es geht (bzw. ging ursprünglich) bei dieser Sprache (Language) um Strukturierte Anfragen (Structured Queries), wobei mit Queries hier Anfragen in natürlicher (oder der natürlichen sehr ähnlicher) Sprache gemeint sind. Heute ist auch eine DML (INSERT, UPDATE, DELETE) Bestandteil von SQL, aber der Ursprung war "SELECT ... FROM ... WHERE ...".

Das genannte Beispiel ist - soweit ich mich erinnere fast wörtlich schon mehrfach dort im Eingangsbereich gestanden und immer wieder (m.E. zu recht) dort (übrigens bisher nie von mir ...) entfernt worden, weil eine Enzyklopädie grundsätzlich in ihrer Erklärung nicht auf Beispiele zurückgreift. Die Beispiele werden immer erst aufgelistet nachdem der Begriff erläutert wurde - ich denke es ist auch möglich, SQL zu erklären ohne dafür auf ein Beispiel zurückgreifen zu müssen. Außerdem stellt das Beispiel das wirklich entscheidend Wichtige an SQL überhaupt nicht dar. Datenbankabfragemöglichkeiten gibt es in Massen - auch solche, die nahe an der natürlichen Sprache formulieren.

SQL hat sich heute aber als de facto Standard-Schnittstelle für alle Datenbanken etabliert, weil jede DB, die SQL nicht direkt versteht über Interfaces ("Adapter") verfügt (verfügen muß - sonst verkauft sie sich nämlich nicht), sodaß man den "harten Kern" von SQL mit jeder DB verwenden kann. Das geht mit keiner der sog. "proprietären" Sprachen. Auch die Erweiterungen von SQL sind übrigens überwiegend proprietär (d.h. in diesem Falle: datenbankspezifisch), weswegen es heute leider hunderte von als "SQL-Dialekte" bezeichnete mehr oder weniger starke Abwandlungen und Ergänzungen gibt.

Ich will nicht mißverstanden werden: einen guten Ansatz zu einer verständlicheren Formulierung dieses Artikels würde ich begrüßen und ich bin ein Anhänger von "verbessern statt löschen" und würde daher auch einen guten Ansatz nicht revertieren, sondern lieber Fehler ausbügeln - aber dieser Ansatz war etwas zusehr mit Fehlern und "Halbwahrheiten" garniert und in der EDV ist nichts schlimmer, als Halbwahrheiten, weil Laien den Unterschied zur Wahrheit meist nicht erkennen und jeden Mist ohne jedes hinterfragen übernehmen.

Ob ein Artikel speziell zu SQL allgemeinverständlich sein muß ist übrigens keine rhetorische sondern eine ernstgemeinte Frage. Für die "breite Masse" sollten Artikel wie Abfragesprache und Data Manipulation Language verständlich sein. Wer sich speziell über "SQL" informieren will, darf hingegen schon eine gewisse Detailtiefe erwarten und sollte sich nicht durch eine "SQL für Dummies"-Einleitung durchquälen müssen ...

Wichtige Elemente der Einleitung müssten m.E. bleiben bzw. sein:

1. . Die Bedeutung von SQL = Structured Query Language
2. . Die Tatsache, daß es (im standardisierten Kern) zum einen eine Abfragesprache (SELECT) und zum anderen eine DML (INSERT UPDATE DELETE) ist
3. . Die Tatsache, daß es Versionen gibt, die auch Zugriffs-Rechte managen können, daß das aber Dialekte sind und nicht jedes SQL diesen Teil beherrscht
4. . Die Tatsache, daß es Dialekte mit Erweiterungen des Standards gibt, die sich teilweise überhaupt nicht verstehen (zahlreiche Fehlermeldungen und fehlerhafte oder garkeine Ergebnisse)
5. . Die Tatsache, daß SQL - mit seinen Dialekten - heute de facto Standardsprache für (fast) alle DBs geworden ist - wozu nicht zuletzt die (Web-)Datenbank "MySQL" beigetragen hat (der Name muß aber nicht unbedingt erwähnt werden, da grenzwertig zu Werbung)
6. . Wikilinks auf Abfragesprache und Data Manipulation Language möglichst weit oben, damit Leser, die die Infos hier nicht verstehen, die Grundlagen schnell finden können und nicht kapitulieren

Ich hoffe dies war jetzt ausführlich genug ... --PhChAK 21:48, 22. Jan. 2010 (CET)

Mal wieder DML und Abfragen

Da mal wieder einige Leute Abfragen als eigene Kategorie neben DML einführen wollen:

1. Es gibt in der Wissenschaft weder einen Streit noch eine Diskussion darüber, ob Abfragen zur DML gehören. Es gibt lediglich ein paar Einzelmeinungen, die behaupten Abragen gehörten nicht zur DML. Diese Einzelmeinungen erreichen nicht mal die Größe einer Mindermeinung. Ferner gibts eine Legaldefinition: In ANSI/ISO 9075 wird "Select" unter "data manupulation" geführt.
2. Die Diskussion ob Abfragen zu DML gehören oder nicht wurde in Wikipedia schon mehrmals geführt, mit dem Ergebnis, dass Abfragen zur DML gehören. Die Hauptdiskussion war 2006, falls es jemand raussuchen will. Das Lemma zu DQL wurde damals sogar gelöscht.
3. Die aktuelle Quelle gibt ebenfalls nicht her, das Abfragen eine eigene Kategorie bilden. Für die geänderte Behauptung müsste eine neue Quelle beigebracht werden.

Man kann darüber streiten, ob Abfragen innerhalb der DML eine Sonderrolle spielen, man kann vielleicht Transaktionen als eigenständige vierte Kategorie einführen, man kann aber nicht Abfragen neben DML stellen, das wäre falsch. Übrigens bitte schongarnicht DQL wieder einführen! Ich habs daher wieder zurückgedreht. Alauda 19:16, 31. Jan. 2010 (CET)

P.S. Ein bischen merkwürdig ist es auch, dass eine Änderung ohne jegliche Quelle gemacht wird, für den Revert aber eine Quelle gefordert wird, obwohl die sogar schon verlinkt ist. Bischen verkehrte Welt, oder? Übrigens ist die Auffassung, dass Abfragen zur DML gehören hier detailiert belegt. Alauda 19:40, 31. Jan. 2010 (CET)

Was ist hier eigentlich los? Wieso wird mit Zähnen und Klauen die Unverständlichkeit verteidigt? Ob Abfragen nun zur DML gehörden oder nicht oder ob das strittig ist, ist völlig unwichtig. Ein fruchtloser Streit um Worte. Wir hier gerade zutreffend erläutert wurde, handelt es sich im standardisierten Kern um eine Abfragesprache. Und glaubt mir: wenn sich ein Nichtprofi hierher verirrt, wird er weder CREATE TABLE noch INSERT daddeldu suchen, sondern SELECT, damit er MySQL ins Laufen kriegt. Im übrigen stehen Abfragen ja auch im folgenden Text gleich ganz oben. Dem sollte auch der Vorspann dienen.--JoachimG 20:47, 31. Jan. 2010 (CET)

Bei aller Liebe zur Allgemeinverständlichkeit: Die Grenze ist da erreicht, wo's falsch wird. Wie wärs denn mit einem Nachsatz, der die besondere Bedeutung von Abfragen hervorhebt? Alauda 21:05, 31. Jan. 2010 (CET)

Wieso denn falsch? Ich habe in meinem Text doch zu diesem sinnlosen Streit überhaupt keine Stellung bezogen. Die Zuordnung zu den drei Kategorien ist für Zwecke der Allgemeinverständlichkeit vollkommen überflüssig. Die drei Kategorien sollten überhaupt nicht erwähnt werden, weil sie nicht zum Verständnis beitragen.--JoachimG 21:31, 31. Jan. 2010 (CET)

Sorry: Du hast in der Aufzählung Abfragen neben DML, DDL und DCL gestellt und das ist falsch. Fehlt nur noch einer, der das dann in DQL umbenennt, was richtig guselig wäre. Im übrigen bezweifle ich, dass es der Verständlichkeit dient, Abfragen aus DML herauszulösen. Abfragen sind die höchste Form der Datenmanipulation, wer das nicht versteht, hat vermutlich sowieso ein Problem mit dem Artikel. Oder verstehe ich Dich vielleicht falsch und du willst den ganzen Absatz löschen? Da hätte ich auch kein Problem mit. Alauda 21:52, 31. Jan. 2010 (CET)

Der Vorspann ist eigentlich ganz sinnvoll, weil er einen Überblick über den nachfolgenden Text gibt. Lediglich die Zuordnung zu den Kategorien darin halte ich für unnötig. Ihr müsst auch bedenken, dass der typische Leser praktisch nur mit SELECT zu tun hat (wenn überhaupt!!!). Die anderen Dinge braucht man, wenn man eine Administrationssoftware für Datenbanken schreibt - aber das gehört nicht in die Wikipaedia. Der typische Verwender ist froh und glücklich, ein SELECT zu basteln (und selbst dafür werden gern noch Editoren verwendet), während alles andere von Datenbankumgebungen wie MySQl, Access, ADO oder sonstwie erledigt wird.--JoachimG 22:13, 31. Jan. 2010 (CET)

Vorschlag zur Güte: verschiebt doch die Abschnitte DDL, DML und DCL in deren eigene Lemmas. Die gibt es ja schon, bisher recht spartanisch, aber da gehören diese Texte auch hin, und die SQL-Seite würde dadurch von den Dingen, die ein Normalsterblicher nicht braucht, entlastet. In der SQL-Seite genügen dann entsprechende Links. Dies wäre systematischer, und dadurch kommt man auch der Allgemeinverständlichkeit näher. (nicht signierter Beitrag von Sansibla (Diskussion | Beiträge) 10:22, 1. Feb. 2010 (CET))

Gewiss darf ich das Schweigen des Establishments hier als Zustimmung betrachten? Da DDL, DML und DCL jeweils Spezialthemen zu SQL sind, hat Sandibla mit seinem Vorschlag recht. Übrigens: wie verträgt sich das Protestgeheule gegen meinen Text mit der Tatsache, dass Abfragen im nachfolgenden Text unter 3.1 erläutert sind und nicht unter 3.2 Manipulationsbefehle?--JoachimG 21:58, 1. Feb. 2010 (CET)

Danke. Geändert und neu sortiert. Alauda 23:08, 1. Feb. 2010 (CET)

Glückwunsch. Die Seite wird immer schlechter.--JoachimG 23:25, 1. Feb. 2010 (CET)

Ehrlich gesagt weiß ich nicht was du willst. Einmal sehe ich in dieser Miniänderung keine Verschlechterung. Zum andern habe ich mehrere Vorschläge gemacht: Löschen der Aufzählung, Nachsatz über Abfragen einfügen, Umformulieren. Von mir aus kann das Ganze auch verschoben oder auf jede andere Art verändert werden, solange keine Fehler eingebaut werden. Scheinbar alles keine Vorschläge die du aktzeptierst? Alauda 23:54, 1. Feb. 2010 (CET)

heißt das, dass mein gestriger "Vorschlag zur Güte" nicht gleich revertiert würde? Und was Joachim meint: wieso protestierst du gegen seine vier Punkte in der Aufzählung, wenn deine vier Punkte 3.1, 3.2, 3.3 und 3.4 einer identischen Logik folgen? Oder anders gefragt: was unterscheidet denn systematisch deine 3.1 von der 3.2? Lass uns bloss diesen Theoriestreit beenden, er ist ja sowas von sinnlos.... (vermutlich sind wir uns wenigstens darin einig?) (nicht signierter Beitrag von Sansibla (Diskussion | Beiträge) 09:19, 2. Feb. 2010 (CET))

Es ist und bleibt absolut totaler Quark, die DML-Befehle ausgerechnet in diesem Artikel mit den Abfragen zu vermengen. Der einzige zentrale Befehl in SQL (ohne den eine Sprache nicht SQL wäre) ist SELECT. Alle anderen können fehlen und tun das in einigen Dialekten / Implementierungen auch. Es gibt gültige SQL mit genau einem Befehl: "Select". "From", "Where", "Order by" ... sind bekanntlich keine eigenständigen Befehle (sie können niemals allein stehen), sondern ergänzen nur den Select-Befehl.

Ein Abfrage darf an den Daten in der Datenbank niemals irgendetwas ändern sonst bekommt man höchstwahrscheinlich inkonsistente Daten. Abfragen darf immer jeder Nutzer machen (ohne Login in die Datenbank !), weil ja nichts geändert werden kann. Alle "Änderungen" von Select sind rein temporär und werden niemals in die Datenbank (zurück)geschrieben. Insofern ist eine Abfrage eine absolute Einbahnstraße: READ-ONLY.

Jeder DML-Befehl ändert etwas an den Daten in der Datenbank, das ist der Grundsinn von "DATA MANIPULATION", daß die Daten in den Tabellen dauerhaft geändert werden. Deshalb gibt es Datenbanken, die als DML nur die eigene proprietäre Sprache zulassen und SQL nur zum Abfragen gestatten ("CREATE", "UPDATE" und "INSERT" sind bei diesen SQL-Interfaces einfach nicht vorhanden, man muß sich bei der Datenbank anmelden und kann dann die datenbankeigenen Befehle nutzen). Gerade das ist der Sinn einer eigenen Abfragesprache, daß man ohne kompliziertes Rechtemanagement einfach SQL (natürlich ohne die 3 o.g. DML-Befehle !!) für die in tausenden zählenden anonymen Nutzer freigibt und das Datenbank-Login für die wenigen zu Änderungen an den Tabellen Berechtigten (mit persönlichem Login !) reserviert. Deswegen muß man strikt zwischen DML-Berechtigten (nur Update, Insert, Delete gegen persönliches Login) und Abfrage-Berechtigten (nur anonymes Select) unterscheiden können. Daß man Berechtigten idR nicht gestattet mit ihrem Login/Account auch Select zu nutzen hat den einfachen Grund, daß sie sich schnell wieder ausloggen sollen, da viele Systeme bei den SQL-Abfragen ein Data-Sharing zulassen, bei der DML hingegen ein exklusives Login fordern (kein anderer kann gleichzeitig Änderungen an den Tabellen machen).

Der Artikel Abfragesprache dürfte übrigens nicht existieren, wenn Abfragen Bestandteil von DML wären, denn dann müsste zwingend das Lemma "DML" heißen (immer der "übergeordnete Begriff nicht der Teilbereich) und die Abfragen bzw. Abfragesprachen dürften dann nur einen Abschnitt innerhalb von DML belegen. Dies ist aber derzeit nicht der Fall, wie jeder sich gern überzueugen kann, die Abfragesprachen (zu denen SQL in seiner Grundform zählt, es war ursprünglich nur eine Abfragesprache ohne jedes DML usw.) haben einen eigenen Artikel.

Im übrigen ist die strikte Trennung von DML (write) und Abfragesprachen (read-only)keine "Mindermeinung" oder "Laienmeinung", sondern Inhalt von universitären Lehrveranstaltungen im Bereich EDV / Informatik und es wurde sogar extra der Befehl "Merge" in SQL eingeführt damit man bei der DML nie mit "Select" arbeiten muß und so die strikte Trennung zwischen Abfragen einerseits und DML andererseits gewahrt bleiben kann. Wäre diese Trennung unwichtig, könnte man statt "Merge" einfach "Insert To ... Select ... From ..." verwenden und so das Ergebnis der Abfrage zu einer Tabelle dauerhaft hinzufügen. Genau das ist aber so nicht möglich - aus gutem Grund: Alle Zusammenfassungen von Tabellendaten mit Select sind immer nur temporär. --PhChAK 04:29, 3. Feb. 2010 (CET)

Nochmals ganz deutlich: Für SQL gibt es einen Standard, nämlich ISO/IEC 9075. Wenigstens ins Inhaltsverzeichnis solltest Du mal schauen, zur 2008er-Version (ISO/IEC 9075-2:2008-07) gibts das hier. Dort findet sich ein Kapitel 11 namens "Schema definition and manipulation", ein Kapitel 12 namens "Access control" und ein Kapitel 14 namens "Data manipulation", einschließlich "select". Was die Literatur angeht wiederhole ich mich auch nochmal: das Abfragen zur DML gehören wurde hier belegt.

Zu deinem Statement: vielleicht solltest du "manipulation" einfach mal frei nach Leo mit Bedienung oder Handhabung übersetzen, um so endlich die "hier Abfragen, da DML"-Idee zu vergessen. Vielleicht ist es einfacher Abfragen unter Datenhandhabung einzuordnen?

Das es APIs gibt, die nicht den ganzen SQL-Standard implementieren, reduziert doch nicht den Umfang des Standards, den wir hier beschreiben. Natürlich ist die "Select"-Syntax "read only" - und was belegt das? Zur Aussage "Abfragen darf immer jeder Nutzer machen" spar ich mir den Kommentar. Das man die Select-Syntax auch als Abfragesprache sehen kann, wird von mir nicht bestritten, natürlich innerhalb der DML. Und das in Wikipedia auch Unsinn stehen kann ist richtig. Alauda 08:22, 3. Feb. 2010 (CET)

Dann lasst uns doch 3.2, 3.3 und 3.4 in die jeweiligen Spezialseiten DML, DDL und DCL verschieben, wie ich es vorgeschlagen habe. Damit wird SQL auch allgemeinverständlicher. 3.1 (SELECT) bleibt hier. Wer sich wirklich für DML - ich sage jetzt mal: "im engeren Sinne" - interessiert, mag sich dort in die Eingeweide des Maschinenraums vertiefen. (nicht signierter Beitrag von Sansibla (Diskussion | Beiträge) 10:06, 3. Feb. 2010 (CET))

Die große Schiebung

Nachdem sich gegen Sansiblas Vorschlag hinreichend lange kein Protest geregt hatte, habe ich die maschinennäheren Abschnitte in die entsprechenden Spezialseiten verschoben. Das macht die Seite imho deutlich allgemeinverständlicher. @Alauda: bevor du übereilt revertierst, bitte ich zu würdigen, dass ich deinen heißgeliebten Dreier-Block dabei nicht angetastet habe! (nicht signierter Beitrag von JoachimG (Diskussion | Beiträge) 21:24, 5. Feb. 2010 (CET))

Ok, ich höre jetzt erstmal auf. Seid bitte nicht zu harsch mit mir. Immerhin bin ich langsam durchaus geneigt, den Allgemeinverständlichkeits-Kasten wieder zu entfernen!--JoachimG 09:55, 6. Feb. 2010 (CET)

Allgemeinverständlichkeit jetzt erreicht?

Wenn sich hier kein Protest regt und meine Änderungen der letzten Tage auch nicht komplett revertiert werden, wäre ich dafür, den Allgemeinverständlichkeits-Block jetzt wieder zu entfernen.--JoachimG 10:49, 7. Feb. 2010 (CET)

Vielen Dank für Deine Änderungen. Wenn in den nächsten ein, zwei Tagen keine grösseren Einsprüche kommen (mal abgesehen von kleinen Details), könntest Du als Einsteller des Blocks gerne zur Tat schreiten. Danke und Gruss -- Toni am See 16:31, 7. Feb. 2010 (CET)

... sagst du das vielleicht nur, damit ich endlich Ruhe gebe und mit dem Wildern aufhöre;)? (wäre allerdings auch ok. Ich befasse mich derzeit ohnehin mehr mit der Praxis von Kreekfahren).--JoachimG 17:10, 7. Feb. 2010 (CET)

... äh, du hast mich durchschaut :) aber es ist auch tatsächlich was erreicht worden, der Dank war nicht ganz unernst. Gruss -- Toni am See 17:38, 7. Feb. 2010 (CET)

Verschwundene Leerzeichen

Ich entschuldige mich in aller Form wegen der bei mir verschwundenen Leerzeichen, die ihr wieder eingebaut habt. Meine Leertaste war durchaus nicht kaputt, wie man meinen könnte. Tatsächlich hatte ich die fraglichen Abschnitte gar nicht angefasst, sondern kam das dadurch, dass ich Texte in Word vorbereitet hatte und dann in der Wikipedia-Beta-Version mit Copy and Paste eingefügt hatte. Das mag Beta offenbar nicht (vielleicht Bug 22394), teilweise landeten ja sogar Word-Formatvorlagen in der Wikipedia. Trotzdem bleibt es natürlich meine Schuld, weil ich das zwar gleich entdeckt, aber nicht vollständigt beseitigt hatte. Gelobe Besserung.--JoachimG 21:38, 13. Feb. 2010 (CET)

SQL Turingvollständig

Eine weit verbreitete Fehlannahme ist, dass SQL nicht Turing-vollständig ist. Auch in aktuelleren Werken wird beispielsweise noch die Transitive Hülle als ein in SQL nicht beschreibbares Problem aufgeführt (etwa in Datenbanksysteme Von Alfons Kemper,André Eickler), wie jedoch in http://www.slideshare.net/signer/advanced-sql gezeigt wird, lässt sich ein derartiges Programm relativ einfach in SQL:2003 definieren. Der volle SQL Sprachumfang ist mit Rekursion in SQL:1999 und der Aufnahme von SQL/PSM in SQL:2003 gemäß des Structured Program Theorems [Böhm/Jacopini1966] auch ohne proprietären Erweiterungen Turing-vollständig und ermöglicht folglich die Realisierung beliebiger Computerprogramme. (siehe hierzu: Advanced SQL: SQL für Praxis und Studium Von Daniel Warner).

Das könnte ja evtl. jemand aktualisieren.

-- 141.28.131.58 16:09, 13. Sep. 2010 (CEST)hants

Hatten wir das nicht gerade? Der Artikel fängt nicht erst bei SQL3 / SQL:1999 an, sondern behandelt alle SQL-Versionen. Damit ist es keine Fehlannahme und deine Aussage "SQL ist turing vollständig" so auch nicht richtig. Vielleicht formulierst Du das um, so das klar wird, dass die früheren Versionen das nicht waren, und die neueren es sind. Dann kannst du noch das mit der "weit verbreiteten Fehlannahme" streichen, ausser, Du findest eine Quelle, die sagt, wie weit sie verbreitet ist. --P.C. ✉ 16:14, 13. Sep. 2010 (CEST)

Macht was ihr wollt, Leute, aber bitte haltet solche philosophischen Defintionsfragen aus der Seite heraus, denn das ist nicht allgemeinverständlich. Wenn überhaupt, sollte das ein Abschnitt auf Turing-Vollständigkeit werden; hier genügt ein Link darauf.--JoachimG 18:50, 13. Sep. 2010 (CEST)

Ohne mich jetzt allzu tief in die Materie des Themas "Turing-Vollständigkeit" einarbeiten zu wollen, gebe ich zu bedenken, dass viele SQL-Erweiterungen proprietär sind und nicht dem Standard entsprechen. Beispiele dafür wären Transact-SQL (TSQL) von Microsoft, welches eine Menge Erweiterungen der "Sprache" SQL mitbringt.

--TorPedo 22:50, 19. Sep. 2010 (CEST)

Zusatz: Nach kurzem Studium der verlinkten Folien scheint mir, dass sich die Inhalte und Beispiele in ihrer Syntax und Formatierung auf die TSQL-Erweiterung beziehen. Da jedoch Trigger und Rekursionen mittlerweile im Standard angekommen sind, sollte man SQL als Turing-Vollständig bezeichnen können. Das kann ruhig im Artikel erwähnt werden.

--TorPedo 22:58, 19. Sep. 2010 (CEST)

SQL#Linker natürlicher Verbund

Wieso ist hier bei der zweiten Abfrage von einer Umkehrung die Rede? Die Ergebnismenge ist, zumindest was die Zeilen anbelangt, eine Teilmenge der ersten Abfrage. --Tz92 11:37, 6. Jan. 2011 (CET)

Du hast recht, ich habe es etwas angepasst. Viele Grüße, --Adlange ☎ 11:50, 6. Jan. 2011 (CET)

SQL-Datentypen

"In den oben vorgestellten Befehlen create table und alter table wird bei der..."

Bedaure, besagte Befehle wurden bisher weder vorgestellt, noch erklärt. Möglich, dass sich die Angabe auf eine ältere Version des Artikels bezieht?! Sollte jedenfalls geändert werden. Ich habe sicher nichts überlesen und eben auch noch mal alles Davorstehende überflogen, da ist nichts (mehr). Die Befehle werden an dem Punkt zum ersten Mal genannt. -- Zero Thrust 10:55, 12. Jul. 2011 (CEST)

Und was hat das mit "SQL-Datentypen" zu tun? --80.153.250.36 11:47, 15. Jun. 2016 (CEST)

Ist ein LEFT JOIN in SQL ein "left outer join" der relationalen Algebra?

Bei MySQL erhalte ich mit einem "LEFT JOIN" NULL-Werte in der Ergebnismenge für nicht zuordenbare Zeilen. Laut Relationale_Algebra ist das ein "Left outer join". Stimmt das?

Die engl. Wikipedia verwendet dafür ein eigenes Unicode-Zeichen (⟕), das sich von dem anderen Zeichen ⋉ unterschiedet, welches wiederum für eine Operation steht, die dort "left semi-join" genannt wird. Ich bin jetzt total verwirrt. Kann da nicht mal bitte jemand aufräumen im Zeichen- und Bezeichnungswirrwarr? --RokerHRO 14:17, 13. Jul. 2011 (CEST)

Bitte solche Fragen in einem SQL-Forum posten, das hat hier wirklich nichts verloren. -- bg phaidros (Diskussion) 19:14, 3. Jun. 2012 (CEST)

Dialekte

Was mir am Artikel abgeht, ist das der Standard durch die Hersteller interpretierbar ist und verschiedene DBMS daher trotz gleicher Standardkonformität (leicht) unterschiedliche SQL-Kommandos verlangen. Das gilt insbesonders aber nicht nur bei DDL-Anweisungen. Quelle: "SQL-Cookbook", O'Reilley-Verlag. In 3.4 ist eine im Standard vorgesehene "Nur-in-einer-Datenmenge-vorkommen"-Abfrage (SELECT) einmal mit einem Schlüsselwort "EXCEPT" definiert, einmal mit "MINUS" und einmal als "NOT IN" mit Unterabfrage. --Leuchuk 09:39, 23. Feb. 2012 (CET)

Bei der Frage der Standardkonformität sollte man drei Ebenen unterscheiden. a) Manche Hersteller verwenden Schlüsselworte, die im Standard nicht defiert sind, und drücken damit Zusammenhänge aus, die zum Standard gehören. Beispiel: die Datentypen VARCHAR2 oder INT4. b) Die Implementierung mancher Features ist im Standard nicht 100%-ig geregelt. Dadurch erhalten Anbieter Interpretationsspielräume. Beispiel: Das Verhalten eines UNIQUE CONSTRAINT auf einer Spalte mit mehreren NULL Values - darf es mehrere NULL Values geben oder nicht? c) Ähnlich wie in der Mathematik gibt es oftmals mehrere Lösungswege, um ein Ziel zu erreichen. Beispiel: Ein Select mit Subselect kann auch als Join formuliert werden. Diese Freiheit in der Formulierung von SQL Befehlen ist möglicherweise irritierend, aber gewollt - und standardkonform. Zur Laufzeit entscheidet das DBMS sowieso, nach welchem der (vielen) möglichen Ausführungsplänen es vorgehen wird. SQL ist eine deklarative Sprache. Sie legt nicht fest, wie die Befehle abzuarbeiten sind. --Kelti 11:50, 23. Feb. 2012 (CET)

Ich müsste mich schon irren, Kelti, aber m.E. muss es mehrere NULLs geben können. Denn wenn nur eine einziges NULL erlaubt wäre, so würde das heißen, dass NULL ein Wert wäre - aber eben das ist nicht der Fall! NULL existiert zusätzlich zu allen erlaubten Werten der Domäne mit der Bedeutung "unbekannt". -- bg phaidros 13:14, 23. Feb. 2012 (CET)

Das sehe ich genau so. Der Standard (zumindest ab 2006, ältere Versionen liegen mir nicht mehr vor) ebenfalls. Aber: SQL Server 2008 läßt nur eine einzige Zeile mit NULL Value zu (http://msdn.microsoft.com/en-us/library/ms191166.aspx). Bei Oracle gibt es ebenfalls eine spezielle Abweichungen für den Fall, dass sich der Constraint auf mehrere Columns bezieht: http://troels.arvin.dk/db/rdbms/#constraints. --Kelti 17:36, 23. Feb. 2012 (CET)

Schon klar, aber vielleicht stehe ich auf der Leitung: beruft MS oder Oracle sich dabei auf den Standard? Das ist doch nur ein Implementierungsdetail. (Nebenbei: wenn der DB-Server berechnete Spalten kann, kann man mehrere NULLs in der sonst eindeutigen Spalte C mit einer berechneten Hilfsspalte H durchsetzen: mit einem case lässt Du in den not-NULL Zeilen 'C' + dem Wert von C ausgeben, in den NULL Zeilen 'PK' + dem des Primärschlüssels. Auf H legst Du die UNIQUE constraint.) -- bg phaidros 21:08, 24. Feb. 2012 (CET)

Ich zitiere mal: "Die Implementierung mancher Features ist im Standard nicht 100%-ig geregelt. Dadurch erhalten Anbieter Interpretationsspielräume." Heißt: Ein Dialekt, oder liege ich da falsch?

-- Leuchuk (Diskussion) 13:36, 17. Apr. 2012 (CEST)

Aus dem hohlen Bauch heraus würde ich aber sagen, dass das keiner dieser »freien« Features sein kann. Dass aber grundsätzlich so »Dialekte« entstehen, sehe ich auch so. -- bg phaidros (Diskussion) 19:16, 3. Jun. 2012 (CEST)

Reihenfolge der Abschnitte

Ich schlage vor, die Abschnitte »Chronologie« und »Sprachstandard« ans Ende des Artikels zu stellen. Als Abschnitte 1 und 2 sind sie für jemand, der wissen will, was SQL ist, an erster Stelle (sic) völlig uninteressant, nichtssagend und mglw. auch etwas verwirrend. -- bg phaidros (Diskussion) 19:19, 3. Jun. 2012 (CEST)

Kein Widerspruch - habe das jetzt gemacht. Sind nun nicht mehr Abschnitte 1 und 2 sondern 8 und 9 (wo sie sich recht gut hineinfügen, finde ich) -- bg phaidros (Diskussion) 13:42, 26. Jul. 2012 (CEST)

Tabellen-Schema im Beispiel Fehlerhaft

Im Abschnitt Abfrage mit verknüpften Tabellen wird auf die Spalte PersNr in der Tabelle Vorlesung zugegriffen, die laut Tabellenbeschreibung nicht existiert. Zum Verknüpfen der Tabellen Vorlesung und Professor muss die Tabelle liest mit einbezogen werden.

SELECT
    Vorlesung.VorlNr,
    Vorlesung.Titel,
    Professor.PersNr,
    Professor.Name
  FROM
    Professor,
    liest,
    Vorlesung
  WHERE
    liest.PersNr = Professor.PersNr
    AND Vorlesung.VorlNr = liest.VorlNr

bzw.

SELECT
    Vorlesung.VorlNr,
    Vorlesung.Titel,
    Professor.PersNr,
    Professor.Name
  FROM
    Professor
    JOIN liest ON liest.PersNr = Professor.PersNr
    JOIN Vorlesung ON Vorlesung.VorlNr = liest.VorlNr

(nicht signierter Beitrag von 194.25.93.82 (Diskussion) 10:05, 5. Jun. 2012 (CEST))

Tja, da bin wohl ich schuld für die falsche Fährte. Wie Benutzer:Rare71 im Editkommentar erklärte, wird 'liest' hier nicht als eigenständige Relation aufgefasst. (Theoretisch wäre das zwar möglich gewesen, ist aber praktisch unnötig umständlich.) Sorry und Gruss --Toni am See (Diskussion) 12:30, 5. Jun. 2012 (CEST)

Zusammengesetzte Schlüssel

Zitat: "Schlüssel können auch aus einer Kombination mehrerer Angaben bestehen. Z. B. können die Teilnehmer einer Vorlesung durch die eindeutige Kombination von Vorlesungsnummer und Studentennummer identifiziert werden, so dass die doppelte Anmeldung eines Studenten zu einer Vorlesung ausgeschlossen ist."

Falls es überhaupt ein Beispiel ist, dann ein schlechtes. --Nutzer142 09:48, 8. Aug. 2012 (CEST)

Kritik

Ein Abschnitt über Kritik ( wie z.B.: in der englischen wikipedia) wäre nützlich. (nicht signierter Beitrag von Wikitester2501 (Diskussion | Beiträge) 20:44, 19. Sep. 2012 (CEST))

"Linker äußerer Verbund"

Ich habe mir den Artikel durchgelesen und bin über "linker äußerer Verbund" gestossen. Nach 20 Jahren SQL doch noch etwas neues, habe ich zuerst gedacht, dabei ist das eine Übersetzung von "LEFT OUTER JOIN". Das ging nicht nur mir so, sondern auch einigen Kollegen. Vorab: Mich stört nicht, dass es eine Eindeutschung gibt. Könnte man dennoch irgendwo darauf hinweisen, dass es sich um einen left outer join handelt, ohne gleich in den Code gehen zu müssen? Noch etwas: Schon nach der Überschrift wird die Wortreihenfolge auf "äußerer linker Verbund" gedreht. Muss das sein? --Leuchuk (Diskussion) 09:28, 9. Mär. 2015 (CET)

Tote Links

Die/der folgende Version/Abschnitt http://de.wikipedia.org/w/index.php?title=SQL&oldid=142905958#Erweiterungen enthält einen Link auf einen nicht (mehr?) existierenden Abschnitt "SQL Standards" http://de.wikipedia.org/wiki/SQL#Standard . (nicht signierter Beitrag von 84.56.227.88 (Diskussion) 00:22, 12. Jun. 2015 (CEST))

Einfache Operatoren wie AND, OR; +, -, *, / sollten schon irgendwo erklärt werden

... vielleicht auch || (String-Concatenation). --Haraldmmueller (Diskussion) 11:26, 29. Jul. 2018 (CEST)

So viel Training?

Alle diese vier:

Erklärvideos zu SQL, Big Data Analytics Group, Uni Saarland

SQL-Tutorial

SQLcoach – Freies Üben von SQL

Interaktiver SQL-Trainer

... wozu? --Haraldmmueller (Diskussion) 12:24, 21. Apr. 2019 (CEST)

Wieso "strukturierte" Abfrage-Sprache?

Wenn es eine "strukturierte" Abfrage-Sprache gibt, muss es auch eine "unstrukturierte" geben. Ansonsten wäre das Attribut redundant. Kennt jemand eine "unstrukturierte Abfrage-Sprache" und mag mal ein Beispiel dafür geben? --91.55.216.189 08:07, 17. Aug. 2022 (CEST)