Zum Inhalt
wannacode

Der Shop

Kurz gesagt: Die Übungsdatenbank des Kurses ist ein Online-Shop mit sechs Tabellen, in dem jede Bestellposition auf ein Produkt und jede Bestellung auf einen Kunden verweist.

Problem

Wer hat was bestellt?

Die Inhaberin des Shops fragt: „Was war in der letzten Bestellung, und wem gehörte sie?“

In Excel gäbe es eine Zeile mit allem. In der Datenbank ist die Antwort auf drei Tabellen verteilt. Das klingt nach einer Komplikation, ist aber genau das Gegenteil. Sehen wir, warum.

Die Idee

Sechs Tabellen

Der Shop hat sechs Tabellen. Jede ist für eine Art von Dingen da:

customers

  • PKidinteger
  • nametext *
  • emailtext *
  • citytext
  • joined_attext *

categories

  • PKidinteger
  • nametext *
  • FKparent_idinteger→ categories

products

  • PKidinteger
  • nametext *
  • FKcategory_idinteger→ categories
  • pricereal *
  • stockinteger *
  • added_attext *

orders

  • PKidinteger
  • FKcustomer_idinteger *→ customers
  • ordered_attext *
  • statustext *

order_items

  • PKorder_idinteger→ orders
  • PKproduct_idinteger→ products
  • quantityinteger *
  • unit_pricereal *

reviews

  • PKidinteger
  • FKproduct_idinteger *→ products
  • FKcustomer_idinteger *→ customers
  • ratinginteger *
  • bodytext
  • created_attext *
  • customers: die Kunden. categories: die Kategorien der Produkte. products: die Produkte, mit Preis in Euro und Lagerbestand.
  • orders: die Bestellungen. Eine Bestellung gehört einem Kunden, hat ein Datum und einen Status: new, paid, shipped, delivered oder cancelled.
  • order_items: was in jeder Bestellung steckt. Eine Zeile ist ein Produkt in einer Bestellung.
  • reviews: die Bewertungen, mit einer Note von 1 bis 5.

PK ist die Spalte, an der man eine Zeile erkennt: die Zahl id. FK ist eine Spalte, die auf eine Zeile in einer anderen Tabelle verweist. Das Sternchen heißt, dass die Spalte nicht leer sein darf.

Genauer, für Neugierige

Preise sind REAL, also Dezimalzahlen. Datumsangaben sind Text in der Form 2026-10-19: SQLite hat keinen eigenen Datentyp für Datum, und in dieser Form wird der Text richtig sortiert. In PostgreSQL und MySQL gibt es die Typen DATE und NUMERIC, und dort nimmt man diese. Auf die Typen kommen wir zurück, wenn wir eigene Tabellen bauen.

Sieh es dir an

Die letzte Bestellung, Zeile für Zeile

Die letzte Bestellung ist die 60. In orders hat sie customer_id 1. Kunde 1 in customers ist Maria Ivanova.

Was hat sie bestellt? Die Zeilen von Bestellung 60 stehen in order_items. Führe die Tabelle aus und scrolle ans Ende:

SQLDatenbank: Shop

Die letzten beiden Zeilen gehören zu Bestellung 60: Produkt 1, 2 Stück zu je 1,20 €, und Produkt 19, 4 Stück zu je 2,90 €. Sieh jetzt nach, welche Produkte 1 und 19 sind:

SQLDatenbank: Shop

Weißbrot und Spülmittel. Die Antwort wurde aus drei Tabellen zusammengesetzt, und jede Tatsache ist nur einmal gespeichert: Marias Name, der Name des Brots, sein Preis.

Genauer, für Neugierige

152 Zeilen mit den Augen zu durchsuchen ist langsam und fehleranfällig. Im nächsten Modul sagst du der Datenbank „nur die Zeilen von Bestellung 60“, und später bringst du die drei Tabellen mit JOIN in einer Abfrage zusammen.

Probier es aus

Wessen Bewertung?

1. Bewertung 3 gehört zu Produkt 17. Welches Produkt ist das? (Führe oben die Produkte aus und suche die id 17.)

Übung

Die Bewertungen

Zeige alle Bewertungen (Tabelle reviews). Welche Bewertung hat die niedrigste Note, und für welches Produkt ist sie?

SQLDatenbank: Shop

Test

Teste dich

1. Wie oft steht der Name von Produkt 1, „Weißbrot“, in der Datenbank?
2. Warum speichert order_items den unit_price, statt den Preis aus products zu nehmen?
3. Bestellung 60 hat zwei Zeilen in order_items. Was bedeutet das?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·