✔ SQL fragen

L

latinum_1982

Erfahrenes Mitglied
Hallo leute

da ich mich mitlerweile ein bischen mehr mit php auskenne versuch ich einigesin verbindung mit SQL aber teils klappts und keils muss ich mich herumspielen bis ich es raus hab :)
aber meine frage is ..
ich hab ein kunden login erstellet und darunter angebote , momentane auftrage , etc gemacht

jetzt ich ich es so das alle angotobe verkürzt in einer liste zu sehen und habe details mit php zu angebotsdetails verlinkt jetzt ist meine frage
die muss ich die SQL anlegen wenn der kunde die bestellung aufgibt das ich das in der SQL bei dir Auftraege hab und zusätztlich an mich per mail schickt
aber der kunde musste ein paar kontrol kästen anklicken wenn er mag zb. gibts bereits eine bestehende grafik (ja oder nein) und einge andere fragen

aus was muss ich bei der SQL erstellung achten wegen die kontroll kästchen sollten die dazu oder echer nicht

daweil schaut es so aus

PHP: 
CREATE TABLE IF NOT EXISTS `angebote` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` varchar(200) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `angebotsnummer` varchar(200) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `gultig` varchar(200) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `beschreibung` varchar(220) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `kurzbesch` varchar(220) COLLATE latin1_general_ci NOT NULL DEFAULT '', 
  `menge` varchar(220) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `produkt` varchar(220) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `liferzeit` varchar(220) COLLATE latin1_general_ci NOT NULL DEFAULT '', 
  `betrag` varchar(220) COLLATE latin1_general_ci NOT NULL DEFAULT '',
   
PRIMARY KEY (`id`),
  
UNIQUE KEY `angebotsnummer` (`angebotsnummer`)
)
 
Zuletzt bearbeitet:
Abgesehen davon, dass ich die Frage nun nicht genau verstehe.. Schau Dir das Thema Normalisierung nochmals an. In der Regel sollte es mehrere Tabellen geben, die abhängig von der Aufgabe eine Beziehung eingehen.

Es gibt mindestens
* eine Tabelle Kunden (daran hast Du ha scheinbar mit der user_id gedacht)
* eine Tabelle Produkt (wozu jedesmal das Produkt samt Infos/Preis etc vollständig eintragen?)
* eine Tabelle Angebot (die Vermischung aus Kunde und gewünschten Produkten)
* eine Tabelle Kauf (wenn ein Angebot zu einem Kauf führt)

Das ist jetzt sehr simpel beschrieben, jedenfalls drückt das die Normalisierung schon recht gut aus. Im Endeffekt besteht dann ein Angebot nur noch aus der user_id, den produkt_id's und dem Ausstellungsdatum. etc pp. Solch eine Tabelle macht auch umgedreht mehr Sinn, zB wenn die Frage lautet: "Wieviel Angebote habe ich dem Kunden XY geschrieben" (Suche in Tabelle Angebot alle Einträge mit user_id 123 raus) oder "Welches Produkt wurde am meisten gekauft" (Erstelle eine Liste aller Produkte, die in Kauf vorkommen, und summiere die Einzelvorkommen) Und so weiter und so fort...

http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

mfg chmee
 
Zuletzt bearbeitet:
Hallo danke für die antwort

ja ich hab eh die notwendigen tabellen

kunden
archiv
offeneauftrege
angebote

aber ich weiß nur nicht wie das das mit die angebote kauf machen soll..

sollt ich die daten dann zu offeneauftrege abspeichern?
 
Zuletzt bearbeitet:
Nee, Du musst das nochmal überarbeiten. Es scheint, als siehst Du die Tabellen wie Ordner an. Ein abgeschlossener Auftrag wandert ins Archiv und so.. Nee nee..

Sehen wir uns nur mal die Tabelle Auftrag an.. Sie sollte mindestens folgende Dinge beinhalten:

a_id (Auftragsnummer)
user_id (Kunde)
b_id (welcher Bearbeiter ist verantwortlich)

dateIn (Erstellungsdatum)
dateOut (Lieferdatum)
dateEndA (Zahlungsdatum Soll)
dateEndB (Zahlungsdatum Ist)

skonto (auftragsabhängiger Rabatt)
comment (Bemerkung)

Und? Da fehlt was, nicht wahr? Die Artikel.. Jene sollten für die Aufträge in eine eigene Tabelle gepackt werden und mit der AuftragsID versehen werden. Also könnte die Tabelle Posten heißen und sieht sehr viel einfacher aus, als man denkt.

posten_id (unique id)
a_id (AuftragsID für die Zuordnung)
artikel_id ( * )
menge ( * )
skonto (artikel und auftragsbezogener rabatt)

Nun solltest Du sehen, dass jene Artikel-Tabelle vonnöten sei, um sie in dieser Postentabelle nutzen zu können. Ein unabhängiger Artikelstamm also, auf den sich alle Angebote und Aufträge beziehen.

Du hast ja nach der Problematik Angebot/Auftrag gefragt. Ich denke, ich würds mit zwei Tabellen lösen, die fast gleich sind, nur dass die Angebote-Tabelle anstatt Lieferdatum usw eher noch Attribute wie ist_bearbeitet, wurde_zu_auftrag und bearbeiter_id haben sollte.

puuhhhh. Man könnte dazu soviel erzählen. Man könnte Unmengen an Tipps und Umsetzungsvarianten aufzeigen. Ich würde Dir empfehlen, irgendein Tutorial dazu durchzuarbeiten, für Hier ist es doch n bissel zuviel.. Microsoft gab (gibt?) zu seiner Datenbank Access das Northwind-Beispiel dazu. (Northwind als SQL?)

Links:
http://mysql.lernenhoch2.de/lernen/
http://www.strassenprogrammierer.de/mysql-komplexe-abfragen-mit-joins-meistern_tipp_429.html

mfg chmee
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück