Frage zu einer Abfrage

[fran]

Hallo,

also ich schreibe da gerade eine Datenbankanwendung und dabei könnte ich mal einen Tipp gebrauchen (wenn es denn keine Umstände macht)

Also ich habe 3 Tabellen
- Kundendaten (KundenNr, Name usw.)
- Artikel (ArtikelNr, Bezeichnung, Preis, Datum usw.)
- bestellte_Artikel (ArtikelNr, KundenNr)

bei meinen Artikeln handelt es sich übrigens um Essen einer Mensa, die nur an einem bestimmten Tag verfügbar sind, deshalb auch das Datum bei Artikel.

Da diese Essen bezuschusst werden, darf pro Person und Tag nur ein Essen bestellt werden.

Nun wollte ich eine Abfrage machen, die alle für einen bestimmten Tag verfügbaren Essen anzeigt, was ja kein Problem ist. Das Problem ist, das ich in einer zusätzlichen Spalte noch anzeigen möchte ob der gerade eingeloggte Kunde (KundenNr also bekannt) für den Tag schon bestellt hat oder nicht.

Das ist nämlich wichtig, wenn dann da ein Ja (bzw 1) stünde, würde der Bestellbutton für den Tag deaktiviert und bei Nein (bzw 0) würden dann die Essensdaten angezeigt werden.

Ich habe es bereits mit count probiert, aber entweder zählt der die Essen, die alle bestellt haben oder er zählt nur die von der betroffenen Person, zeigt dann aber nicht alle Essen an.

Ich könnte natürlich 2 Abfragen machen, aber das wurmt mich das, das nicht in einer geht oder vielleicht doch?

Vielen Dank für eure Hilfe schon mal im voraus

Fran

[alzaimar]

Du kannst Dir doch anschauen, wann der Kunde zuletzt etwas gegessen hat. Das wäre dann das höchste (MAX) Datum des Artikels, der dem Kunden zugeordnet ist...

Reicht das als Denkanstoss?

[fran]

Zitat von alzaimar:

Du kannst Dir doch anschauen, wann der Kunde zuletzt etwas gegessen hat. Das wäre dann das höchste (MAX) Datum des Artikels, der dem Kunden zugeordnet ist...

Reicht das als Denkanstoss?

Das geht nicht, da der Kunde sein Essen bis zu zwei Wochen im voraus ordern kann. Dann würde ich nur das späteste Essen, das er bestellt hat erhalten. Und mit MIN das erste das er je bestellt hat.

[alzaimar]

In Artikel.Datum steht, ob und wann der Artikel verfügbar ist.
In bestellte_Artikel steht, das ein Kunde einen bestimmten Artikel bestellt hat.
Wenn ich das richtig verstanden habe, überschreibst Du Artikel.Datum jedesmal, wenn ein Essen wieder verfügbar ist. Na, das würd ich aber anders lösen, aber egal.

SQL-Code:

Select Artikel.Datum 
from bestellte_artikel 
join Artikel on bestellte_artikel.artikelnr = Artikel.Artikelnr 
where bestellte_artikel.KundenNr = MyKundenNr
  and Artikel.Datum between :Heute and :HeuteKurzVorMitternacht

Allgemein sollten 'Stammdaten', also Kunden und Artikel, einmal angelegt, nicht mehr verändert werden (Gebot der Rückverfolgbarkeit).
Wenn Du die 'Verfügbarkeit' eines Artikels ausdrücken willst, dann solltest Du das auch in einer entsprechenden Tabelle darstellen. Was ist, wenn es Montags und Freitags Kartoffeln mit Rindsbraten gibt? Legst Du dann zwei Datensätze an?

Es ist sehr ungünstig, die Kunden- und Artikelnummer als PK zu defnieren, denn wenn irgendwann irgendjemand die Artikel anders nummerieren will (was eigentlich immer irgendwann passiert), siehst Du in die Röhre...

Normalerweise legt man eine interne ID (int, als AutoInc), die Artikelnr (char oder varchar) und die Ausprägung, also Beschreibung an. Gleiches für Kunden. Dann noch eine Tabelle 'Verfügbarkeit' mit zwei Spalten ('ArtikelID' und 'Datum'). Somit kannst Du auch in die Vergangenheit gucken.
Was bestellt der Kunde? Einen Artikel? Oder nicht doch eher einen Artikel für einen bestimmten Tag, also eine Verfügbarkeit? Dann solltest Du die Tabelle 'Verfügbarkeit' noch um eine ID-Spalte (int, Autoinc) erweitern.

Die Tabelle bestellte_Artikel besteht dann aus der ArtikelID und der VerfügbarkeitsID.

Die 3.Normalform ist durchgezogen, alle sind zufrieden und dein DB-Design ist robust gegen Änderungen und Erweiterungen.

[fran]

Zitat von alzaimar:

In Artikel.Datum steht, ob und wann der Artikel verfügbar ist.

Nein da steht nur für welchen Tag der verfügbar ist.

Zitat:

In bestellte_Artikel steht, das ein Kunde einen bestimmten Artikel bestellt hat.
Wenn ich das richtig verstanden habe, überschreibst Du Artikel.Datum jedesmal, wenn ein Essen wieder verfügbar ist. Na, das würd ich aber anders lösen, aber egal.

Nein da wird nichts überschrieben. Wenn es ein Gericht jeden Tag gibt, dann gibt es da auch für jeden Tag, wo es das Gericht gibt einen extra Datensatz. Nur mit einer anderen ID.

Zitat:

Allgemein sollten 'Stammdaten', also Kunden und Artikel, einmal angelegt, nicht mehr verändert werden (Gebot der Rückverfolgbarkeit).
Wenn Du die 'Verfügbarkeit' eines Artikels ausdrücken willst, dann solltest Du das auch in einer entsprechenden Tabelle darstellen. Was ist, wenn es Montags und Freitags Kartoffeln mit Rindsbraten gibt? Legst Du dann zwei Datensätze an?

Es ist sehr ungünstig, die Kunden- und Artikelnummer als PK zu defnieren, denn wenn irgendwann irgendjemand die Artikel anders nummerieren will (was eigentlich immer irgendwann passiert), siehst Du in die Röhre...Normalerweise legt man eine interne ID (int, als AutoInc), die Artikelnr (char oder varchar) und die Ausprägung, also Beschreibung an. Gleiches für Kunden. Dann noch eine Tabelle 'Verfügbarkeit' mit zwei Spalten ('ArtikelID' und 'Datum'). Somit kannst Du auch in die Vergangenheit gucken.

Selbstverständlich gibt eine ID für die Artikel, die automatisch eröht wird, die wird gleichzeitig als ArtikelID verwendet. Das hatte ich nur nicht erwähnt, da ich es für die Abfrage als eher unwichtig betrachtet habe. Diese ID ist bei mir auch der PK. Da die Artikelnummer eigentlich nur intern Verwendung findet, sehe ich da keinen Grund warum die jemand umnummerieren sollte.

Da ich nicht erwähnt habe was der PK ist, wie kommst du zu deinen Annahmen? Bei den Kunden ist die Kundennummer eine eindeutige und nur einmal vorkommende und von der Datenbank generierte Integerzahl. Also gibts da auch keine Probleme mit doppelten Datensätzen oder Ähnlichem. Bei den bestellten_Artikeln ist der PK die KundenNr und ArtikelNr, was auch eindeutig ist.

Zitat:

Was bestellt der Kunde? Einen Artikel? Oder nicht doch eher einen Artikel für einen bestimmten Tag, also eine Verfügbarkeit? Dann solltest Du die Tabelle 'Verfügbarkeit' noch um eine ID-Spalte (int, Autoinc) erweitern.

Die Tabelle bestellte_Artikel besteht dann aus der ArtikelID und der VerfügbarkeitsID.

Die 3.Normalform ist durchgezogen, alle sind zufrieden und dein DB-Design ist robust gegen Änderungen und Erweiterungen.

Also der Kunde kann den Tag für den er bestellen will, auswählen. Es wird ihm dann eine Liste aller für den Tag verfügbaren Gerichte angezeigt. Von diesem darf er sich dann maximal eines auswählen.

Und damit er nicht mehr als eines pro Tag bestellen kann, wollte ich aus Performence Gründen die Abfrage der für den gewünschten Tag verfügbaren Essen mit der Abfrage, ob er für den Tag schon bestellt hat verknüpfen.

[marabu]

Hallo fran,

so ähnlich könnte ich mir das vorstellen:

SQL-Code:

SELECT a.bezeichnung, a.preis, IF(b.kundennr, 'mahlzeit', '...')
FROM artikel a
LEFT OUTER JOIN bestellungen b ON a.artikelnr = b.artikelnr
WHERE a.datum = :date
  AND b.kundennr = :kunde

Und zu deiner Tabelle Artikel noch etwas:

Zitat:

Wenn es ein Gericht jeden Tag gibt, dann gibt es da auch für jeden Tag, wo es das Gericht gibt einen extra Datensatz. Nur mit einer anderen ID.

Wenn das eine base table ist, dann ist die nicht ordentlich normalisiert - darauf wollte alzaimar dich zu Recht hinweisen.

Grüße vom marabu

[alzaimar]

Tach nochmal

ArtikelNr und KundenNr sind Indizien für sprechende Nummern ('Nr'), daher mein Exkurs in die 3.Normalform und die Annahme, das die Nummern sprechend sind, also keine IDs. Ein Grund mehr, Nomenklaturen zu verwenden, also z.B. 'ID', 'Nr', etc. Dessenungeachtet ist eine Tabelle 'Verfügbarkeit' einfach die bessere Wahl, schon allein aufgrund der Vermeidung von doppelten Artikelbeschreibungen, aber es ist ja Dein Code.

marabu liefert Dir eine Liste aller verfügbaren Artikel zu diesem Tag und ein 'mahlzeit', wenn dieser Artikel vom Kunden schon ausgewählt wurde, das sollte reichen.

[tomsel]

Noch'n Vorschlag:

falls dich die 'Mahlzeit' stört, könntest Du ja mit not exists arbeiten, das macht die Query zwar etwas langsamer, aber wenn dein Server ordentlich auf Zack ist, macht das fast nix. Also: Finde alle Artikel, zu denen keine Bestellung des aktuellen Kunden existiert:

select * from artikel a where a.Datum = :Datum and not exists(select * from bestellte_artikel b where b.ArtikelNr = a.ArtikelNr and b.KundenNr = :Kunde) Servus

[fran]

Zitat von marabu:

SQL-Code:

SELECT a.bezeichnung, a.preis, IF(b.kundennr, 'mahlzeit', '...')
FROM artikel a
LEFT OUTER JOIN bestellungen b ON a.artikelnr = b.artikelnr
WHERE a.datum = :date
  AND b.kundennr = :kunde

Ich habe das jetzt mal ausprobiert, das liefert mir entweder nichts zurück falls für den Tag keine Bestellung vorliegt oder es liefert die Essen die bestellt wurden.

Zitat von tomsel:

Noch'n Vorschlag:

falls dich die 'Mahlzeit' stört, könntest Du ja mit not exists arbeiten, das macht die Query zwar etwas langsamer, aber wenn dein Server ordentlich auf Zack ist, macht das fast nix. Also: Finde alle Artikel, zu denen keine Bestellung des aktuellen Kunden existiert:

SQL-Code: markieren
select * from artikel a where a.Datum = atum and not exists(select * from bestellte_artikel b where b.ArtikelNr = a.ArtikelNr and b.KundenNr = :Kunde)

Servus

Ähm ich glaube du hast mich da missverstanden, deshalb werde ich es noch mal genauer erklären. Pro Tag gibt es sagen wir mal 4 Essen, von denen sich jeder Kunde maximal 1 aussuchen darf. Und die Abfrage soll alle 4 Essen auflisten und in einer zusätzlichen Spalte dann ausgeben, ob der gerade eingeloggte Kunde dieses Essen bestellt hat oder nicht.

Z.B.
Essen1 ja
Essen2 nein
Essen3 nein
Essen4 nein

In diesem Beispiel steht Essen für alle Daten zum jeweiligen Essen wie Bezeichnung Preis usw.


Danke noch mal für eure Mühen

Fran

[marabu]

Der Kunde muss natürlich innen selektiert werden - darf ich nochmal nachbessern?

SQL-Code:

SELECT a.bezeichnung, a.preis, IF(b.kundennr, 'ja', 'nein')
FROM artikel a
LEFT OUTER JOIN (
  SELECT * FROM bestellungen WHERE kundennr = :kunde
) AS b ON a.artikelnr = b.artikelnr
WHERE a.datum = :date

Grüße vom marabu