Diskussion:Einführung in SQL: Downloads

Autoren der früheren Kapitel

In der ursprünglichen Konzeption gab es mehrere Kapitel mit SQL-Skripten als Ergänzung zu Tabellenstruktur der Beispieldatenbank sowie zu Änderung der Datenbankstruktur. Diese Skripte wurden ausgelagert auf eine Download-Seite. Dieses Kapitel enthält jetzt Erläuterungen zu dieser Download-Seite. In der folgenden Aufstellung werden die Bearbeiter der bisherigen Kapitel und Diskussionen aufgeführt.

Dieser Artikel basiert auf dem Artikel Einführung in SQL: Tabellenstruktur der Beispieldatenbank aus dem freien Projekt wikibooks und steht unter der GNU Lizenz für freie Dokumentation und der CC-by-sa 3.0. Gemäß den Lizenzbestimmungen ist hier die Liste der Autoren zum Exportzeitpunkt 17. Feb. 2011 16:30 (CET) wiedergegeben.

Benutzer

Ergänzung zu Tabellenstruktur der Beispieldatenbank Skript und Anleitung für Firebird Jürgen, Edits:20 Skript und Anleitung für MS-SQL Jürgen, Edits:6 Skittle, Edits:4 Skript und Anleitung für MySQL Jürgen, Edits:1 Skript und Anleitung für Oracle Jürgen, Edits:9 Mcflash, Edits:1 ThePacker, Edits:1 Diskussion zu Oracle mehrere Beiträge einer IP Jürgen, Edits:1 Skript und Anleitung für SQLite Jürgen, Edits:15 ThePacker, Edits:1 Ergänzung zu Änderung der Datenbankstruktur Skript für Spalten Jürgen, Edits:7 Skript für Constraints Jürgen, Edits:5 Diskussion dazu Bullet4myval, Edits:1 Jürgen, Edits:1 Skript für Indizes Jürgen, Edits:4 Skript für ForeignKeys Jürgen, Edits:4 Skript für Anpassung Jürgen, Edits:3 Skript für weitere Testdaten Jürgen, Edits:3 Gesamtzahl dieser Beiträge Jürgen, Edits:79 Skittle, Edits:4 ThePacker, Edits:2 Mcflash, Edits:1 Bullet4myval, Edits:1

IP-Adressen

IPs haben an den Artikeln nur ausnahmsweise mitgearbeitet, sie sind hier nicht angegeben.

Einen fertig ausgefüllten Textbaustein erstellt Duesentrieb's Contributor Tool auf dem Wikimedia Toolserver. Ist die Liste lang, ist es zweckmäßig, dafür eine neue Seite zu erstellen und von der Seite mit den importierten Inhalten darauf zu verweisen.

Create Database mit Oracle

Testlauf

mit folgenden untigen Änderungen unter Oracle 10 erfolgreich getestet. autoincrement entfernt beim Tabellen anlegen, dann manuell die ID zugefügt beim füllen der Tabellen, Datumsangaben bedurften der Definition. Die Frage ist dann ob die übungen dann generisch genug sind das sie auch mit Oracle SQL laufen oder auch geändert werden müssen. 141.39.13.5 15:32, 13. Dez. 2010 (CET)CA

(Quelltext wurde an dieser Stelle von 141.39.13.5 eingetragen; aufgrund der nachfolgenden Diskussion steht das Skript jetzt unter CreateScript-Oracle11.sql.)

Eingetragen von 141.39.13.5 13:40, 10. Dez. 2010 (CET) Signatur nachgetragen von Jürgen 13:57, 13. Dez. 2010 (CET)

Ich nähere mich schritt für schritt mit erfahrenen Kollegen: Schau mal hier rein für die Datum und Sequenz Problematik: Diskussion:Einführung_in_SQL: DML (2) - Daten speichern#Anpassung für Oracle -- 141.39.13.5 11:42, 14. Dez. 2010 (CET)CA

Diskussion dazu

Ich habe mir jetzt die Zeit genommen, um deine Überarbeitung zu prüfen und zu übernehmen. Ich danke dir vielmals für den Test und die Realisierung.

Mir sind aber folgende Punkte unklar:

• Warum entfernst du den automatischen Zähler? Laut Oracle-Dokumentation ist er durchaus bekannt; anders als üblich schreibt er sich bei Oracle anscheinend mit Leerzeichen statt Unterstrich: AUTO INCREMENT.
• Ersatzweise könnte auch mit SEQUENCE gearbeitet werden. Warum benutzt du das nicht?

Bei dieser Mini-Beispieldatenbank kann man einen Zähler natürlich auch manuell zuweisen. Aber der richtige Weg ist doch die Automatik. Deshalb möchte ich deine Lösung, die du [wie oben] veröffentlicht hast, nicht übernehmen, sondern bitte dich, einen der automatischen Wege zu verwenden.

Ich werde das bisherige Skript ändern. Wenn dir weitere Änderungen auffallen, darfst du sie gerne selbst einbauen.

Ich hoffe, dass dich dieser Text überhaupt erreicht. Leider hattest du dich nicht mit Namen angemeldet; so ist eine Kontaktaufnahme und Diskussion sehr erschwert. Vielleicht liest du diesen Hinweis dennoch.

Danke jedenfalls nochmals für die Mitarbeit! Jürgen 13:51, 13. Dez. 2010 (CET)

Nachtrag:

• Ist denn die Anmeldung bei der Datenbank für Oracle richtig beschrieben, oder wie sollte es besser/genauer/richtiger formuliert werden?
• Was meinst du mit "Datumsangaben bedurften der Definition"? Jedes Datum ist doch als DATE definiert, und das ist ein zulässiger Datentyp. Allenfalls kann es um die Schreibweise eines Literals gehen. Die von mir verwendete Schreibweise 'yyyy-mm-dd' ist Standard gemäß SQL-92 und wird von Oracle direkt unterstützt.
• Beiträge auf Diskussionsseiten sollten mit 4 Tilden ~~~~ unterschrieben werden, damit vor allem Antworten.

Gruß Jürgen 14:08, 13. Dez. 2010 (CET)

Der aut. Zähler funktioniert leider bei mir auch so nicht, in der KurzReferenz kann ich dazu auch nichts finden, da ich aber Anfänger bin ist nicht auszuschließen das es doch geht und nur die Syntax noch falsch ist.

Mit der Erkennung des Literals zum Datum hatte ich probleme daher die Variante. Mittendrin fehlten auch noch einzelne Klammern.

141.39.13.5 15:32, 13. Dez. 2010 (CET)CA

Auch wenn du Anfänger bist, hast du mehr Kenntnisse als ich, weil ich mich mit Oracle nur über die Online-Dokumentation (siehe den o.g. Link) und das Oracle-Buch befasst habe. Die Dokumentation hilft natürlich nur begrenzt wegen der vielen Oracle-Versionen.

Kannst du sagen, wo Klammern fehlten, bzw. dies gleich ändern? Durch "scharfes Hinschauen" habe ich nichts gefunden.

Gibt es zu einer Datumsangabe eine richtige Fehlermeldung? Dann kann ich vielleicht im Text noch etwas dazu sagen. Bisher steht auf Einführung in SQL: Tabellenstruktur der Beispieldatenbank nur dieser Hinweis:

Hinweis: Datumsangaben werden in den Skripts durch '2009-12-14' nach ISO 8601 angegeben. Dieses Format sollte jedes DBMS in jeder Sprache richtig verarbeiten können.

Danke für die Unterstützung! Jürgen 15:58, 13. Dez. 2010 (CET)

Ich habe das Datenbank-Skript jetzt geändert:

• AUTO_INCREMENT entfernt
• SEQUENCE definiert (getrennt nach Tabellen) - der Anfangswert für die Zuordnungstabelle muss noch angepasst werden; denn hier werden einzelne Werte gezielt zugewiesen
• TRIGGER definiert
• DATE bei den Datumsangaben hinzugefügt

Erläuterungen siehe Diskussion zu DML (2). Jetzt fehlt noch ein erneuter Test. -- Jürgen 17:13, 15. Jan. 2011 (CET)

Skript-Constraints führt zu Fehlern

Dieser Punkt stand vorher unter "Diskussion:Einführung in SQL: Skript-Constraints"; durch die Auslagerung in die Download-Seite habe ich es hierher verschoben. Jürgen

Hallo zusammen, ich weiß nicht, ob ich was übersehen habe, aber bei der Erstellung der Tabelle Versicherungsvertrag wird bei den anschließeneden INSERT Befehlen 3 Mal die Versicherungsnummer 'DG-01' verwendet. Aufgrund dessen, kann doch ein UNIQUE CONSTRAINT auf diese Spalte nie erstellt werden?! Es gibt diese Fehlermeldung:

CONSTRAINT Versicherungsvertrag_Nummer UNIQUE (Vertragsnummer) auf nicht UNIQUE Spalte Vertragsnummer

MfG Bullet 18:07, 2. Feb. 2011

Nein, du hast recht. Das muss DG-01/02/03 heißen. Vor kurzem war mir das aufgefallen, aber weil ich mich noch mit anderen Punkten befasst habe, habe ich es nicht sofort (oder nicht überall) erledigt. Damit es mir nicht nochmals durch die Lappen geht, werde ich es gleich nachholen. (Hoffentlich vergesse ich keine Stelle.) -- Jürgen 18:54, 2. Feb. 2011 (CET)

SQLite-Skript: Falsche Zeichencodierung (encoding)

Das SQLite-Skript sollte als Encoding UTF-8 statt Latin1 verwenden - dann werden auch Strings wie "Müller" in der Mitarbeitertabelle richtig gespeichert/ausgegeben:

Unter Verwendung der Originaldatei (CreateScript-SQLite.sql):

$ sqlite3 -init CreateScript-SQLite.sql db.sqlite "SELECT Name FROM Mitarbeiter WHERE Name LIKE 'M%';"
-- Loading resources from CreateScript-SQLite.sql

M�ller
Meyer

Mit angepasster Datei (in Vim Encoding zu UTF-8 geändert; CreateScript-SQLite_mod_utf8.sql):

$ sqlite3 -init CreateScript-SQLite_mod_utf8.sql db_utf8.sqlite "SELECT Name FROM Mitarbeiter WHERE Name LIKE 'M%';"
-- Loading resources from CreateScript-SQLite_mod_utf8.sql

Müller
Meyer

(Getestet in Konsole 2.10.5 (Kubuntu 13.04) mit LANG=de_DE.UTF-8 und mit SQLite Manager 0.8.1 (mit den in der Shell erzeugten Datenbanken).) -- 79.241.87.242 22:56, 10. Okt. 2013 (CEST)

Das ist ein sehr nützlicher Hinweis. Da ich selbst nie mit SQLite (und auch nicht mit Linux) gearbeitet habe, konnte ich nur "fremde Anleitungen" übernehmen. Deshalb bitte ich dich um genauere Informationen:

• Was genau ist im Skript zu ändern? Nach deiner Beschreibung vermute ich, dass an den Anfang ein SET oder LANG o.ä. gehört, aber ohne detaillierten Hinweis kann ich den Quelltext nicht ändern und hochladen.
• Verstehe ich es richtig, dass bei deinem Code die Datenbank-Datei als db_utf8.sqlite benannt wird, was bei mir Beispieldatenbank.db heißt (also nur ein anderer Name, keine weitere Einstellung)?
• Sehe ich es richtig, dass der LANG-Parameter in deinem Hinweis "getestet in" zu den Einstellungen des SQLite-Managers gehört (nicht zu KDE)? Wo und wie sollte darauf im Abschnitt SQLite hingewiesen werden?

Danke jedenfalls für deine Aufmerksamkeit! -- Gruß Jürgen 09:57, 12. Okt. 2013 (CEST)

• Es sollte reichen, das Skript in einem guten Texteditor zu öffnen und mit der Zeichencodierung/dem Zeichensatz/... "UTF-8" (ohne BOM) zu speichern bzw. die Datei in diese Zeichencodierung umzuwandeln und dann zu speichern (sollte wohl z.B. mit Notepad++ gehen; Windows-Notepad fügt standardmäßig ein BOM ein). Man kann die Zeichencodierung zwar auch im Skript angeben ("PRAGMA encoding = ..."), so wie es aussieht aber nur Codierungen für Unicode (UTF-8/UTF-16), kein ISO 8859-1 (was für das Skript momentan ja notwendig wäre). Intern wird von SQLite UTF-8/UTF-16 verwendet. Im SQLiteManager ist es möglich, die Zeichencodierung beim Import auszuwählen (einschließlich ISO 8859-1), beim sqlite3-Werkzeug soweit ich weiß nicht (habe nichts gefunden) - d.h. es wäre vermutlich sinnvoll, tatsächlich die Zeichencodierung des Skripts anzupassen (eigentlich alleine schon wegen der Vorteile von Unicode/UTF-8 gegenüber ISO 8859-1 etc.).

• Zur Benennung: ja - db_utf8.sqlite ist nur ein anderer Name.

• LANG ist eine Umgebungsvariable und bezieht sich (hier) auf die Konsole und war vor allem zum Debuggen/Nachvollziehen/"Beweisen" gedacht. -- 79.241.67.17 01:28, 15. Okt. 2013 (CEST)

SQLite-Skript: Verwendung einer expliziten Transaktion

Spricht etwas dagegen, für das Erstellen der Tabellen und Einfügen der Daten eine explizite Transaktion zu verwenden? Ein mit sqlite3 erstellter Dump enthält BEGIN TRANSACTION und COMMIT (s.u.); das Erstellen der Datenbank aus diesem Dump dauert (hier) ca. 0,2 Sekunden, mit der Original-Skript-Datei (CreateScript-SQLite.sql) ca. 15 Sekunden (mit starker Festplattenaktivität).

Die SQLite-Dokumentation hierzu: "(19) INSERT is really slow - I can only do few dozen INSERTs per second [...] By default, each INSERT statement is its own transaction. But if you surround multiple INSERT statements with BEGIN...COMMIT then all the inserts are grouped into a single transaction. The time needed to commit the transaction is amortized over all the enclosed insert statements and so the time per insert statement is greatly reduced."

Mit sqlite3 erstellter Dump der aus CreateScript-SQLite.sql erstellten Datenbank:

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE Versicherungsvertrag
    (ID                     INTEGER     NOT NULL,
     Vertragsnummer         VARCHAR(20) NOT NULL,
-- [...]
INSERT INTO "Fahrzeughersteller" VALUES(10,'Renault','Frankreich');
INSERT INTO "Fahrzeughersteller" VALUES(11,'Seat',NULL);
COMMIT;

- 03:28, 15. Okt. 2013 (CEST)

SQL-Skript für MySQL

eingefügt von 176.198.220.18 10:12, 12. Sep. 2019 (CEST)

Danke vielmals! -- Jürgen 11:04, 12. Sep. 2019 (CEST)

(Quelltext wurde ursprünglich von 176.198.220.18 hier eingetragen. Er steht jetzt als eigenständige Seite unter CreateScript-MySQL5.sql.)

Downloads zu vs-polis.de wieder ausgelagert

Nachdem die Homepage von Jürgen Ende 2018 abgeschaltet wurde, steht die Download-Seite „nur noch“ über ein Web-Archiv zur Verfügung. Für den Fall, dass diese Archiv-Seite verschwindet, werden alle Skripte in eigene Unterseiten ausgelagert und die Beschreibung angepasst:

• Die zip-Dateien für die vollständige fertige Beispieldatenbank stehen (in drei Versionen) nur über das Web-Archiv zur Verfügung.
• Die sql-Skripte zur Erstellung der Beispieldatenbank stehen in mehreren Versionen als Unterseiten zur Verfügung.
• Ebenso gibt es die sql-Skripte zur Änderung der Beispieldatenbank in mehreren Einzeldateien.

Das hat den angenehmen Nebeneffekt, dass auch die Skripte auf dieser Diskussionsseite in das Buch übernommen werden können. -- Jürgen 15:36, 28. Dez. 2020 (CET)