Diskussion:SQL

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.

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

Fremdschlüssel

Laut meines Lehrers in der Schule sind Fremdschlüssel die in der Slavetabelle (Master und Slavetabllen)ein Primärschlüssel(-teil) sind KEINE Fremdschlüssel in der Slavetabelle. d.h. ein Fremdschlüssel ist 1. ein Schlüssel der in der Mastertabelle ein Primär oder nicht Primärschlüssel ist 2. ein Schlüssel der in der Slavetabelle KEIN Primärschlüssel ist 3. eine Verknüpfung zu einer Mastertabelle

--Darkblue86 10:10, 7. Apr 2005 (CEST)

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

Liste der Relationalen Datenbanksysteme

Ich würde Punkt 10 (Jet) entfernen und dafür bei Punkt 11 (Access) ggf. anmerken: "... mit der Datenbank-Engine 'Jet'.", da 'JetSLQ' kein eigenständiges Datenbanksystem ist. Alternativ könnte man natürlich auch Access löschen, da es nur ein grafischer Aufsatz mit Programmierschnittstelle für Jet ist. Aber Access ist wohl bekannter als Jet und sollte daher eher genannt werden. -- 195.37.188.211 09:29, 15. Apr 2005 (CEST)

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=

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
• Verweise auf andere Abfragesprachen einbauen
• Standardisierungs-Wirrwarr ein bisschen darstellen
• ggfs. SQL-Erweiterungen einzelner Hersteller darstellen (HILFE)

Ich benutze das hier als meine persönliche TODO-Liste, lasst Euch nicht verwirren ;-)