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)
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.
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.
aundnsind 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)
- 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 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)