Diskussion:Einführung in SQL

Aus Wikibooks

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

[Bearbeiten] 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.
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)

[Bearbeiten] 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)

[Bearbeiten] 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 http://de.wikibooks.org/wiki/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)

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)

[Bearbeiten] 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)

[Bearbeiten] Artikel SQL: Befehle

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)
Von „http://de.wikibooks.org/wiki/Diskussion:Einf%C3%BChrung_in_SQL“
Persönliche Werkzeuge
Buch erstellen
  • Artikel hinzufügen
  • Hilfe zu Sammlungen