Drei Tabellen in eine einfügen und Duplikate vermeiden

Zu deutsch: So wie du das machen willst, geht es defintiv nicht, korrekt?
Gibt es eine Idee/Vorschlag/Hinweis wie ich das Problem anders irgendwie lösen könnte?
Das Ganze ist eine Übung für die FH die ich heute abgeben muss, wenn ich das Problem nicht irgendwie gelöst bekomme, kann ich die Abfragen (die nun eigentlich Ziel der Übung wären) nicht machen und das wäre ein wenig ungünstig.
Ich bin wie anfänglich schon erwähnt, wirklich für jede Hilfestellung dankbar und erwarte auch keinen fixfertig servierten Code, nur momentan komm ich irgendwie überhaupt nicht weiter.
 
Werbung:
Also ich denke ein kartesisches Produkt wie du eingangs beschreiben hast ergibt einfach keinen Sinn. Ich denke aber auch das es für die Übung nicht relevant ist ob man jetzt zu 10 Rechnungen individuelle Positionen (nichts anderes steht in dieser Tabelle ja drin, Produkte und Preis) hast oder zu 100. Das Prinzip ist das selbe, wichtig ist das man mit einem Select in der Lage ist die Beziehungen zu nutzen um die Rechnungspositionen auszugeben.

Natürlich könnte man sich theoretisch ein Script basteln das zufällige Daten erstellt. Die wären aber zunächst mal so zufüllig, das eine Rechnung 0 - 10 Artikel mit bis zu 10 Preisen also 0 bis zu 100 Positionen haben könnte. Sinnvoll erscheint mir das nicht.
 
Die 3000 Rechnungen mit jeweils 1 Rechnungszeile (also in dem Fall einem Warenkorb) sind leider Teil der Angabe, also kann ich sie nicht reduzieren.
Oder hab ich da jetzt was missverstanden?
 
Hallo Ahalya,

gib nicht auf! Wir helfen dir. Ich mache zwar jetzt Feierabend, aber ich werde mich dem zu Hause noch eninmal widmen.
Du wirst also heute noch einmal etwas ausführlicher von mir hören (das haste jetzt davon ;))


Viele Grüße,
Tommi
 
Hallo Ahalya,

ich habe mir noch einmal ein paar Gedanken gemacht. Wenn du nachher auch mit deinen Abfragen so wenig Probleme wie möglich haben willst, solltest du das DB-Schema tatsächlich ein wenig umstellen.
Ich habe mal als Beispiel ein Schema angehängt, wie ich es aufgebaut hätte (ab Tabelle Rechnung). Es unterscheidet sich auf den ersten Blick zwar nur wenig von deinem Entwurf, aber dieser Unterschied ist durchaus entscheidend.

Entscheidend ist, dass die Tabelle "Artikel" eine eigenständige Auflistung ist. Aus meiner Sicht stellt diese Tabelle Stamm-Daten (nämlich den Waren-Pool) dar.
Für jeden Artikel können ein oder mehrere Preise eingegeben werden, die zeitlich über das Gueltig_von und Gueltig_bis differenziert werden können.
Allgemein wird in solchen Tabelle nur das Gueltig_ab verwaltet, ich habe das Gueltig_bis aber vorgesehen, um nachher die Abfragen zu erleichtern.

Als nächstes würde ich hier fortfahre und dir eine Prozedur erklären, die dir das Füllen der Tabellen ermöglicht.
Dafür solltest du im Vorfeld aber entscheiden, welches DB-Schema du nun verwenden möchtest.

Viele Grüße,
Tommi
 

Anhänge

  • Schema Restaurant.jpg
    Schema Restaurant.jpg
    74,6 KB · Aufrufe: 3
Ist statt Rechnungsnummer, Rechnungs_ID so gedachte oder auch ein versehen? ;)

Aber ich versteh schon worauf du hinaus willst, wenn du mir vielleicht ein wenig helfen kannst würde ich es dann nach deinem Vorschlag umbauen.

Ach und übrigens, ich weiß nicht ob dus gesehen hast, ich hab auch eine View erstellt worüber ich dann eigentlich die Abfragen machen wollte :)
 
Aus meiner Sicht reicht hier die Rechnungs-ID, da ich hierüber auch direkt die Rechnungsnummer ermitteln kann.
 
Okay, dann schau ich mal ob ich das so hinkriege :)

Hab gerade gesehen, dass Rechnungsnummer die Rechnungs_ID ist *hüstel*
 
Deine View habe ich mir auch angesehen. In dieser werden aber nicht alle Beziehungen zwischen den Tabellen berücksichtigt.
Ich bevorzuge im Übrigen auch explizite JOINS zwischen den Tabellen. Durch die deutlichere Schreibweise sind die Beziehungen leichter nachzuverfolgen.

Ich gebe dir mal ein Beispiel zu dem von dir aufgebauten DB-Schema:

Code: 
SELECT R.Rechnungsnummer, R.Datum, R.Uhrzeit,
P.Nachname+', '+P.Vorname as Personal,
K.Nachname+', '+K.Vorname as Kunde,
A.Beschreibung,
PR.Preis as Einzelpreis,
W.Menge,
PR.Preis * W.Menge as Positionspreis,
FROM dbo.Rechnung R
INNER JOIN dbo.Personal P
     ON P.Personalnummer=R.Personalnummer
INNER JOIN dbo.Kunde K
     ON K.Kundennummer=R.Kundennummer
INNER JOIN dbo.Warenkorb W
     ON W.Rechnungsnummer = R.Rechnungsnummer
INNER JOIN dbo.Artikel A
     ON A.Artikel_ID=W.Artikel_ID
INNER JOIN dbo.Preis PR
     ON PR.Preis_ID=W.Preis_ID
 
Ohja, mein Feind der Join, ich hab es bisher ja irgendwie noch hingekriegt sie zum umgehen, weil ichs einfach nicht kapiere *hust*
Fürchterlich, ich bin gerade dabei die Datenbank an deinen Vorschlag anzupassen, dann schau ich mir die View nochmal an
 
Für meinen Vorschlag des DB-Designs muss natürlich die Abfrage dann wie folgt aussehen:

Code: 
 SELECT R.Rechnungsnummer, R.Datum, R.Uhrzeit,
P.Nachname+', '+P.Vorname as Personal,
K.Nachname+', '+K.Vorname as Kunde,
A.Beschreibung,
PR.Preis as Einzelpreis,
W.Menge,
PR.Preis * W.Menge as Positionspreis,
FROM dbo.Rechnung R
INNER JOIN dbo.Personal P
     ON P.Personalnummer=R.Personalnummer
INNER JOIN dbo.Kunde K
     ON K.Kundennummer=R.Kundennummer
INNER JOIN dbo.Warenkorb W
     ON W.Rechnungsnummer = R.Rechnungsnummer
INNER JOIN dbo.Artikel A
     ON A.Artikel_ID=W.Artikel_ID
INNER JOIN dbo.Preis PR
     ON PR.Artikel_ID=A.Artikel_ID
     AND R.Datum BETWEEN PR.Gueltig_von AND PR.Gueltig_bis

:)

JOINS sind wesentlich für SQL-Abfragen! Was verstehst du daran nicht?
 
Ich verstehe was sie tun sollen, aber ich versteh die Syntax absolut nicht. Das ist ein Buch mit sieben Siegeln für mich.
Alias ist klar, sogar wie du Vor- und Nachname zu einem String verbindest, aber bei JOINS komm ich nicht mehr mit.
Warum steht da immer P, R und so dahinter?

Ähm ... wo ist die Mehrwertsteuer hin? :)
 
Werbung:
Die Tabellen kannst du natürlich beliebig erweitern. Allerdings würde ich für die Mehrwertsteuer sogar eine eigene Tabelle führen, ebenfalls mit Spalten zur Abgrenzung des Gültigkeitszeitraums.
 
Zurück
Oben