• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Preisliste

Tronjer

Senior HTML'ler
Ich möchte eine Datenbank erstellen, in der Warenmenge, Produktname, Beschreibung und Preis hinterlegt sind und daraus eine Preisliste in HTML generieren. Mal angenommen, es würde sich um Obst handeln, dann sollte die Ausgabe etwa wie folgt aussehen:

Code:
Menge:   Name:    Beschreibung:         Preis:
1 kg     Äpfel    frisch und knackig    € 2,95
2 kg     Äpfel    frisch und knackig    € 4,95
.......
1 kg     Bananen  gelb und krumm        € 1,95
......

Bin nun am Überlegen, wie ich so etwas am besten aufbaue und dabei Redundanzen vermeide. Ich habe ca. 100 Produkte, mit jeweils 5 verschiedenen Warenmengen und da die Preise nicht linear skalieren, kann ich auch keinen Modifikator verwenden (also nicht: 2 kg == 1k * 1.5). Mein Gedanke war, zwei Tabellen anzulegen.




Ein Query auf die Warengruppe durchzuführen und das Array anschließend in einer Schleife auszugeben. Folgender Code sollte alle Produkte der Warengruppe 1 (Äpfel) anzeigen:

PHP:
function hole_datenbank($db)
{
    $abfrage = $db->query("SELECT waren.produktname, waren.beschreibung, preise.anzahl,
    preise.preis FROM waren JOIN preise ON waren.warengruppe = preise.warengruppe WHERE warengruppe = '1';")
    $daten = $abfrage->fetchAll();
    return $daten
}

HTML:
<table>
    <?php foreach ($daten as $produkt) { ?>
    <tr>
        <td><?php echo $produkt['anzahl'] ?></td>
        <td><?php echo $produkt['produktname'] ?></td>
        <td><?php echo $produkt['beschreibung'] ?></td>
        <td><?php echo $produkt['preis'] ?></td>
    </tr>
</table>

Ist das in Ordnung, oder sollte ich einen anderen Ansatz wählen? Ich habe bisher noch keine Abfrage über mehrere Tabellen durchgeführt.
 
Für eine saubere Struktur brauchst Du mindestens folgende Tabellen:

Artikelstamm
ArtikelId | Bezeichnung | Beschreibung | WarengruppeId

Warengruppe
WarengruppeId | Warengruppe

Verkaufsmenge
VerkaufsmengeId | ArtikelId | Menge | Preis

Dabei darf aber jeder Artikel nur zu 1 Warengruppe gehören. Falls das anders sein soll, brauchst Du noch eine Zuordnungstabelle Artikel-zu-Warengruppe. Es versteht sich, daß in Menge nur eine einzige Einheit gebraucht werden darf, sollte das nicht möglich sein, dann wirds etwas komplizierter. Für den Preis gilt analog dasselbe. Weiterhin solltest Du Dir Gedanken über die Artikelbezeichnungen machen. Um bei Deinem Beispiel zu bleiben: wenn es Äpfel nicht nur in 1 Sorte gibt sondern vielleicht Boskop, Golden Delicious und Gravensteiner, dann sollte es eine Vorratstabelle für die Bezeichnungen geben und eine Spalte im Artikelstamm für die Sorte.
 
Für eine saubere Struktur brauchst Du mindestens folgende Tabellen:

Hmm, das ist für mich nicht evident. In meinem Beispiel mit zwei Tabellen ergeben sich Redundanzen in der Artikelmenge. Wenn ich das nun über drei Tabellen splitte und trotzdem Menge und Preis in einer zusammenfasse, wie sollte die Abfrage aussehen und warum wäre das effizienter?

Es gibt nur eine Sorte Äpfel, und das mit dem Obst war eh nur ein Beispiel.
 
Es gibt ein grundlegendes Konzept bei relationalen Datenbanken, die Normalisierung. Und es gibt ein Riesen-Mißverständnis bei manchen Leuten: viele Tabellen sind schwerer zu verwalten als eine große Klumpatsch-ich-hau-hier-alles-rein-Tabelle.
Alles, was Du Dir an Arbeit und Denken beim Aufbau sparst, wirst Du nachher doppelt und dreifach bezahlen; wenn Dein Programm auf all' die Sachen aufpassen muß, die bei einer normalisierten Struktur von der DB gratis erledigt werden.
das mit dem Obst war eh nur ein Beispiel.
Dann schildere doch konkret worum es geht.
 
Dann schildere doch konkret worum es geht.

Ich will eine Website für eine kleine Druckerei erstellen. Kernstück ist eine Preisliste mit den einzelnen Positionen, nebst Bestellmöglichkeit für den Kunden. Es ist kein richtiges Warenwirtschaftssystem, weil die Artikel nicht eingekauft, sondern produziert und die Daten nicht mit der Buchhaltung gekoppelt werden. Ebensowenig brauche ich einen Warenkorb oder ein Billing-System. Die Artikel sollen nach Kategorien sortiert (siehe Bild 1) auf einzelnen Seiten ausgegeben werden, und beim Klick auf Bestellen öffnet sich ein HTML-Formular (Bild 2), welches die Artikelbschreibung übernimmt. Dort kann der Kunde seine Daten eingeben und gegebenenfalls PDF-Dateien uploaden. Genaugenommen geht es um vielleicht 30 Drucksachen in unterschiedlichen Auflagen und jeweils zwei verschiedenen Ausführungen. Das Beispiel mit den Äpfeln und Birnen sollte lediglich zur Vereinfachung dienen.

Bei der Realisierung dieser Aufgabe ergeben sich für mich folgende Problemstellungen:

1. Da Drucksachen keinen Einzelpreis haben, sondern nach Auflagen berechnet werden, kann ich den Gesamtpreis nicht aus der Bestellmenge errechnen. 1000 Visitenkarten kosten nicht zehnmal soviel wie 100.

2. Für die Datenbank benötige ich mindestens vier verschiedene Werte: Auflage, Artikelname, Ausführung und Preis. Soll ich dazu vier Tabellen erstellen, was würde ich in diesem Fall als Foreign Key verwenden, und wie müsste dann die Abfrage aussehen? Ich habe zwar ein grobe Vorstellung von n:m Beziehungen und Joins über Zwischentabellen, aber so etwas noch nie in der Praxis umgesetzt.

 
Nu, den ganzen Formularkrimskrams vergessen wir zuerst. Eine Datenstruktur ist 'ne rein logische Sache, wie die Daten weiterverarbeitet werden interessiert zunächst gar nicht.

Eine Drucksache hat: Bezeichnung, Papiersorte, Format, Farben Vorderseite, Farben Rückseite, Weiterverarbeitung, Verpackung

"Bezeichnung" kann nur aus einem vorher festgelegten Datenvorrat genommen werden: Visitenkarte, Briefbogen
"Papiersorte" kann nur aus einem vorher festgelegten Datenvorrat genommen werden: 80g Offset, 300g B'Druck
Für "Format" gilt hier das gleiche: DinA4, Scheckkartenformat, DinA6
"Farben" weiß ich nicht, kommt auf Eure Maschinen an: 4c-Euro, schwarz, 4c+Schmuck
"Weiterverarbeitung" weiß ich nicht, kommt auf Eure Maschinen an: stanzen, perforieren, rillen

Wenn Du auf die Vorratstabellen verzichtest wird früher oder später irgendwo "Brifbogen" in der DB stehen oder 5c-Euro, und dann soll ein Programm entscheiden was das denn sein soll?

Jede einzelne Ausprägung (Kombination von Eigenschaften) einer Drucksache bekommt eine eindeutige Id. Es gibt also z. B.
Postkarte - DinLang - 4c - 4c - 300g B'Druck
Postkarte - DinLang - 4c - schwarz - 300g B'Druck
Postkarte - A6 - 4c - 4c - 300g B'Druck
usw.

In einer weiteren Tabelle wird jetzt jede gewünschte Kombi aus Id - Auflage - Preis abgelegt.

Wenn du den Tabellenaufbau sehr sorgfältig machst, ist die Pflege sehr einfach. Du willst Laminierung anbieten? Du bekommst jetzt eine 5-Farben-Maschine? Postkarten jetzt auch mit einer Perfo in der Mitte? Schmuckschachteln für Privatbriefbogen?
Spiel's mal im Geiste durch, Du kannst das ergänzen ohne alles über den Haufen zu werfen, insbesondere, ohne am Programm rumzufummeln!
 
Zurück
Oben