Diskussion:Einführung in SQL/ Archiv

Inhalt und Struktur

Da ich beruflich viel mit SQL zu tun habe, habe ich mich entschieden das Buch "Einführung in SQL" voranzutreiben. Um vorher eine Diskussion über die Struktur und den Inhalt des Buches zu ermöglichen, habe ich meine Ideen als Stichpunkte aufgeschrieben. Vielleicht könnt ihr mir bei der Strukturierung der Kapitel helfen oder ihr habt noch weitere Ideen.

Ursprünglicher Inhalt

• DML
• DDL
• Abfragen (SELECT-Statements)
  • Spalten-Selektion
  • verwendete Tabellen
  • Where-Klauseln
  • Unterabfragen
• Datentypen
• Anlegen, Ändern und Löschen von Tabellen
• Funktionen (Datum, String, ...)
  • sin(), sqrt(), ...
  • nvl(), ...
• Arithmetische Operationen
• Rechteverwaltung
• Einfügen, Ändern, Löschen von Daten (INSERT-, UPDATE-, DELETE-Statements)
• Alias für Tabellen und Spalten
• Referenz über die vorgestellten Befehle

Die Befehle werden alle anhand von Beispielen vorgestellt, die der Leser anhand seiner Datenbank nachvollziehen kann. Danke für eure Hilfe.
-- Mcflash 21:20, 1. Nov. 2006 (CET)

Schön wären auch

• Transaktionen,
• Trigger und
• Prozeduren

-- 84.189.251.225 21:49, 1. Nov. 2006 (CET)

Gute Idee! Die ersten beiden Punkte sollten wir mit aufnehmen. Hierbei muss aber berücksichtigt werden, dass diese Bereiche bei jedem DBMS-Hersteller anders implementiert sind. Ich wollte die Beispiele eigentlich anhand der DBMS Oracle 9i und MySQL 4 demonstrieren. Da sich aber bei den Transaktionen und Trigger mit MySQL 5 einiges getan hat, werde ich dieses DBMS anstatt MySQL 4 nehmen. MySQL 5 muss ich aber erstmal installieren.

Bei den Prozeduren sehe ich aber das Problem, dass dies nicht direkt was mit SQL zu tun hat, da diese Sprache keine prozedurale Sprache ist. Jeder Hersteller kocht hier sein eigenes Süppchen. Oracle nutzt PL/SQL während man in MySQL C++ einbinden. Da dies nichts direkt mit SQL zu tun hat, sollte man dies weglassen. Bspw. ist PL/SQL für ein selbständiges Buch geeignet.

Danke für Deine Hinweise! Ich werd mich nun um die Strukturierung des Buches kümmern und hier dann den Vorschlag für die Diskussion veröffentlichen!

-- Gruß Mcflash 20:37, 2. Nov. 2006 (CET)

Da MySQL 5 doch Stored Procedures und Functions unterstützt, werden diese Punkte doch in einem eigenen Kapitel abgearbeitet.

So, den Vorschlag für die Gliederung des Buches habe ich angelegt. Die Diskussion ist nun eröffnet.
-- Gruß Mcflash 21:20, 2. Nov. 2006 (CET)

Die Kapitel Trigger und Prozeduren gibt es schon in dem Buch PL/SQL. Daher sollten diese Themen hier nicht parallel beschrieben werden. Und wenn doch, dann nur im Überblick mit einem Verweis auf das PL/SQL-Buch. Das Inhaltsverzeichnis dieses Buchs habe ich entsprechend angepasst. --Julius-m 12:32, 16. Jan. 2008 (CET)

Weitere Überlegungen

Nachdem ich jetzt zur "Fortführung" des Projekts ermuntert wurde und damit begonnen habe, sind mir ein paar Punkte aufgefallen, die ich bei der weiteren Bearbeitung berücksichtigen möchte. Falls es Einwände gibt, dann bitte her damit.

• Prozeduren (StoredProcedures) sind inzwischen Standard bei (fast) jeder SQL-Datenbank. Sie gehören also auf jeden Fall auch in eine "Einführung". Ich halte es für sinnvoll, diese zusammen mit Triggern zu bearbeiten, und habe deshalb den Titel dieses Abschnitts schonmal geändert. Dieser Abschnitt sollte dann enthalten: Prozeduren, Trigger, Grundzüge der internen Programmiersprache (bei Firebird heißt es PSQL, bei Oracle PL/SQL)
• Unterschiede zwischen den SQL-Dialekten treten sehr oft auf. Ich denke deshalb über Änderungen im Gesamtaufbau nach und bitte um Kommentare. Alle Beispiele und Vorgaben, z.B. die Struktur der Befehle, sollten ausschließlich nach SQL-2003 gehen. Abweichungen werden im laufenden Text höchstens mit einem Hinweis auf das DBMS versehen. Hinzu kommt ein Abschnitt (in der Einleitung oder im Anhang) mit genaueren Angaben auf die Abweichungen; wahrscheinlich ist - soweit verfügbar - ein Link auf die jeweilige Dokumentation sinnvoll.
• Eine nutzbare Dokumentation zu SQL-2003 ist schwierig zu finden. Ich möchte mich eigentlich beziehen auf: 5WD-02-Foundation-2003-09.pdf (vor allem Kap.11, 14) enthalten in http://www.wiscorp.com/sql_2003_standard.zip Aber dieses Produkt ist so "technisch" konstruiert, dass es schwierig (und äußerst umständlich) ist, dies als Grundlage heranzuziehen. Hat jemand bessere Vorschläge?

-- Juetho 11:19, 10. Apr. 2009 (CEST)

• Die Reihenfolge mancher Kapitel gefällt mir nicht mehr. Ich überlege, den Abschnitt Mehrere Tabellen vorzuziehen und gleich als erstes Kapitel für Fortgeschrittene zu behandeln: Mehrere Tabellen zu kombinieren ist schließlich ein wichtiges Merkmal (das wichtigste?) eines RDBMS und ist bei vielen Beispielen der anderen Kapitel sinnvoll. Für die bisherige Reihenfolge spricht vor allem der Gedanke "vom einfachen zum schwierigen". Gibt es weitere Begründungen für oder gegen diese Änderung? -- Juetho 16:12, 15. Jul. 2009 (CEST)

• Die Präfixe bei den Spaltennamen gefallen mir überhaupt nicht, weil sie keine wesentliche Zusatzinformation enthalten, sondern nur das Lesen und Schreiben erschweren: Entweder der Spaltenname spricht für sich selbst, oder er wird sowieso im Zusammenhang mit dem Tabellennamen verwendet. Also kann man sich darauf beschränken, den "Präfix" als Alias für den Tabellennamen zu benutzen. -- Juetho 15:11, 20. Jul. 2009 (CEST)

Mehrere Tabellen ist recht lang geworden. Das ist zwar unproblematisch, weil es der Sache angemessen ist. Sollte ich es wegen der besseren Übersicht in mehrere Kapitel aufteilen? Beispielsweise

• Einfache Verknüpfungen mehrerer Tabellen
• JOINs, INNER JOIN
• OUTER JOIN

Aber SELF JOIN als eigenes Kapitel? Außerdem gehört das sowohl zu INNER JOIN als auch zu OUTER JOIN. Um mit Lenin zu sprechen: Was tun? -- Juetho 16:07, 17. Aug. 2009 (CEST)

Zusatzinformation: Die Seite umfasst etwa 20 kB. Es ist also vertretbar, sie nicht aufzuteilen. -- Juetho 10:39, 18. Aug. 2009 (CEST)

Ein Satz mit "X" - das war wohl nix. Die Seite umfasst inzwischen 41 kB. Ich muss also doch nachdenken, sie aufzuteilen, und bitte um Kommentare. -- Juetho 18:38, 24. Aug. 2009 (CEST)

Gliederung nochmals überarbeiten?

Eine erneute Änderung der Gliederung ist m.E. sehr sinnvoll. Nachdem ich inzwischen eine ganze Reihe Kapitel geschrieben habe, gefallen mir einige Punkte überhaupt nicht mehr:

• Einige Kapitel wurden zwangsläufig ziemlich lang und überschreiten die empfohlene Maximalgröße von 32 kB oder werden sie voraussichtlich noch überschreiten.
• Eine "Einführung in SELECT" tritt wiederholt auf: bei den grundsätzlichen Befehlen, den Einfachen Abfragen und der ausführlichen SELECT-Struktur.
• Die Verknüpfung "Mehrerer Tabellen" ist für ein RDBMS besonders wichtig, sollte also vorgezogen werden.

Ich möchte die Gliederung deshalb nochmals überarbeiten. Die Titel der Kapitel in der folgenden Übersicht sollen den Inhalt kennzeichnen, nicht die neue Überschrift sein.

Einführung

Einleitung, Relationale Datenbanken, Beispieldatenbank, (neu:) SQL von der natürlichen Sprache abgeleitet

Grundlagen

DML, DDL, DCL, Datentypen, Funktionen mit Untergliederung (dabei werden die bisherigen Kapitel aufgeteilt und übernommen: grundsätzliche Befehle, Einfache Abfragen, Manipulieren von Daten)

Abfragen für Fortgeschrittene

Ausführliche SELECT-Struktur, WHERE-Klausel im Detail, Mehrere Tabellen (getrennt nach "Einfacher Weg", JOINS mit INNER und SELF, OUTER JOINS), Nützliche Erweiterungen, Berechnete Spalten, Gruppierungen, Unterabfragen, Erstellen von Views

Weitere fortgeschrittene Themen

(unverändert)

Anhang

weitgehend unverändert, aber:

die Skripte zum Erstellen der Beispieldatenbank sollen als sql-Dateien zum Download angeboten werden und nicht mehr als Seiten bereitstehen (auch diese Seiten wurden zu lang) (nachgetragen Juetho 12:10, 17. Sep. 2009 (CEST))

das Literaturverzeichnis möchte ich entfernen, da es nicht sehr aktuell ist, nur rudimentär ist, den Vorlieben früherer Bearbeiter entspricht und ich keine umfassende Kenntnisse habe

Bei der Umbenennung der Kapitel werde ich darauf achten, dass die Versionsgeschichte unbedingt erhalten bleibt.
Ich werde bis Ende September abwarten, ob es noch Kommentare zu diesen Gedanken gibt; wenn nicht, werde ich die Gliederung in dieser Weise ändern. -- Juetho 09:35, 17. Sep. 2009 (CEST)

Hallo Juetho, danke für den Hinweis auf meiner Profil-Seite. Erst mal ein Komplement an Dich, Du hast hier ein richtig umfangreiches Buch verfasst. Zu Deinem Vorschlag der Überarbeitung der Gliederung: Ich fände es schade, wenn das Kapitel Der Einstieg wegfallen würde. Ich finde, ein Buch in Wikibooks sollte eben nicht nur - wie Wikipedia - eine möglichst umfassende Abhandlung über ein bestimmtes Thema sein, sondern es sollte ein Buch sein, dass jemandem hilft, sich im Eigenstudium ein bestimmtes Fachgebiet anzueignen. Wenn jemand dieses Buch liest, der noch fast gar nichts von dem Thema weiß, dann ist diesem Leser sehr damit geholfen, wenn es erst mal ein ganz leichtes Kapitel lesen kann, in dem alle wichtigen Bereiche kurz gestreift werden. Wenn er das verstanden hat, dann kann er sich danach den Kapiteln zuwenden, in denen die einzelnen Themen umfassend beschrieben werden. --Julius-m 20:33, 20. Sep. 2009 (CEST)

Danke für die Antwort. Dein Einwand zu Der Einstieg hat etwas für sich. Das Problem, das ich habe, liegt darin, dass es einen Einstieg in SELECT an mehreren Stellen gibt. Das lässt sich aber vermutlich mit passenden Formulierungen steuern, sodass der "Einstieg" etwas anderes wird als die "grundlegenden" DML-Befehle. Ich werde das berücksichtigen. -- Juetho 08:49, 21. Sep. 2009 (CEST)

So, ich fang mal mit einem Kapitel Einführung in SQL: Ein Einstieg an. Da ich mir über den Inhalt und den Zusammenhang mit den anderen Kapiteln noch nicht klar bin, setze ich den Link erstmal nur hierher, aber noch nicht in das Inhaltsverzeichnis. -- Juetho 11:00, 24. Sep. 2009 (CEST)

Die erste Version von Einführung in SQL: Ein Einstieg ist abgeschlossen. Wenn so etwas als geeignet angesehen wird, ist die Frage, an welche Stelle der Einführung es am besten gehört. Mir würde es gefallen, damit anzufangen und erst dann die allgemeine Einleitung und Theorie zu bringen. Aber wie wirkt das? -- Juetho 13:29, 24. Sep. 2009 (CEST)

Hallo Juetho, die Einteilung in Grundlagen und Themen für Fortgeschrittene gefällt mir gut. Ich finde das Kapitel Funktionen allerdings noch ziemlich dick für ein Grundlagen-Kapitel. Wie wäre es, hier nur zwei oder drei Beispiele für Spaltenfunktionen und skalare Funktionen aufzunehmen und dann im Kapitel für die Fortgeschrittenen noch ein par besondere Aspekte der Funktionen zu beleuchten z.B. die Datums- und Zeit Funktionen - eigentlich die Kapitel 4 - 8 aus dem aktuell vorhandenen Kapitel. Die benutzerdefinierten Funktionen würden dann auch viel besser in die Rubrik für die Fortgeschrittenen passen.--Julius-m 21:23, 2. Okt. 2009 (CEST)

Hallo Julius, dein Hinweis passt. Vorschlag: MOD, String-Verknüpfung und LENGTH, EXTRACT, dazu die Konvertierungen bleiben; diese sind für eine Reihe Beispiele von Bedeutung. (Dann braucht das Kapitel "Funktionen" nicht geteilt zu werden.) Die "vertiefenden" Funktionen kommen noch vor "WHERE" als "Weitere eingebaute Funktionen"; denn die logischen Operatoren werden in WHERE benötigt. -- Juetho 10:39, 3. Okt. 2009 (CEST)

So, ich habe die Gliederung jetzt überarbeitet und Hinweise berücksichtigt.

• Einführung mit "Ein Einstieg"
• Grundlagen: DML in "Abfragen" und "Speichern" aufgeteilt (dadurch bleiben die alten Artikel mit Versionsgeschichte und Diskussion erhalten), Funktionen ohne Untergliederung
• Abfragen für Fortgeschrittene: hinzu kommen "weitere Funktionen", die aus den Grundlagen ausgelagert werden sollen; mir fehlen Kommentare zum Titel und zur Position (vor oder nach WHERE?)
• Weitere fortgeschrittene Themen: unverändert zusätzlich DDL mit TABLE, INDEX (siehe unten "DDL-Befehle") (Nachtrag um 16:34)
• Anhang: ohne Fehlermeldungen, neu die Schlüsselwörter (ich werde es einfach aus der SQL-Dokumentation kopieren und mit Erläuterungen versehen)

-- Juetho 11:08, 5. Okt. 2009 (CEST)

Generische / spezielle Beispiele

Hallo, die Gliederung halte ich schonmal für ganz übersichtlich. Ein Vorschlag: Ich hielte es für sinnvoller, Beispiele zuerst in ISO-SQL zu bringen, und dann jeweils für Oracle / MySQL zu spezifizieren. Erstens ist der Buchtitel ja "Einführung in SQL" und nicht "Einführung in MySQL / Oracle", und zweitens könnte man dadurch gerade sehr gut die Spitzfindigkeiten und Unterschiede der Implementierungen zeigen. Bei den Beispieltabellen würde ich z.B. empfehlen, auf der Einstiegsseite ("Tabellenstruktur der Beispieldatenbank") ISO-SQL zu verwenden (varchar2 ist ja bspw. bereits Oracle-spezifisch) und dann unter "_Beispieldatenbank:_Oracle" dann (wie bereits angedeutet dort) die spezifische Syntax. --57.66.193.71 15:19, 20. Nov. 2006 (CET)

Gute Idee! Werde ich berücksichtigen! --Mcflash 20:03, 20. Nov. 2006 (CET)

Grundlegendes Schema einer Einführung

Wie die meisten Bücher beginnt auch dieses mit einer Grünfläche, auf der in diesem Fall eine neue Datenbank entsteht. Aus der Erfahrung finde ich solcher Art Einführungen aber weniger zielführend. Nur so als Idee: Vielleicht bietet eine fertige, minimale Datenbank als Grundlage eine bessere Lernkurve, grade für Einsteiger. In einem nicht-proprietären SQL gescripted, könnten einige genannte Kapitel im Sinne von Erweiterungen gehandhabt werden. Andere könnten einfach in Form eines Anhangs aufgezogen werden. Datentypen ? Anhang. Arithmetik ? Anhang. Solche Dinge im Prinzip zu kennen bzw. unterscheiden zu können kann man bei der Zielgruppe (selbst ein Einsteiger in SQL wird IT-affin sein) voraussetzen.

Im gleichen Zusammenhang: Anleitungen integrieren, wie man schon bestehende Datenbanken erweitert/modifiziert, ohne die Clients in den Wahnsinn zu treiben. Ist auch etwas, das in einem vorgegebenen Beispielprojekt gut gelingen kann. Selten wird nämlich der Neuling, der hier Zielgruppe ist, darauf angesetzt, eine neue Datenbank aus dem Vollen zu schnitzen, sondern er wird "mal eben" an einer Tabelle ein paar neue Felder, Constraints, Foreign Keys definieren müssen, dabei aber nur an einer der zehn betroffenen Stored Procedures schrauben, damit er das Ergebnis im Resultset hat. NULL/NOT NULL, Identity Insert, klingt nicht nach Einsteiger, ich weiss, aber in meinen Augen sind das eher die nutzbringenden Einsteigerthemen, als zum Beispiel ein Kapitel über die Datentypen.

Kapitelvorschläge:

• JOINs

  Indizierung

Wenn ich Dich richtig verstehe, glaube ich, dass Du mich nicht richtig verstanden hast ;-) Das Buch ist schon so konzipiert, dass es eine fertige Datenbankstruktur inkl. Datensätze geben wird, die der Leser zum Üben nutzen kann und soll. Es wird hier also keine neue Datenbank von Grund auf neu aufgebaut.

Diese Datenbank kann der Leser am Anfang des Buches auf seinem DBMS installieren. Dafür gibt es dann die verschiedenen Installationsskripte. In der Einführung ist der Sachverhalt der Datenbank beschrieben, damit der Leser verstehen kann, was in dieser Datenbank (vereinfacht) abgebildet wird.

In den einzelnen Kapiteln hat der Leser dann die Möglichkeit mit dieser Datenbank zu arbeiten: Abfragen, Updaten, Löschen, Erweitern der Datenbankstruktur... Ich glaube also, dass wir beide das gleiche meinen.

Das bspw. aber die Datentypen in den Anhang gehören, sehe ich nicht so. Es ist schon elementar zu wissen, welche Datentypen es gibt. Denn für die verschiedenen Datentypen stehen auch verschiedene Funktionen zur Verfügung. Und nur wenn mir das bewusst ist, kann ich vernünftig mit Funktionen in den Abfragen umgehen.

Der Kapitelvorschlag Joins gehört aus meiner Sicht zu den Abfragen. Die werden in ihren verschiedenen Ausprägungen natürlich berücksichtigt. Die Indizierung kann man sicherlich im Part für die Fortgeschrittenen berücksichtigen.

Habe ich Dich insoweit richtig verstanden? Danke für Deine Kommenentare.

--Mcflash 19:48, 4. Dez. 2006 (CET)

Mag sein, dass ich mich unklar ausgedrückt habe. Ich finde es toll, wenn Du das auf Basis einer Rumpfdatenbank aufziehst, umso besser, wenn Du das ohnehin vorhattest. Worauf ich abziele ist die starre Struktur der Kapitel, die Du aufgelistet hast. Solche Strukturen findest Du in wirklich jedem Einsteigerbuch, sie werden meist eins nach dem anderen durchgekaut. Und ich kann behaupten, dass das nicht unbedingt zielführend (im Sinne des Einsteigers) ist. Wenn ich Dich nicht schon wieder falsch verstehe, willst Du ja keinen SQL-Language-Index schreiben, sondern ein Buch für Einsteiger. Die üblichen Einsteigerbücher kranken daran, dass Du erstmal drei bis fünf Kapitel lesen must, die Dir einzelne Aspekte der Aufgabe isoliert zeigen, bevor Du genug Material gesammelt hast, um die minimalste Aufgabe lösen zu können. So ist ohne das Kapitel Datentypen ein Kapitel Tabellen sinnfrei. Ohne etwas von Inserts und Selects zu wissen, ist das Anlegen von Tabellen eine ziemlich nutzlose Angelegenheit usw. Und danach las sich Deine Liste für mich. Umso schöner, wenn Du es anders im Kopf hast, ich kann ja nur das kommentieren, was ich hier lesen kann.

Bei Funktionen bin ich anderer Ansicht. Funktionen sind etwas, das man im Sprachindex nachschlagen kann, da braucht ein Einsteiger keine Hilfe, wie ein Arkustangens in seiner Lieblingsdatenbank heisst, wird er in der Doku finden, wenn er es braucht. Mit einem solchen Kapitel macht man üblicherweise Masse. Hilfe braucht der Einsteiger eher da, wo es um prinzipielle Zusammenhänge geht, z.B. wie man eine exemplarische Funktion aus den Hunderten in seine Statements erfolgreich einbaut. Stell Dir vor, Du würdest eine Einsteigerschulung vorbereiten und vergleiche deren Konzeption mit der Aufteilung eines Buches. Das wäre das, was ich mir vorstelle, und nur das wollte ich rüberbringen. Wenn es Deiner Idee ähnlich sieht, freu ich mich umso mehr, letztlich hast Du die Arbeit am Hals.

Entschuldigung, dass Du 'ne Weile auf die Antwort warten musstest. Momentan hab ich auf Arbeit relativ Stress, sodass ich aktuell kaum Zeit für Wikibooks habe.

Auch ich denke, dass die Beispiele in einem Einsteigerbuch von Anfang an durch den Leser ausprobiert werden können müssen. Ich habe vor, schon im ersten "richtigen" Kapitel für die Abfragen die Beispieldatenbank zu nutzen. Zu jedem Kapitel wird es auch Aufgaben mit Lösungen geben, sodass der Leser das Wissen üben und vertiefen kann.

Auch bei den Funktionen denken wir beide offensichtlich in die gleiche Richtung. Ich habe im Kapitel nicht vor, auf alle Befehle einzugehen. Es wird anhand von einigen Beispielfunktionen erläutert. Aus eigener Erfahrung denke ich, dass hier insbesondere die Funktionen für die Konvertierung (z.B. to_char, to_date inkl. Formatmasken), für die Zeichenketten (substr, rtrim, upper, lower, ...) und fürs Datum sowie nvl()/ifnull() als Beispiele interessant sind.

Ich finde es super, dass Du Dich für das Buch interessierst. Ich würde mich freuen, wenn Du auch weiterhin ab und zu mal nach dem Rechten siehst und evtl. Deine Kritik bzw. Kommentare äußerst.

--Mcflash 21:25, 7. Dez. 2006 (CET)

Vielleicht sollte man das Buch umbennen in: "Einführung in SQL an Hand praktischer Beispiele" und sich, um das Ganze nachvollziehbar zu machen, auf eines der frei erhältlichen DBMS beschränken. Ich denke da an MySQL 5.x nebst zugehörige administrative Tools mit denen die Einführung direkt nachvollziehbar ist. Stored Procedures etc. haben imho in einer Einführung nichts zu suchen. Die kann ein Folgeband behandeln. Was denkst du Mcflash?

--ezhik 17:00, 21. Dez. 2006 (CET)

Hallo ezhik, Danke für Deine Hinweise. Den Titel finde ich eigentlich so ideal. Nach meinen Verständis von einem "guten Lehrbuch" sollten Einführungen immer anhand von Beispielen erfolgen. Denn so ist der Lernerfolg am größten. D.h. aus meiner Sicht hat der aktuelle Titel die Erweiterung Deines Vorschlags schon implizit enthalten. Und ein kurzer knackiger Titel ist bestimmt auch nicht verkehrt, wenn er aussagekräftig genug ist.

Auf ein bestimmtes Datenbankmanagementsystem möchte ich mich nicht beschränken. Der Leser/Anwender sollte die freie Wahl haben, welches er benutzen möchte. Die Beispiele soll er dennoch in den verschiedenen Systemen nachvollziehen können. Dafür will ich ja die entsprechenden Skripte bereitstellen, die die Beispieldatenbank auf den verschiedenen Systemen anlegt.

Auf die verschiedenen Admin-Tools hatte ich eigentlich nicht vor einzugehen, da es so viele verschiedene gibt. Der Schwerpunkt liegt auf SQL als Sprache. Ob das Resultset einer Abfrage in einer grafischen GUI angezeigt wird oder in einem konsolenbasierten Frontend ausgegeben wird, ist eigentlich unerheblich.

Bzgl. der Stored Procedures und der anderen "erweiterten" Funktionalitäten bin ich mir selber noch nicht sicher, ob diese in das Buch "Einführung in SQL" passen. Das Problem hier sehe ich aber eher, dass jeder Hersteller hier andere Wege gibt. Von meiner Arbeit her komme ich aus der Oracle-Richtung und kenne daher noch nicht die Details bspw. von MySQL. Die systemübergreifende Erklärung dieser erweiterten Themen (ohne auf die Besonderheiten jedes einzelnen System eingehen zu müssen) kann daher sehr schwieriger sein, als ich es mir vorstelle. Ich werde es aber dennoch versuchen.

--Mcflash 21:01, 23. Dez. 2006 (CET)

---

Ich habe mich mal an "Einführung in SQL: Manipulieren von Daten" gemacht. War meine erste Seite, also schaut lieber nochmal drüber ;) --AK-Palme 22:37, 18. Jan. 2007 (CET)

Link herausgenommen; dieses Kapitel ist inzwischen in SQL-Befehle und DML (2) - Daten speichern aufgegangen. -- Juetho 17:04, 10. Nov. 2009 (CET)

Es würde mir besser gefallen, wenn die Tabellen- und Spaltennamen ohne Anführungszeichen angegeben wären. Bei den meisten Datenbanksystemen kann man die Namen nämlich ohne diese Anführungszeichen schreiben. Bei DB2 und Oracle werden diese einfachen Anführungszeichen nur für die Formulierung von Literalen verwendet. Anführungszeichen braucht man nur dann unbedingt, wenn man unbedingt Sonderzeichen oder Leerzeichen in den Tabellen- oder Spaltennamen einbauen muß.

Vielleicht könnte man solche allgemeinen Konventionen in einem der Einleitungskapitel beschreiben.

Dann hätte ich noch den Vorschlag, dass hier nur solche SQL-Statements beschrieben werden, die auf den gängigen Datanbanksystemem getestet wurden, also DB2, Oracle, MySQL (evtl. auch MS-ACCESS ?). Die ersten drei dieser Datenbank-Versionen sind kostenlose Downloads von der Webseite des Herstellers verfügbar und ACCESS hat man vielleicht sowieso installiert. In einem allgemeinen SQL-Buch sollten keine Spezifika eines einzelnen Datenbank-Systems beschrieben werden, es sei denn, dass man explizit auf diese Speziika in den einzelnen Systemen hinweist und z.B. die verschiedenen Varianten miteinander vergleicht. Könnte doch vielleicht auch interessant sein, was bei ACCESS geht und was nicht. Ich hätte alle vier Datanbanken auf meinem PC verfügbar und könnte die SQL-Statements testen und ggfs. ergänzen. Wenn sich andere Autoren finden, die sich mit noch weiteren Datanbanksystemen auskennen, dann können sie das Buch entsprechend ergänzen. --Julius-m 17:45, 1. Jun. 2007 (CEST)

Ich bin auch dafür Tabellen- und Spaltennamen ohne Anführungszeichen zu schreiben. Wir sollten uns auf die allgemeine Konvention einigen. Ich werde das mal in die Hand nehmen und dann entsprechend zu Diskussion stellen. --> Mein Vorschlag ist auf der Projektorganisation-Seite zu finden.

Du hast Recht, wenn Du sagst, wir sollten uns nicht auf bestimmte DBMS festlegen. Die Beispiele sollten auf allen DBMS laufen, die den Standard unterstützen. --Mcflash 19:45, 10. Nov. 2007 (CET)

---

Ich bin jetzt zufällig auf die WikiBooks gestoßen und möchte mich am Buch SQL beteiligen, habe zur Projektorganisation aber ein paar Fragen:

• Unter "Autoren" heißt es, dass man sich in die Liste eintragen kann. Aber in welche Liste, wo steht diese zur Verfügung?
• Die "Vorlagen" sind zwar erwähnt, aber wie genau diese zu benutzen sind, verstehe ich nicht.

Dieser Punkt hat sich teilweise erledigt; unter http://de.wikibooks.org/wiki/Vorlage:Navigation_Text bin ich auch noch fündig geworden.

• Die vorhandenen Kapitel sind für meinen Geschmack sehr kurz gehalten. Ist das Absicht, oder ging es zunächst darum, "etwas" zu veröffentlichen, was später erweitert werden soll?
• Die Diskussionen und Versionen deuten darauf hin, dass sich an diesem Buch nicht allzuviel tut. Ist dieser Eindruck richtig?
• Was ist mit den Übungen? Fehlen die noch vollständig, oder sollten sie in die Kapitel eingebaut werden?
• Hat es also überhaupt Sinn, sich mit Beiträgen zu befassen?

Ich würde mit Unterabfragen und JOINs beginnen; auch die Befehlsreferenz käme für mich in Frage.

Ich arbeite übrigens mit Firebird; durch meine aktive Mitarbeit unter www.mycsharp.de habe ich auch Einblick in verschiedene andere DBMS.

Bitte lasst mich wissen, ob eine Mitarbeit an diesem WikiBook sinnvoll ist. --Juetho 15:53, 8. Apr. 2009 (CEST)

SQL verschieben ins Regal:EDV#Datenbanksysteme (erledigt)

Ich finde, dieses Buch gehört nicht in das Regal:Programmierung, sondern eher in das Regal:EDV#Datenbanksysteme.

Der aktuelle SQL-Standard wurde um einen prozeduralen Teil erweitert. Dieser Teil wird in diesem Buch noch gar nicht erwähnt. Im Buch Oracle (Im Regal:EDV) ist ziemlich viel über PL/SQL beschrieben worden. Ich finde, der PL/SQL-Teil sollte in einem eigenen Buch beschrieben werden, das dann im Regal:Programmierung steht. Alles andere der SQL-Sprache hat mit Programmierung nichts zu tun und gehört in das Regal:EDV#Datenbanksysteme.

Ich bitte um Stellungnahme, dass das Buch SQL ins Regal:EDV#Datenbanksysteme verschoben wird. --Julius-m 17:22, 1. Jun. 2007 (CEST)

Ich habe mit dem Verschieben des Buches nach Regal:EDV#Datenbanksysteme kein Problem. Wenn man es genau nimmt ist SQL keine (Turing)-Programmiersprache. --Mcflash 22:11, 1. Nov. 2007 (CET)

Nun habe ich das Buch SQL ins Regal EDV gestellt. --Julius-m 22:03, 8. Jan. 2008 (CET)

IMHO gehört es eigentlich in beide Regale(!). Zu Programmierung, weil es halt eine Programmiersprache ist, wenn es auch von Turing noch nichts gehört hat. Zu EDV aus den von Julius-m genannten Gründen. Leider habe ich die Diskussion zu spät gesehen, naja, läßt sich ja immer noch so einrichten. Beste Grüße, --Turelion 18:10, 17. Jan. 2008 (CET)

Artikel SQL: Befehle (erledigt)

Was ist das eigentlich für ein Artikel SQL: Befehle. Ein Buch SQL gibt es nicht, bzw. man wird weitergeleitet zu Einführung in SQL. Gibt es vielleicht noch weitere Kapitel SQL:xxx ? --Julius-m 11:43, 7. Jun. 2007 (CEST)

Siehe Wikibooks:Löschkandidaten/_Archiv/_September2006#SQL_(Gelöscht) und dort den Kommentar von "Stefan Majewsky 15:07, 14. Sep 2006 (CEST)" --62.47.61.162 11:46, 7. Jun. 2007 (CEST)

Ich habe diesen Artikel inzwischen "gekapert" und benutze ihn als Einführung in SQL: Befehlsreferenz. -- Juetho 09:06, 17. Sep. 2009 (CEST)

Beispieldatenbank

Immer wieder fallen einem Ungereimtheiten oder "unschöne" Lösungen auf. Ich bitte um Überprüfung, auf welchem Wege dies gelöst werden kann.

Grundlegende Probleme mit ihrer Konzeption

ErfinderDesRades hat unter Relationale Datenbanken und unter Beispieldatenbank Argumente von so grundlegender Natur gebracht, dass sie Auswirkungen auf das gesamte Buch haben können. Ich möchte es deshalb hier zusammengefasst diskutieren.

Datenmodell zu abstrakt

Entitäten, Attribute

Praktischer Bezug unzureichend

Handelt es sich um eine Versicherungsgesellschaft, eine Agentur oder was?

Fehlende Bereiche

ForeignKeys, weitere Tabellen und Felder

Unpraktische Umsetzung

Tabellennamen im Plural u.ä.

ER-Diagramm

enthält Unklarheiten und Mängel

Praktischer Vorschlag

Es handelt sich um eine "Einführung in SQL", nicht um "Alles über RDBMS". Ich möchte deshalb die Konzeption (und auch die Beispieldatenbank) nicht mehr grundsätzlich ändern, die Kritik aber wie folgt aufgreifen und berücksichtigen.

• Die Beispieldatenbank wird nur soweit geändert, wie es für die Zwecke des Buches "Einführung in SQL" wichtig ist. Vor allem werden nur notwendige zusätzliche Tabellen und Spalten hinzugefügt, aber nicht solche, die zusätzlich sinnvoll wären. Ich vermisse vor allem die Möglichkeit für mindestens eine sinnvolle StoredProcedure, habe allerdings noch keine Idee für eine einfache Erweiterung.
• Namen von Tabellen und Spalten werden nicht mehr geändert. Die stehen jetzt schon in so vielen Seiten und Beispielen, dass mit Sicherheit die eine oder andere Stelle übersehen würde. Das würde die Leser mehr verwirren, als wenn wir jetzt die "falschen" Bezeichner behalten.
• Die Kapitel "Relationale Datenbanken" und "Beispieldatenbank" werden praxisnäher, mit erheblich weniger theoretischem Überbau und passender für SQL-Anfänger umformuliert.
• Das Kapitel "Beispieldatenbank" erhält einen zusätzlichen Abschnitt "Mängel an dieser Struktur" mit einer Auflistung aller relevanten Kritikpunkte sowie eine Begründung, warum diese Mängel hingenommen werden.

Bitte lasst mich wissen, was ihr von diesem Vorgehen haltet. Bis dahin werde ich erstmal die vorhandenen Kapitel an die geänderte Gliederung anpassen. -- Juetho 12:07, 3. Okt. 2009 (CEST)

Mir ist (in Ergänzung zu den vorstehenden Gedanken) jetzt folgende Überlegung gekommen:

1. Die Änderungen, die noch kommen, werden in DDL - Einzelheiten und Fremdschlüssel-Beziehungen besprochen und in Änderung der Datenbankstruktur ausgeführt.
2. Geändert werden nur die Namen der Tabellen, die Namen der Spalten normalerweise nicht.
3. Die Tabelle Versicherungsvertrag erhält folgende Spalten: Basisprämie pro Jahr, aktueller Prämiensatz (bei Neuverträgen 100%, Anfänger mehr, unfallfreie Fahrer weniger), letzte Änderung des Prämiensatzes
4. Damit kann in Prozeduren eine StoredProcedure erzeugt und genutzt werden: Aktualisiere die Prämiensätze nach letzter Änderung und aktuellen Schadensfällen einschließlich Schadenshöhe.
5. Andere Tabellen werden nicht geändert.

Wenn es keine Kommentare dazu gibt, werde ich so verfahren. -- Juetho 12:29, 15. Okt. 2009 (CEST) -- Nachtrag Juetho 16:32, 18. Okt. 2009 (CEST)

CHAR oder VARCHAR bei verschiedenen Feldern (erledigt)

• Pflichtfelder varchar(1) und varchar(2) sind sinnvollerweise als char zu definieren.
• Gleiches gilt für das PLZ-Feld, siehe die Erläuterung unter Datentypen.

Ich setze dies mal unter Projektorganisation in die ToDo-Liste; aber es kann noch diskutiert werden. -- Juetho 17:11, 15. Jul. 2009 (CEST)

Die varchar-Felder mit 1,2,5 Zeichen Länge habe ich inzwischen in char-Felder geändert; dies ist nicht mehr in der ToDo-Liste enthalten. -- Juetho 12:03, 18. Jul. 2009 (CEST)

ForeignKeys (erledigt)

Außerdem vermisse ich die Definition der ganzen ForeignKeys, obwohl sie immer erwähnt sind. Ich setze auch dies unter Projektorganisation in die ToDo-Liste. -- Juetho 17:11, 15. Jul. 2009 (CEST)

Das kommt jetzt unter Beispieldatenbank in die "Liste der Mängel" und wird unter Fremdschlüssel-Beziehungen sowie Änderung der Datenbankstruktur nachgeholt. -- Juetho 16:39, 18. Okt. 2009 (CEST)

Neue Tabelle "Dienstwagen" (erledigt)

Problem: Es können keine sinnvollen Beispiele für OUTER JOIN in Mehrere Tabellen konstruiert werden. Ich füge deshalb eine Tabelle "Dienstwagen" hinzu. Diese entspricht der Tabelle der (versicherten) Fahrzeuge, ergänzt um eine optionale Zuordnung zu einem Mitarbeiter. -- Juetho 16:39, 14. Aug. 2009 (CEST)

Tabelle "Versicherungsverträge" genügt nicht (erledigt)

Ich vermisse inzwischen: Schadensfreiheitsrabatt, Termin der Änderung dafür; separate Tabelle für Tarife; separate Tabelle(n) für Rechnungen und Zahlungen.

Auslöser für diese Anmerkung ist, dass mit den bisherigen Daten keine sinnvolle StoredProcedure benutzt werden kann – nämlich eine Automatik, um neue Daten zu erzeugen oder Daten zu ändern, wenn gewisse Bedingungen - z.B. Zeitablauf - erfüllt sind. -- Juetho 09:46, 24. Sep. 2009 (CEST)

Wird als "erledigt" angesehen: Es kommt unter Beispieldatenbank in die "Liste der Mängel" und wird unter Änderung der Datenbankstruktur nachgeholt. -- Juetho 16:47, 18. Okt. 2009 (CEST)

Normalisierung reicht nicht (erledigt)

Es gibt zwei Tabellen für "Personen", nämlich Mitarbeiter und Versicherungsnehmer. Auch für die Mitarbeiter ist die Privatanschrift zu speichern; auch für Versicherungsnehmer sind Kontaktdaten sinnvoll. Aber soll wirklich jetzt, wo die Mehrzahl der Kapitel (mit entsprechend vielen Beispielen) erstellt ist, die Struktur so stark geändert werden? Ich weiß nicht recht... -- Juetho 09:46, 24. Sep. 2009 (CEST)

Wird als "erledigt" angesehen: Es kommt unter Beispieldatenbank in die "Liste der Mängel", aber nicht mehr geändert. -- Juetho 16:47, 18. Okt. 2009 (CEST)

Wozu die Tabellen ZUORD_VNE_SCF und ZUORD_FZG_SCF? (erledigt)

Eine der beiden Zuordnungstabellen reicht doch; die Werte der anderen erhält man durch die ForeignKeys. Vorschlag (so habe ich es mit den Testdaten gemacht): Es wird nur ZUORD_FZG_SCF benutzt; dort kommt noch die Schadenshöhe (anteilig) hinzu. Die Liste der Schadensfälle pro Versicherungsnehmer erhält man durch JOINS auf Fahrzeug -> Versicherungsvertrag -> Versicherungsnehmer. -- Juetho 09:46, 24. Sep. 2009 (CEST)

Wird als "erledigt" angesehen. In der (geänderten) Firebird-Version gibt es Zuordnung_FZG_SCF incl. Schadenshoehe. -- Juetho 16:47, 18. Okt. 2009 (CEST)

Weitere sinnvolle Spalten (erledigt)

• Mitarbeiter, Versicherungsnehmer (Personen): Geschlecht (wegen der Anrede). -- Juetho 12:20, 24. Sep. 2009 (CEST)

Wird als "erledigt" angesehen: Es kommt unter Beispieldatenbank in die "Liste der Mängel" und wird unter Änderung der Datenbankstruktur nachgeholt. -- Juetho 16:47, 18. Okt. 2009 (CEST)

Problematischen Farben (erledigt)

Hallo! Die hellgrünen Operatoren und Klammern sind auf den farbigen Hintergründen, kaum zu erkennen. Da sollte man vielleicht auf Hintergrundfarbe verzichten. --84.131.156.13 11:36, 13. Jul. 2009 (CEST)

Das erledigt sich durch die geänderte Vorlage:Code von selbst. Auf der Seite Gruppierungen habe ich alle Beispiele bereits umgestellt; siehe auch die ToDo-Liste auf der Seite Projektorganisation. -- Juetho 16:15, 15. Jul. 2009 (CEST)

DDL-Befehle

Ich möchte eine Frage zur Abgrenzung bzw. Ausgrenzung von Themen in diesem Artikel anregen. Ich finde es gut, die DML hier ganz ausführlich zu beschreiben. Dieser Teil der SQL-Sprache ist ganz klar vom ANSI beschrieben. Ich bin mir aber nicht sicher, wie weit die DDL überhaupt vom ANSI-SQL definiert wird und ob überhaupt. Denn es ist ja so, dass es hier sehr große Unterschiede bei den einzelnen Datenbank-Herstellern gibt. Die Syntax der einzelnen Datenbank-Produkte ist reich an vielen Spezifika der betreffenden Hersteller und sogar der einzelnen Release. Noch unterschiedlicher sind sicher die sonstigen Tools wie z.B. Ixport, Import, Load, Runstats, Reorg, Explain. Was die DDL betrifft, sehe ich drei Möglichkeiten für dieses Buch:

• man spart die DDL ganz aus diesem Buch aus und verweise auf das Buch Oracle, wo die DDL ja schon beschrieben wird.
• hier werden nur die Befehle beschrieben, die so ziemlich in allen Datenbank-Systemen gleich sind. Das wäre, CREATE/DROP/ALTER für Table, Index, View. evtl auch noch Trigger, Procedure, Function. Das wäre so ungefahr der Umfang, der aktuell in dem Kapitel SQL-Befehle vorliegt.
• Oder man beschreibt die Befehle noch etwas detaillierter (Partitionierung, Primary-Key-Angaben, Null, External Tables, Verschiedene Arten von Indices), dann wäre es aber zwingend erforderlich, auf die Unterschiede der verschiedenen Dialekte der einzelnen Datenbank-Hersteller einzugehen.

In jedem Fall sollten wir aufpassen, dass 1. in diesem Artikel nicht nur die Syntax eines bestimmten Datenbank-Produkts beschreiben wird und 2. nicht Themen beschreiben werden, die breits im Buch Oracle ausführlich abgehandelt werden. --Julius-m 22:26, 20. Sep. 2009 (CEST)

Danke für diese Anregungen. Zu den genannten Möglichkeiten: (1) gefällt mir weniger, weil Oracle viel zu sehr auf dieses DBMS ausgerichtet ist. (2) gefällt mir mehr, weil das (wie du schreibst) relativ einheitlich gilt. (3) gefällt mir weniger wegen der massiven Unterschiede der SQL-Dialekte. (Ich habe mich schon bei den DML-Beschreibungen sehr oft gewunden, wenn ich das berücksichtigen wollte.) Meine Empfehlung lautet also klar: Die unter (2) genannten Befehle werden in den unter "Weitere fortgeschrittene Themen" genannten Kapiteln behandelt. Mal sehen, ob es noch andere Kommentare gibt. -- Juetho 09:17, 21. Sep. 2009 (CEST)

Nachdem ich die Gliederung überarbeitet habe, wollte ich jetzt die "neuen" Kapitel passend formulieren. Dabei bin ich über ein neues Problem gestolpert, das ich bei mir erstmal "sacken" lassen muss. CREATE TABLE ist durch die wahnsinnig vielen Optionen so komplex, dass es keinesfalls unter "Grundlagen" passt. Ich tendiere deshalb jetzt dazu: (1) In den Grundlagen bleibt es nur etwa in dem Umfang, in dem es bisher unter "Befehlsreferenz" steht, mit entsprechend einfachen Beispielen. (2) Unter "fortgeschrittene Themen" kommt ein neues Kapitel dazu, das TABLE, INDEX behandelt. (3) "Änderung der Datenbankstruktur" baut darauf auf. (4) Die "Befehlsreferenz" wird in diesem Zusammenhang ausführlicher, aber Beispiele entfallen. Kommentare? -- Juetho 16:32, 5. Okt. 2009 (CEST)

DML-Befehle

SELECT INTO

Zur Vollständigkeit von SELECT gehört auch die INTO-Klausel. Ich habe diese bisher vollständig ignoriert, weil sie nicht zu "separaten" Abfragen gehört. Aber spätestens bei Prozeduren usw. ist sie wichtig. Frage: Sollte ich diese Klausel bereits unter Einführung in SQL: Ausführliche SELECT-Struktur behandeln oder erst unter Prozeduren erwähnen? -- Juetho 11:24, 21. Sep. 2009 (CEST)

Die INTO-Klause gehört nicht zum SELECT-Befehl im engeren Sinne. Sie wird immer dann benötigt, wenn SELECT in eine Programmiersprache eingebettet wird. Das kann PL/SQL sein, kann aber auch C, JAVA, COBOL sein. Ich fände es sinnvoll, über die Einbettung in Programmiersprachen ein eigenes Kapitel zu schreiben. Da sollte dann auch auf CURSOR, UPDATE ... WHERE CURRENT OF <Cursor>, Block-Fetch und so weiter beschrieben werden. --Julius-m 23:18, 26. Sep. 2009 (CEST)

Eigentlich verstehe ich das auch so. Aber in der SQL-Dokumentation steht unter "14.5 <select statement: single row>" diese Definition: "<select statement: single row> ::= SELECT [ <set quantifier> ] <select list> INTO <select target list> " – das INTO käme also noch vor der FROM-Klausel. Aber ich gebe dir trotzdem recht (auf jeden Fall für die Praxis): In einer "normalen" Abfrage spielt INTO keine Rolle; also sollte es erst unter Prozeduren unter "Programmieren mit SQL" erwähnt werden. -- Juetho 16:43, 27. Sep. 2009 (CEST)

TCL-Befehle (erledigt)

Im Bereich "Grundlagen" ist TCL - Ablaufsteuerung enthalten. Da es sich insgesamt um eine "Einführung in SQL" handelt, tendiere ich dazu, auf das Kapitel Transaktionen im Bereich "Weitere fortgeschrittene Themen" zu verzichten. Mir fällt so gut wie nichts ein, welche "einführenden" Erläuterungen man noch geben könnte. Kommentare dazu? -- Juetho 16:56, 12. Okt. 2009 (CEST)

Da sich bisher niemand dazu geäußert hat und mir nach wie vor keine "erweiterten Informationen" einfallen, entschließe ich mich, dieses Kapitel im Inhaltsverzeichnis zu streichen. -- Juetho 16:44, 20. Dez. 2009 (CET)

Fehlermeldungen

Im Anhang ist unter Einführung in SQL: Fehlermeldungen eine solche Liste vorgesehen. Ich bin mir nicht (mehr) sicher, inwieweit das sinnvoll ist:

• Diese Liste müsste eigentlich sehr umfangreich sein.
• Woher kann man sie nehmen? Die von mir verwendete SQL-Dokumentation (siehe "Geschichte von SQL" auf Einführung in SQL: Einleitung) enthält im Kap. 13.4 Calls to an <externally-invoked procedure> ab Seite 775 eine längere, aber dennoch vermutlich unvollständige Liste.
• Wonach kann man überhaupt zwischen "wichtigen" und "unwichtigen" Fehlern unterscheiden?
• Zu einer Liste müssten eigentlich gehören: Fehlernummer, Fehlername, Beschreibung, Ursachen, Möglichkeiten der Beseitigung. Kann man das überhaupt schaffen?

-- Juetho 11:45, 21. Sep. 2009 (CEST)

Wenn man Fehlermeldungen hier beschreiben will, sollte man nur allgemein darüber schreiben. Sobald man anfängt, bestimmte Fehlercodes hier auszuzählen und zu beschreiben, beschreibt man ein ganz bestimmtes Datenbank-Produkt. Im Übrigen sind die Fehlermeldungen auch vom ANSI standardisiert worden. Der Vorteil davon ist, dass diese herstellerunabhängig definiert wurden, der entscheidende Nachteil ist aber, dass diese Einteilung logischerweise nur sehr grob sein kann. Die herstellerspezifischen Fehlermeldungen sind viel detaillierter und helfen bei der Fehlersuche viel mehr. Aber sie können sich auch von einem zum nächsten Release des selben Datenbank-Produkts unterscheiden. Jede neue Funktion erfordert natürlich auch neue gezielte Fehlermeldungen --Julius-m 23:26, 26. Sep. 2009 (CEST)

Da es auch von den früheren Bearbeitern und Diskutanten nur für den Anhang vorgesehen war, sollte es also vollständig gestrichen werden. Dass Fehlermeldungen dennoch relevant sind, ergibt sich durch ein paar Beispiele, bei denen ich einen Error als Ergebnis mitgegeben habe. -- Juetho 16:45, 27. Sep. 2009 (CEST)

Das finde ich gut. Fehlermeldungen nur als Randbemerkung, wenn es zur Erläuterung eines bestimmten Sachverhalts dient, aber keine systematische oder vollständige Erläuterung. Da sollte man lieber einen Link zu den entsprechenden Manuals einiger bekannten Datenbankprodukthersteller aufnehmen. --Julius-m 20:02, 29. Sep. 2009 (CEST)

Unter Einführung in SQL: Einleitung stehen diese Links schon sehr lange, nämlich dort, wo die verschiedenen DBMS erwähnt und "eingeführt" werden. -- Juetho 09:44, 30. Sep. 2009 (CEST)

Aber du hast recht: Ein Abschnitt "Weblinks" im Anhang passt, also gehören dorthin auch die Verweise. -- Juetho 09:49, 30. Sep. 2009 (CEST)

Grundwissen / Ergänzung

Da dies ja eine Einführung in SQL darstellen soll, würde ich auf jedenfall auch das Grundwissen mit dazunehmen. Hier wäre evtl. ein Thema bezüglich z.B. Normalisierung und Relationen zwischen Tabellen nicht schlecht. Kommentar von Benutzer:Natok aus c-sharp-forum 12:12, 5. Dez. 2009 (CET)

Kommentar: Datenbank-Strukturen werden einfach benutzt, siehe Einführung in SQL: Projektorganisation#Abgrenzung und Einführung in SQL: Relationale Datenbanken#Beispielhafte Struktur. Relationen werden besprochen, nur dieser Begriff wird vermieden. Siehe Einführung in SQL: Relationale Datenbanken#Verknüpfungen und Schlüssel und Einführung in SQL: Fremdschlüssel-Beziehungen. -- Juetho 12:59, 5. Dez. 2009 (CET)

Danke schön!

Hallo Jürgen, Dein Wikibook hilft mir sehr bei der Arbeit mit SQL. Es ist gut strukturiert, praxisnah und v.a. verständlich. Danke für dieses Buch! --195.145.109.58 09:33, 21. Jan. 2010 (CET) verschoben von Benutzer Diskussion:Juetho

Übernommen von Benutzer:Juetho

Die folgenden Diskussionen standen vorher unter Benutzer Diskussion:Juetho.

Du kannst dich in die Liste unter Einführung in SQL: Projektorganisation eintragen. Ändere das Buch so, wie es dir gefällt. Zur Zeit gibt es niemanden außer dir, der das Buch bearbeitet. Fühl dich frei ;-) Das Buch gehört zu denjenigen, die ich gerne mal lesen würde. -- Tandar(D, B) 16:08, 8. Apr. 2009 (CEST)

• Hi Nochmal! In der Einführung gibt es den Hinweis auf Freie und kommerzielle DBMS. Das sind beides keine Gegensätze im Sinne von Freier Software (jemand könnte für das Programm PostgreSQL Geld verlangen). Im Sinne "kostenloser Software" ist "frei" hier vielleicht das falsche Wort. Welches "Frei" ist denn gemeint? -- Tandar(D, B) 15:07, 9. Apr. 2009 (CEST)

• Hmm, da müssten wir wohl den früheren Bearbeiter (McFlash?) fragen. Ich hatte diese Unterscheidung zunächst belassen; mir war zwar auch nicht wohl dabei, aber die alternativen Formulierungen, die mir bisher durch den Kopf gegangen waren, gefielen mir noch weniger. Ich werde weiter darüber nachdenken. -- Juetho 16:23, 9. Apr. 2009 (CEST)

Ich habe inzwischen eine passende Formulierung eingefügt, siehe Einführung in SQL: Einleitung. -- Juetho 17:56, 7. Nov. 2009 (CET)

Hallo Juetho, ich beobachte Dein Treiben schon eine ganze Weile, und zwar sehr wohlwollend. Ich habe den Eindruck gewonnen, dass Du von der Materie mehr Ahnung hast als meine Wenigkeit, vor allem, daß Du diesbezüglich auf dem neuesten Stand bist. Da ich da nicht mithalten kann, werde ich den Entscheidungsfindungsprozess nicht dadurch erschweren, indem ich so tue, als könnte ich es doch. Stattdessen möchte ich Dich ermutigen, mit Deiner Arbeit so fortzufahren, wie Du es für richtig hältst. --Turelion 07:59, 20. Sep. 2009 (CEST)

Mit dieser Stellungnahme kann ich bei meinem "Treiben" :-) und hinsichtlich der Notwendigkeit, die Gliederung zu überarbeiten, auch etwas anfangen. Danke schön! -- Juetho 10:34, 20. Sep. 2009 (CEST)

Hallo Juetho, ich finde es klasse, wir Du Dich für dieses Thema angagierst und wie gut dieses Buch inzwischen geworden ist. Lasse uns die Überarbeitung des Kapitels Fremdschlüssel dort auf der Diskussions-Seite planen und diskutieren. Die Überarbeitung der SQL-Beispiel-Skripte (Anpassung an die Beispiel-Tabellen) würde ich gerne Dir überlassen. Ich würde mich gerne darauf beschränken, die Kompatibilität zu Oracle zu prüfen und hier und da Anmerkungen zu geben. Themen die mich interessieren, sind mehr die neueren SQL-Erweiterungen, die auch durch ANSI vereinheitlicht werden wie z.B. XML-Verarbeitung, die Datawarehouse-Extensions. Aber hier ist mein eigenes Wissen noch recht dünn. Auch die ANSI-Syntax zu PL/SQL würde mich sehr interessieren, aber hier kenne ich bisher überhaupt keine Literatur oder andere Quellen. Literatur zu PL/SQL der einzelnen Datenbanken gibt es genug, aber nur sehr wenig zum ANSI-PL/SQL. --Julius-m 20:39, 4. Nov. 2009 (CET)

Mit den Beispielen bin ich einverstanden. Einen Vorschlag zur Überarbeitung werde ich formulieren. -- Juetho 15:55, 5. Nov. 2009 (CET)

Hallo Juetho, noch mal meinen Respekt vor Deiner Arbeit und wie Du das Buch inzwischen wirklich gut und fast vollständig gestaltet hast. Ich habe fast ein schlechtes Gewissen, dass ich mich kaum daran beteiligt habe. Zu dem Kapitel Fremdschlüssel: Mit Deinem Alternativ-Vorschlag bis ich 100% einverstanden. Mit liegen eigentlich nur die beiden Skripte zur Einfügereihenfolge am Herzen, dass die bleiben, denn die brauche ich öfters mal. Und Wikibooks ist nun mal eine überall verfügbare Informationsquelle, aus der ich mir so ein Skript leicht herauskopieren kann, wenn ich irgendwo mal bei einem Kunden bin und eines dieser Skripte gerade brauche. Ich selber bin seit einigen Monaten sehr viel mit Unix-Systemadministration beschäftigt. Hier lese ich viel und versuche, alle relevanten Aspekte zu lernen und zu verinnerlichen. Zut Zeit schlägt mein Herz mehr bei diesem Thema. Das ist sicher der Grund für mein nachlassendes Interesse an SQL-Themen. Trotzdem will ich mir immer wieder mal Zeit nehmen, um Deine Texte zu lesen und Hinweise zu geben. Auch das eine oder andere Syntaxbeispiel für Oracle will ich noch beisteuern. --Julius-m 22:31, 18. Dez. 2009 (CET)

Danke für deine Antworten und Anregungen. (Siehe meine entsprechenden Antworten.)

Zu den Fremdschlüsseln: "Mir liegen eigentlich nur die beiden Skripte zur Einfügereihenfolge am Herzen..." Ich befürchte, dass ausgerechnet diese entfallen müssen, weil rekursive Schlüssel mit mehreren Ebenen für diese "Einführung" nicht passen. Der Abschnitt als solcher sollte natürlich bleiben, aber über die endgültige Form bin ich mir noch nicht klar.

Andererseits hatte ich schon zugesichert, dass die bisherige Version (vor allem auch wegen der Autoren-Liste auf der Diskussionsseite) erhalten bleibt. Vermutlich werde ich sie verschieben, sodass sie von deiner Benutzer-Seite aus zugänglich ist. Damit sollten beide Seiten zufrieden sein.

Gruß -- Juetho 13:15, 20. Dez. 2009 (CET)

Hallo Juetho, Du hast so viel zu diesem Buch beigetragen, dass ich Dir bei der Gestaltung nicht widersprechen will. Wenn Du meinst, dass die beiden Skripte wirklich in dieses Buch nicht reinpassen, dann akzeptiere ich es. Ich habe die beiden Skripte direkt auf meine Startseite übernommen, nun kannst Du sie löschen. Allerdings fände ich es gut, wenn Du die Versionshistorie auf dieser Seite belassen würdest, denn das ist ja nun mal ein wesentlicher Bestandteil der Fremdschlüssel-Seite. --Julius-m 16:43, 26. Dez. 2009 (CET)

Ich weiß; keine Bange, die Historie bleibt erhalten. -- Juetho 20:21, 26. Dez. 2009 (CET)

Hallo Juetho, heute habe ich zwei Anliegen: 1. Deine Anmerkung auf meiner Diskussionsseite vom 27.12. verstehe ich nicht recht. Wie wäre es, wenn wir mal miteinander telefonieren. Ich finde, dass man viele Themen im Dialog viel besser klären kann. Ich würde Dich sowieso germe mal etwas mehr persönlich kennen lernen und etwas mit Dir plaudern, was Du so machst, was Dich interessiert und so. Magst Du mich mal anrufen? 08106-9958403 oder 0173-2666232. Du erreichst mich am besten zwischen 20 und 22 Uhr. 2. Hätte ich noch den Vorschlag, in dem Buch "Einführung in SQL" ein Kapitel "Sonstige Themen" oder "Weiterführende Themen" aufzunehmen. In diesem Kapitel könnte man dann alles sammeln, von dem Du meinst, dass es in eine Einführung eigentlich nicht reingehört, wie z.B. die Inline-View WITH oder auch die geilen DWH-Extensions, die ich auf der Diskussionsseite für Fremdschlüsselbeziehungen beschrieben habe. Was hälst Du davon? --Julius-m 23:19, 29. Dez. 2009 (CET)

Firebird kennt Inline-Views; ich hätte die Befehlsstruktur richtig beachten müssen. Aber ist es richtig, dass dies nur für SELECT verwendet werden kann, nicht jedoch für UPDATE? -- Jürgen 12:04, 9. Jan. 2010 (CET)

Hallo Jürgen, ich schreibe meine Antwort mal direkt hier auf Deine Diskussionsseite: Für UPDATE sind eigentlich Unterabfragen (Subselects) eigentlich sowieso nicht vorgesehen. Allerdings kann man - wie in Deinem Buch bereits erwähnt - zur Ermittlung bestimmter Werte Unterabfragen verwenden. Ob man grundsätzlich bei Unterabfragen auch WITH verwenden darf, habe ich noch ausprobiert. --Julius-m 19:11, 9. Jan. 2010 (CET)

Noch etwas zu Einführung in SQL: Mehr zu JOIN#WITH – Inline-View: Ich möchte dabei im letzten Absatz nicht mehr auf Fremdschlüssel-Beziehungen verweisen, da im selben Kapitel oben bei SELF JOIN schon komplizierte Abfragen stehen. Mir würde es gefallen, wenn einer der Lösungswege 1 und 2 umgeschrieben würde. Da WITH etwas komplexer ist und für mich ungewohnt ist und VIEWs nicht mit variablen Parametern arbeiten können, hänge ich an der Stelle fest.

Ich glaube, ich habe eine Variante für den Lösungsweg 1 gefunden mit WITH:

WITH sf AS
( SELECT Datum, Fahrzeug_ID
  FROM Zuordnung_SF_FZ 
  JOIN Schadensfall 
  ON Schadensfall_ID = ID
)
SELECT fz.ID, fz.Kennzeichen, 
       sf1.Datum AS Datum1, sf2.Datum AS Datum2, sf2.Datum - sf1.Datum AS Abstand
  FROM sf             sf1
       JOIN sf        sf2 ON sf1.Fahrzeug_ID = sf2.Fahrzeug_ID
       JOIN Fahrzeug  fz  ON sf1.Fahrzeug_ID = fz.ID
 WHERE sf1.Datum < sf2.Datum
   AND sf2.Datum = ( SELECT MIN(sf3.Datum)
                       FROM sf sf3 
                      WHERE sf1.Datum < sf3.Datum
                        AND sf3.Fahrzeug_ID = zu1.Fahrzeug_ID )
 ORDER BY fz.ID, Datum1;

Ich habe es allerdings nicht getestet, weil ich die Beispieltabellen bei mir nicht erstellt habe. Aber ich glaube, so könnte es gehen und es müsste das selbe Ergebnis bringen, wie das SQL-Statement von Dir. Ich meine, diese Formulierung mit WITH ist in diesem Fall sogar einfacher und leichter zu verstehen. Viele Grüße --Julius-m 22:23, 9. Jan. 2010 (CET)

Anregungen

Hi nochmal, ich wollte mal meinen Senf zu dem wirklich schon sehr guten Buch geben. Ich hoffe, dir ist das recht, man bekommt ja leider so wenig Kritik und Lob zu einem hier veröffentlichten Buch.

• Einführung_in_SQL:_Ausführliche_SELECT-Struktur Hier steht am Anfang:

Dieses Kapitel erläutert die vollständige Syntax des SELECT-Befehls. und Der SELECT-Befehl bietet so umfangreiche Möglichkeiten, dass ich auch bei dieser Übersicht nicht alle Einzelheiten vorstellen kann. Meiner Ansicht nach widersprechen sich diese beiden Aussagen. Ich finde es auch nicht schlimm, dass man nicht alles zeigen und erläutern kann.

• Einführung in SQL: DCL - Zugriffsrechte ist noch sehr kurz. Ein grobe Übersicht, welche Rechte ich modifizieren kann wäre schön.
• Die Lösung, den Leser mit "Sie" anzusprechen (Beispiel:Bitte probieren Sie alle Beispiele aus) finde ich persönlich sehr angenehm.
• Die Formatvorlagen und die doppelte Navigation (oben und unten) im Buch finde ich super!!!
• Wird irgendwo die Bedeutung der eckigen / spitzen Klammern erläutert? Vielleicht habe ich es nur übersehen.
• Die hoch-Links nach jedem Absatz stören meiner Meinung nach den Lesefluss. Ich weiss, dass die sehr hilfreich sind, aber vielleicht kann man sie etws dezenter einsetzen.
• Lass vielleicht die Überschrift "Übungen" weg, wenn keine Übungen da sind. Z. B. Einführung_in_SQL:_Gruppierungen
• "Zusammenfassung" auf jeder Seite finde ich gut!
• Einführung_in_SQL:_Transaktionen gehört gelöscht oder? lach

Insgesamt ein schönes Buch -- Tandar(D, B) 10:44, 23. Nov. 2009 (CET)

Danke recht herzlich für die Anregungen. Sonst bekommt man ja wenig Reaktionen. Zu deinen Anmerkungen:

• Ausführliche_SELECT-Struktur: Stimmt, das klingt komisch. In Kürze gibt es die Schlussredaktion, auch für solche Formulierungen.
• Zugriffsrechte: IMHO geht das über eine Einführung hinaus; die Zielgruppe sind keine Systemadministratoren. Mal sehen, ob ich noch eine Übersicht einfüge.
• Zur Anrede siehe auch Wikibooks:Ich brauche Hilfe#"Sie" oder "ihr"?.
• Die Klammern werden erläutert unter Einführung in SQL: Einleitung#Regeln für die Beispiele.
• Vorlage: Navigation hoch gab es fertig, deshalb habe ich es genommen. Zum einen sollte es nach etwa einer Bildschirmseite kommen, zum anderen wollte ich es mit den Gliederungsebenen in Übereinstimmung bringen. Inzwischen kenne ich mich mit Vorlagen und Icons etwas besser aus; vielleicht baue ich noch ein kleines Icon mit Link.
• Die Übungen kommen alle noch, siehe Einführung in SQL: Projektorganisation#ToDo-Liste.
• Diese Seite der Transaktionen gehörte in der Tat gelöscht. Aber unter Diskussion:Einführung in SQL#TCL-Befehle frage ich selbst, ob dieses Kapitel noch sinnvoll/notwendig ist.

Ich bin heilfroh, dass es dem Ende zugeht. Jetzt fehlen nur noch Kommentare von Fachleuten zu MySql, MS-SQL; zu Oracle äußert sich vermutlich Julius-m. -- Juetho 11:48, 23. Nov. 2009 (CET)