Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Bei SQL muss man nun eher das Verständnis für relationale Datenbanken aufbauen. Übungen sind schön und gut, aber die Syntax von SQL ist jetzt nicht soooo das Problem für Leute mit Programmiererfahrung.
Hier fände ich ein Buch hilfreicher wie beim Programmieren lernen.
Tutorials mit solchen Mist sollten unbedingt ignoriert werden: SELECT *
FROM Tabelle1, Tabelle2
WHERE Tabelle1.SpalteX = Tabelle2.SpalteY
SELECT *
Nur zum testen, niemals im Echtbetrieb, weil es unnötig Ressourcenaufwendig ist alle Spalten auszugeben.
FROM Tabelle1, Tabelle2
Tabellen immer per (INNER/LEFT/RIGHT )JOIN verknüpfen, alles andere schränkt die Möglichkeiten ein und wird unübersichtlich.
WHERE Tabelle1.SpalteX = Tabelle2.SpalteY
JOIN-Bedingungen gehören NIEMALS ins WHERE, da unübersichtlich und ins INNER JOIN zwingt.
Korrekt wäre also
Code:
SELECT
Artikel.Nr AS ArtikelNr
,Artikel.Bez
,Auftrag.Datum
,Auftrag.Nr AS AuftragsNr
FROM Tabelle1
LEFT JOIN Tabelle2
ON Artikel.Id = Auftrag.ArtikelId
WHERE Artikel.Bez LIKE '%monitor%
AND Auftrag.Datum >= '01.10.2016'
Was heißt denn ein bisschen einfinden? Einfache Datenbanken konstruieren und Abfragen darauf ausführen hat man schnell raus. Würde fast sagen ein Buch ist Overkill. Gehts dir wirklich darum mit größen Mengen oder komplexen Datenbanken zu arbeiten kommen schnell verkettete Joins, Indizes, Trigger, Stored Functions usw. ins Spiel. Hier wäre ein ausführliches Buch evtl. hilfreich.
Ich habe SQL im MS-Office gelernt. Hier gibt es MS Access. Du kannst dir selbst Tabellen bauen und das Ergebnis von SQL-Abfragen einfach nachvollziehen. Wenn man MS-Office besitzt, ist das ein sehr einfacher Weg.
@Yxcv
Du schreibst man soll keine cross joins machen. Kannst du auch begründen weshalb?
Ich verwende das immer zum Jahresabschluss ala:
Select Table1.Year + '-' + Table2.Month from Table1,Table2
Somit erhält man nach Einfügen des neuen Jahres in Table1 immer alle 12 Perioden auf einen Streich (Table2 enthält 12 Monate).
Wie löst du so etwas?
Sieht irgendwie unsinnig aus. Woher weist du jetzt was in Tabelle2 zum Jahr aus Tabelle1 gehört? Oder war das nur ein Teil deines Statements? Vielleicht verstehe ich was falsch.^^
In welcher SQL Umgebung nutzt man der "+" Operator zum Zusammenfügen von Spalten. Kenne das sonst nur mittels CONCAT, "&" oder "||".
Er fügt keine Spalten zusammen, sondern verkettet strings (varchar oder was auch immer). Das funktioniert einwandfrei z.B. in Access und MS SQL Server.
Meinte ich damit ja auch. Glaube aber inzwischen sollte man auch unter MS SQL (<2012) auch eher concat verwenden. Es sei denn man will explizit Null als Rückgabe, sobald ein Wert Null ist. Aber Danke für die Rückmeldung.
Meinte ich damit ja auch. Glaube aber inzwischen sollte man auch unter MS SQL (<2012) auch eher concat verwenden. Es sei denn man will explizit Null als Rückgabe, sobald ein Wert Null ist. Aber Danke für die Rückmeldung.
Folgende Zielstellung:
Zum Jahresabschluss - der nicht kalendarisch sondern über das Programm gesteuert wird - benötige ich 12 neue Perioden: 2017-01 bis 2017-12
Ich habe 2 Tabellen: 1 für Jahre u. eine für Monate. Die für Monate hat immer 12 Werte. Die für Jahre wird am Jahresabschluss jeweils um das neue Jahr erhöht. Über einen cross join (zu deutsch Kreuzprodukt) erhalte ich dadurch, dass ich die Tabellen nicht im join aufführe 12 weitere Datensätze. Sehr elegant wie ich finde ...
Hmm, kann man vielleicht so machen aber weiß jetzt auch nicht was du unter Jahresabschluss verstehst. Lässt sich ohne Blick aufs Ganze schlecht sagen, obs elegant ist. Aber stimme dir natürlich zu, es gibt Fälle in denen ein Cross Join Sinn macht.
Ansonsten schrieb yxcv aber wie ich das sehe auch nicht explizit davon, cross join nicht zu nutzen, sondern davon die Bedingung eines (inner) join nicht über das where zu steuern. Damit trennt man die Werte über die verknüpft wird von den Werten die die Ergebnismenge eingrenzen. Dagegen ist grundsätzlich nichts auszusetzen.
Folgende Zielstellung:
Zum Jahresabschluss - der nicht kalendarisch sondern über das Programm gesteuert wird - benötige ich 12 neue Perioden: 2017-01 bis 2017-12
Ich habe 2 Tabellen: 1 für Jahre u. eine für Monate. Die für Monate hat immer 12 Werte. Die für Jahre wird am Jahresabschluss jeweils um das neue Jahr erhöht. Über einen cross join (zu deutsch Kreuzprodukt) erhalte ich dadurch, dass ich die Tabellen nicht im join aufführe 12 weitere Datensätze. Sehr elegant wie ich finde ...
In der Regel optimiert der Query Optimizer das weg. Das kann man sehr gut im Query Plan. Im professionellen Oracle Umfeld ist das Gang und Gäbe. Kenne kaum einen Oracler, der den Inner Join wirklich als Inner Join schreibt.
Folgende Zielstellung:
Zum Jahresabschluss - der nicht kalendarisch sondern über das Programm gesteuert wird - benötige ich 12 neue Perioden: 2017-01 bis 2017-12
Ich habe 2 Tabellen: 1 für Jahre u. eine für Monate. Die für Monate hat immer 12 Werte. Die für Jahre wird am Jahresabschluss jeweils um das neue Jahr erhöht. Über einen cross join (zu deutsch Kreuzprodukt) erhalte ich dadurch, dass ich die Tabellen nicht im join aufführe 12 weitere Datensätze. Sehr elegant wie ich finde ...
Üblicherweise wird dazu eine Zeit-Tabelle angelegt (siehe auch OLAP-Zeitdimension).
Viele DBMS generieren dies mit Bordmitteln. Falls deines nicht, gibt es haufenweise fertige Skripte zum download.
Drexel schrieb:
In der Regel optimiert der Query Optimizer das weg. Das kann man sehr gut im Query Plan. Im professionellen Oracle Umfeld ist das Gang und Gäbe. Kenne kaum einen Oracler, der den Inner Join wirklich als Inner Join schreibt.
Ersetze "professionellen Umfeld " durch "amateur Bereich" und es passt.
Optimizer sind dazu gedacht die letzten Prozente zu optimieren, nicht um generell Blödsinn auszubügeln.
Niemand mit echtem Know-how schreibt solchen unübersichtlichen Code. Völlig unabhängig von der verwendeten DB.
Einfache Datenbanken konstruieren und Abfragen darauf ausführen hat man schnell raus. Würde fast sagen ein Buch ist Overkill. Gehts dir wirklich darum mit größen Mengen oder komplexen Datenbanken zu arbeiten kommen schnell verkettete Joins, Indizes, Trigger, Stored Functions usw. ins Spiel. Hier wäre ein ausführliches Buch evtl. hilfreich.
