14
Query - View - Hilfe benötigt
Hallo zusammen,
ich bin etwas in die PHP Programmierung (privat) eingestiegen und habe gerade etwas ein Problem mit dem erstellen einer Abfrage / View.
Eventuell denke ich auch gerade komplett falsch, weswegen ich kurz nachfragen wollte:
Folgende Tabellen sind vorhanden (ich werde diese verkürzt darstellen):
tAuftraege:
auftragsnr (PK)
kdnr
kontaktnr
titel
tAktivitaeten:
aktivnr (PK)
kdnr
auftragsnr
kontaktnr
datum
von
bis
summe
tMaterial
materialnr (PK)
kdnr
auftragsnr
aktivnr
artike
menge
summe
Nun möchte ich gerne eine Ausgabe Query oder View haben, welche alle Aktivitäten aus der Tabelle "tAktivitaten" und alle Materialen aus der Tabelle "tMaterial" anhand der Auftragsnr ausgegeben haben.
Also Beispiel:
Auftragsnr | kdnr | aktivnr | summeaktiv | materialnr | summematerial|
###
Ist dies überhaupt möglich?
Oder wird sowas generell anders besser umgesetzt?
Danke im Voraus.
Grüße
Phil
ich bin etwas in die PHP Programmierung (privat) eingestiegen und habe gerade etwas ein Problem mit dem erstellen einer Abfrage / View.
Eventuell denke ich auch gerade komplett falsch, weswegen ich kurz nachfragen wollte:
Folgende Tabellen sind vorhanden (ich werde diese verkürzt darstellen):
tAuftraege:
auftragsnr (PK)
kdnr
kontaktnr
titel
tAktivitaeten:
aktivnr (PK)
kdnr
auftragsnr
kontaktnr
datum
von
bis
summe
tMaterial
materialnr (PK)
kdnr
auftragsnr
aktivnr
artike
menge
summe
Nun möchte ich gerne eine Ausgabe Query oder View haben, welche alle Aktivitäten aus der Tabelle "tAktivitaten" und alle Materialen aus der Tabelle "tMaterial" anhand der Auftragsnr ausgegeben haben.
Also Beispiel:
Auftragsnr | kdnr | aktivnr | summeaktiv | materialnr | summematerial|
###
Ist dies überhaupt möglich?
Oder wird sowas generell anders besser umgesetzt?
Danke im Voraus.
Grüße
Phil
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 657795
Url: https://administrator.de/contentid/657795
Printed on: April 24, 2024 at 05:04 o'clock
14 Comments
Latest comment
Das ist generell möglich, via JOIN's.
Deine Tabellen sind schlecht aufgebaut, es gibt eine Menge von Redundanz, also Spalten, die in allen Tabellen vorhanden sind. Du hast PK's definiert, scheinst diese aber nicht als Foreign Keys zu verwenden. Im übrigen hat das auch nichts mit PHP zu tun, sondern mit SQL.
Deine Tabellen sind schlecht aufgebaut, es gibt eine Menge von Redundanz, also Spalten, die in allen Tabellen vorhanden sind. Du hast PK's definiert, scheinst diese aber nicht als Foreign Keys zu verwenden. Im übrigen hat das auch nichts mit PHP zu tun, sondern mit SQL.
Danke dir für die Antwort.
Meinte natürlich SQL sry.
Ja hast du Recht, es handelt sich auch noch um einen Test.
Das mit der Redundanz verstehe ich nicht ganz.
Ich benötige doch die kdnr z.B. in allen Tabellen um z.B. in der Material Tabelle auf die Tabelle Kunden zugreifen und eine Verbindung herstellen zu können.
Diees meintest du vermutlich mit Foreign Keys.
Meinte natürlich SQL sry.
Ja hast du Recht, es handelt sich auch noch um einen Test.
Das mit der Redundanz verstehe ich nicht ganz.
Ich benötige doch die kdnr z.B. in allen Tabellen um z.B. in der Material Tabelle auf die Tabelle Kunden zugreifen und eine Verbindung herstellen zu können.
Diees meintest du vermutlich mit Foreign Keys.
Moin,
so erfüllt das Query deine Anforderungen:
Macht Sinn? Les dich mal ein bischen in ERM und Normalisierung ein 
lg,
Slainte
so erfüllt das Query deine Anforderungen:
SELECT A.Auftragsnr, A.kdnr, A. aktivnr, A.Summe, M.Matertialnr, M.summe
FROM tAktivitaeten as A
LEFT JOIN tMaterial AS M on A.aktivnr = M.aktivnrlg,
Slainte
1
zum Beispiel hast Du in tAktivitaeten die auftragsnr, die in tAuftraege der PK ist. Das ist soweit okay. Außerdem hast Du in beiden Tabellen die kdnr - das ist doppelt und damit redundant und damit böse. Außerdem in beiden Tabellen: kontaktnr. Nochmals redundant, falsch & böse.
1
Moin
Wie schon vom Kollegen @akretschmer gesagt, hast du zu viele Redundanzen.
Beispiel tMaterial:
Ich deute das als "Artikelstammdaten". Willst du hier für jeden neuen Auftrag einen neuen Artikel anlegen?
Besser wäre es, in tAuftrag das Feld "tMaterial" einzubinden und dann dorthin zu referenzieren.*
Tabelle tAktivitaet:
Die Kundennummer sowie Kontaktnummer ergibt sich aus dem Auftrag, muss hier also nicht noch einmal eingebunden werden.*
usw.
Nun möchte ich gerne eine Ausgabe Query oder View haben, welche alle Aktivitäten aus der Tabelle "tAktivitaten" und alle Materialen aus der Tabelle "tMaterial" anhand der Auftragsnr ausgegeben haben.
Siehe Beispiel @SlainteMhath
Heute hat der Artikel "Füller" den Grundpreis 5,50 € und es werden 20 Aufträge mit dieser Bezeichnung angelegt.
Übermorgen ändert Hans im Artikel den Preis aus 6,49€. Bei einer reinen Referenz würden nun die 20 "alten" Aufträge plötzlich den neuen Betrag enthalten, obwohl die Kunden zum alten bestellt haben.
Hier wäre es also durchaus sinnvoll, die Preise in den Auftrag zu übernehmen (was i.d.R. auch gemacht wird).
Gruß
em-pie
Folgende Tabellen sind vorhanden (ich werde diese verkürzt darstellen):
tAuftraege:
auftragsnr (PK), kdnr, kontaktnr, titel
tAktivitaeten:
aktivnr (PK), kdnr, auftragsnr, kontaktnr, datum, von, bis, summe
tMaterial
materialnr (PK), kdnr, auftragsnr, aktivnr, artike, menge, summe
tAuftraege:
auftragsnr (PK), kdnr, kontaktnr, titel
tAktivitaeten:
aktivnr (PK), kdnr, auftragsnr, kontaktnr, datum, von, bis, summe
tMaterial
materialnr (PK), kdnr, auftragsnr, aktivnr, artike, menge, summe
Wie schon vom Kollegen @akretschmer gesagt, hast du zu viele Redundanzen.
Beispiel tMaterial:
Ich deute das als "Artikelstammdaten". Willst du hier für jeden neuen Auftrag einen neuen Artikel anlegen?
Besser wäre es, in tAuftrag das Feld "tMaterial" einzubinden und dann dorthin zu referenzieren.*
Tabelle tAktivitaet:
Die Kundennummer sowie Kontaktnummer ergibt sich aus dem Auftrag, muss hier also nicht noch einmal eingebunden werden.*
usw.
Nun möchte ich gerne eine Ausgabe Query oder View haben, welche alle Aktivitäten aus der Tabelle "tAktivitaten" und alle Materialen aus der Tabelle "tMaterial" anhand der Auftragsnr ausgegeben haben.
- Reine PK/ FK-referenzen sind aber nicht immer sinnvoll, sodass Redundanzen durchaus sinnvoll sein können.
Heute hat der Artikel "Füller" den Grundpreis 5,50 € und es werden 20 Aufträge mit dieser Bezeichnung angelegt.
Übermorgen ändert Hans im Artikel den Preis aus 6,49€. Bei einer reinen Referenz würden nun die 20 "alten" Aufträge plötzlich den neuen Betrag enthalten, obwohl die Kunden zum alten bestellt haben.
Hier wäre es also durchaus sinnvoll, die Preise in den Auftrag zu übernehmen (was i.d.R. auch gemacht wird).
Gruß
em-pie
1so erfüllt das Query deine Anforderungen:
Danke hierfür.
Macht Sinn? Les dich mal ein bischen in ERM und Normalisierung ein face-smile
face-smilewerde ich machen 👍
das ist doppelt und damit redundant und damit böse. Außerdem in beiden Tabellen: kontaktnr. Nochmals redundant, falsch & böse.
Das ist böse 😁.
Werde ich mir anschauen, haste natürlich Recht. Jetzt wenn man es so ließt 😅
Beispiel tMaterial:
Ich deute das als "Artikelstammdaten". Willst du hier für jeden neuen Auftrag einen neuen Artikel anlegen?Völlig richtig von dir.
Diese tMaterial soll nur als Material Liste für alle Aktivitäten dienen.
Also nicht Artikel je Auftrag.
Tabelle tAktivitaet:
Die Kundennummer sowie Kontaktnummer ergibt sich aus dem Auftrag, muss hier also nicht noch einmal eingebunden werden.*usw.
Yes macht Sinn.
Reine PK/ FK-referenzen sind aber nicht immer sinnvoll, sodass Redundanzen durchaus sinnvoll sein können.
Beispiel Auftrag:
Heute hat der Artikel "Füller" den Grundpreis 5,50 € und es werden 20 Aufträge mit dieser Bezeichnung angelegt.
Übermorgen ändert Hans im Artikel den Preis aus 6,49€. Bei einer reinen Referenz würden nun die 20 "alten" Aufträge plötzlich den neuen > > Betrag enthalten, obwohl die Kunden zum alten bestellt haben.
Hier wäre es also durchaus sinnvoll, die Preise in den Auftrag zu übernehmen (was i.d.R. auch gemacht wird).
Beispiel Auftrag:
Heute hat der Artikel "Füller" den Grundpreis 5,50 € und es werden 20 Aufträge mit dieser Bezeichnung angelegt.
Übermorgen ändert Hans im Artikel den Preis aus 6,49€. Bei einer reinen Referenz würden nun die 20 "alten" Aufträge plötzlich den neuen > > Betrag enthalten, obwohl die Kunden zum alten bestellt haben.
Hier wäre es also durchaus sinnvoll, die Preise in den Auftrag zu übernehmen (was i.d.R. auch gemacht wird).
Verstanden.
Also direkt nochmals die Tabellen neu aufbauen 👍👍.
Shiiiit, Arbeit umsonst 😅😅.
Wie heißt es. Nur zur Übung nicht zur Strafe.
Ich wollte mich nochmals kurz bei euch melden und nochmal eine Verständnisfrage klären:
Angenommen ich habe jetzt folgende Tabellen (gekürzt):
tKunden:
PK (kundennr)| |Firma | Name | Vorname | PLZ
##
tAnsprechpartner:
PK (kontaktnr) | Vorname | Nachnachme | Fullname | Telefonnummer
##
tAuftraege:
PK(auftragsnr)| Titel | Beschreibung | Datum
##
tAktivitaeten
PK(aktivnr)| Beschreibung | Zeit
##
tBenoetigtesMaterial:
PK(materialnr) | Artikel | Menge | Summe
So sehen die Tabellen einmal ohne Verknüpfungen (Foreign Keys aus).
Wie würdet ihr nun sauber die Tabellen miteinander verknüpfen, bzw die Foreign Keys bauen?
Meine Lösung:
Bitte um Korrektur, wenn ich hier falsch denke, danke.
1.
Damit die Ansprechpartner den Kunden zugeordnet werden können, benötige ich in der Tabelle tAnsprechpartner das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
2.
Damit die Aufträge dem Kunden zugeordnet werden können, benötige ich in der Tabelle tAuftraege das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
Zusätzlich benötige ich in der "tAuftraege "noch ein Feld "kontaktnr" als Foreign Key auf die Tabelle tAnsprechpartner um den Ansprechpartner für diesen Auftrag zu deklarieren.
3.
Damit die Aktivitäten dem Auftrag zugeordnet werden können, benötige ich in der Tabelle "tAktivitaeten" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
4.
Damit das Benötigte Material dem Auftrag zugeordnet werden kann, benötige ich in der Tabelle "tBenoetigtesMaterial" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
-> Ist dies soweit korrekt?
Nun frage ich mich:
1.
Wenn ich z.B. das Benötigte Material auch einer Aktivität zuweisen will, dann benötige ich in der Tabelle "tBenoetigtesMaterial" noch ein Feld "aktivnr" mit FK auf die tAktivitaeten. Richtig?
2.
Wenn es z.B. für die "tAktivitaeten" einen anderen Ansprechpartner als für den Auftrag gibt, dann muss in der "tAktivitaeten" zusätzlich noch ein Feld kontaktnr als FK auf die tAnsprechpartner eingefügt werden. Richtig?
Danke euch.
Grüße
Phil
Angenommen ich habe jetzt folgende Tabellen (gekürzt):
tKunden:
PK (kundennr)| |Firma | Name | Vorname | PLZ
##
tAnsprechpartner:
PK (kontaktnr) | Vorname | Nachnachme | Fullname | Telefonnummer
##
tAuftraege:
PK(auftragsnr)| Titel | Beschreibung | Datum
##
tAktivitaeten
PK(aktivnr)| Beschreibung | Zeit
##
tBenoetigtesMaterial:
PK(materialnr) | Artikel | Menge | Summe
So sehen die Tabellen einmal ohne Verknüpfungen (Foreign Keys aus).
Wie würdet ihr nun sauber die Tabellen miteinander verknüpfen, bzw die Foreign Keys bauen?
Meine Lösung:
Bitte um Korrektur, wenn ich hier falsch denke, danke.
1.
Damit die Ansprechpartner den Kunden zugeordnet werden können, benötige ich in der Tabelle tAnsprechpartner das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
2.
Damit die Aufträge dem Kunden zugeordnet werden können, benötige ich in der Tabelle tAuftraege das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
Zusätzlich benötige ich in der "tAuftraege "noch ein Feld "kontaktnr" als Foreign Key auf die Tabelle tAnsprechpartner um den Ansprechpartner für diesen Auftrag zu deklarieren.
3.
Damit die Aktivitäten dem Auftrag zugeordnet werden können, benötige ich in der Tabelle "tAktivitaeten" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
4.
Damit das Benötigte Material dem Auftrag zugeordnet werden kann, benötige ich in der Tabelle "tBenoetigtesMaterial" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
-> Ist dies soweit korrekt?
Nun frage ich mich:
1.
Wenn ich z.B. das Benötigte Material auch einer Aktivität zuweisen will, dann benötige ich in der Tabelle "tBenoetigtesMaterial" noch ein Feld "aktivnr" mit FK auf die tAktivitaeten. Richtig?
2.
Wenn es z.B. für die "tAktivitaeten" einen anderen Ansprechpartner als für den Auftrag gibt, dann muss in der "tAktivitaeten" zusätzlich noch ein Feld kontaktnr als FK auf die tAnsprechpartner eingefügt werden. Richtig?
Danke euch.
Grüße
Phil
-> Ist dies soweit korrekt?
sieht gut aus.
Wenn ich z.B. das Benötigte Material auch einer Aktivität zuweisen will, dann benötige ich in der Tabelle "tBenoetigtesMaterial" noch ein Feld "aktivnr" mit FK auf die tAktivitaeten. Richtig?
Wenn das eine 1:1 Beziehung ist: ja, wenn 1:n (also eine Aktivität, n Material) brauchst du noch eine Tabelle alatAktivitaetenMaerial
PK(FK(aktivnr), FK(materialnr))
Wenn es z.B. für die "tAktivitaeten" einen anderen Ansprechpartner als für den Auftrag gibt, dann muss in der "tAktivitaeten" zusätzlich noch ein Feld kontaktnr als FK auf die tAnsprechpartner eingefügt werden. Richtig?
Ja, falls 1:1, sonst siehe oben1
Sehen soweit gut aus
Willst du Wissen, wer von deinen Mitarbeitern der Ansprechpartner für den Kunden ist, dann mache es anders herum:
Füge bei jedem Kunden das Feld "ansprechpartner" ein. Dort wird dann die Nr. des Ansprechpartners aus der tAnsprechpartner eingesetzt.
Denn es kann ja sein, dass es einen Ansprechpartner für viele Kunden gibt.
Oder du bleibst flexibel und lässt beides zu, kann ja also Nicht-Pflichtfeld definiert werden.
Du willst ja einem Auftrag ein Material zuordnen. Dann wäre es sinnvoller, wenn in der Tabelle "tAuftraege" die Materialnummer enthalten wird, die wiederum dann mit der Nr. aus "tBenoetigtesMaterial" stammt
2.
Wenn es z.B. für die "tAktivitaeten" einen anderen Ansprechpartner als für den Auftrag gibt, dann muss in der "tAktivitaeten" zusätzlich noch ein Feld kontaktnr als FK auf die tAnsprechpartner eingefügt werden. Richtig?
Jo.
1.
Damit die Ansprechpartner den Kunden zugeordnet werden können, benötige ich in der Tabelle tAnsprechpartner das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
Das ist jetzt Definitionssache: Willst du die Ansprechpartner beim Kunden wissen, passt deine Definition.Damit die Ansprechpartner den Kunden zugeordnet werden können, benötige ich in der Tabelle tAnsprechpartner das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
Willst du Wissen, wer von deinen Mitarbeitern der Ansprechpartner für den Kunden ist, dann mache es anders herum:
Füge bei jedem Kunden das Feld "ansprechpartner" ein. Dort wird dann die Nr. des Ansprechpartners aus der tAnsprechpartner eingesetzt.
Denn es kann ja sein, dass es einen Ansprechpartner für viele Kunden gibt.
Oder du bleibst flexibel und lässt beides zu, kann ja also Nicht-Pflichtfeld definiert werden.
2.
Damit die Aufträge dem Kunden zugeordnet werden können, benötige ich in der Tabelle tAuftraege das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
KorrektDamit die Aufträge dem Kunden zugeordnet werden können, benötige ich in der Tabelle tAuftraege das Feld "kundennr" als Foreign Key auf die Tabelle tKunden.
Zusätzlich benötige ich in der "tAuftraege "noch ein Feld "kontaktnr" als Foreign Key auf die Tabelle tAnsprechpartner um den Ansprechpartner für diesen Auftrag zu deklarieren.
Jopp, sofern der Ansprechpartner für einen einzigen Kunden je Auftrag variieren kann - macht man aber meist so, wie du es planst.3.
Damit die Aktivitäten dem Auftrag zugeordnet werden können, benötige ich in der Tabelle "tAktivitaeten" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
Korrekt.Damit die Aktivitäten dem Auftrag zugeordnet werden können, benötige ich in der Tabelle "tAktivitaeten" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
4.
Damit das Benötigte Material dem Auftrag zugeordnet werden kann, benötige ich in der Tabelle "tBenoetigtesMaterial" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
Anders herum.Damit das Benötigte Material dem Auftrag zugeordnet werden kann, benötige ich in der Tabelle "tBenoetigtesMaterial" ein Feld "auftragsnr" als Foreign Key auf die Tabelle tAufträge.
Du willst ja einem Auftrag ein Material zuordnen. Dann wäre es sinnvoller, wenn in der Tabelle "tAuftraege" die Materialnummer enthalten wird, die wiederum dann mit der Nr. aus "tBenoetigtesMaterial" stammt
Nun frage ich mich:
1.
Wenn ich z.B. das Benötigte Material auch einer Aktivität zuweisen will, dann benötige ich in der Tabelle "tBenoetigtesMaterial" noch ein Feld "aktivnr" mit FK auf die tAktivitaeten. Richtig?
Anders herum. In der Aktivität das Feld materialnr einbinden.1.
Wenn ich z.B. das Benötigte Material auch einer Aktivität zuweisen will, dann benötige ich in der Tabelle "tBenoetigtesMaterial" noch ein Feld "aktivnr" mit FK auf die tAktivitaeten. Richtig?
2.
Wenn es z.B. für die "tAktivitaeten" einen anderen Ansprechpartner als für den Auftrag gibt, dann muss in der "tAktivitaeten" zusätzlich noch ein Feld kontaktnr als FK auf die tAnsprechpartner eingefügt werden. Richtig?
Grüße
Phil
Phil
Hallo,
danke euch beiden 😉.
Das war mir jetzt wichtig, dass der Aufbau so stimmt und die Denkweise für die weiteren Verknüpfungen bis auf ein paar Erweiterungen auch ganz gut passt.
Hier hast du vollkommen Recht.
In meinem Fall wäre es ja eine 1:n Beziehung, da einer Aktivität mehr Material zugewiesen werden kann und nicht nur jeder Aktivität ein Material.
###
Genau. Ich möchte wie von dir zuerst beschrieben einem Kunden mehrere Ansprechpartner auf Seiten des Kunden zuordnen.
Mhh so wie du es schreibst, weiße ich dem Auftrag ein Artikel zu.
Es kann aber durchaus vorkommen (wird es auf jeden Fall), dass ein Auftrag mehrere Artikel zugewiesen werden (Material).
Ich hatte die Idee, um z.B. alles Material zu einem Auftrag auszugeben.
Wenn ich jetzt allerdings nochmals richtig überlege, habe ich das Material ja den Aktivitäten zugewiesen, welche dem Auftrag zugewiesen sind.
Dadurch bekomme ich eigentlich auch das komplette Material eines Auftrags heraus, richtig?
danke euch beiden 😉.
Das war mir jetzt wichtig, dass der Aufbau so stimmt und die Denkweise für die weiteren Verknüpfungen bis auf ein paar Erweiterungen auch ganz gut passt.
Wenn das eine 1:1 Beziehung ist: ja, wenn 1:n (also eine Aktivität, n Material) brauchst du noch eine Tabelle ala
tAktivitaetenMaerial
PK(FK(aktivnr), FK(materialnr))
tAktivitaetenMaerial
PK(FK(aktivnr), FK(materialnr))
Hier hast du vollkommen Recht.
In meinem Fall wäre es ja eine 1:n Beziehung, da einer Aktivität mehr Material zugewiesen werden kann und nicht nur jeder Aktivität ein Material.
###
Das ist jetzt Definitionssache: Willst du die Ansprechpartner beim Kunden wissen, passt deine Definition.
Willst du Wissen, wer von deinen Mitarbeitern der Ansprechpartner für den Kunden ist, dann mache es anders herum:
Füge bei jedem Kunden das Feld "ansprechpartner" ein. Dort wird dann die Nr. des Ansprechpartners aus der tAnsprechpartner eingesetzt.
Denn es kann ja sein, dass es einen Ansprechpartner für viele Kunden gibt.
Oder du bleibst flexibel und lässt beides zu, kann ja also Nicht-Pflichtfeld definiert werden.
Willst du Wissen, wer von deinen Mitarbeitern der Ansprechpartner für den Kunden ist, dann mache es anders herum:
Füge bei jedem Kunden das Feld "ansprechpartner" ein. Dort wird dann die Nr. des Ansprechpartners aus der tAnsprechpartner eingesetzt.
Denn es kann ja sein, dass es einen Ansprechpartner für viele Kunden gibt.
Oder du bleibst flexibel und lässt beides zu, kann ja also Nicht-Pflichtfeld definiert werden.
Genau. Ich möchte wie von dir zuerst beschrieben einem Kunden mehrere Ansprechpartner auf Seiten des Kunden zuordnen.
Anders herum.
Du willst ja einem Auftrag ein Material zuordnen. Dann wäre es sinnvoller, wenn in der Tabelle "tAuftraege" die Materialnummer enthalten > wird, die wiederum dann mit der Nr. aus "tBenoetigtesMaterial" stammt
Du willst ja einem Auftrag ein Material zuordnen. Dann wäre es sinnvoller, wenn in der Tabelle "tAuftraege" die Materialnummer enthalten > wird, die wiederum dann mit der Nr. aus "tBenoetigtesMaterial" stammt
Mhh so wie du es schreibst, weiße ich dem Auftrag ein Artikel zu.
Es kann aber durchaus vorkommen (wird es auf jeden Fall), dass ein Auftrag mehrere Artikel zugewiesen werden (Material).
Ich hatte die Idee, um z.B. alles Material zu einem Auftrag auszugeben.
Wenn ich jetzt allerdings nochmals richtig überlege, habe ich das Material ja den Aktivitäten zugewiesen, welche dem Auftrag zugewiesen sind.
Dadurch bekomme ich eigentlich auch das komplette Material eines Auftrags heraus, richtig?
Mhh so wie du es schreibst, weiße ich dem Auftrag ein Artikel zu.
Es kann aber durchaus vorkommen (wird es auf jeden Fall), dass ein Auftrag mehrere Artikel zugewiesen werden (Material).
Für gewöhnlich gibt es einen Auftragskopf, welcher Daten wie Liefer-/ Zahlungsbedingungen, Kundennr., eure Auftragsnummer, die BEstellNr. des Kunden, etc. beinhaltet.Es kann aber durchaus vorkommen (wird es auf jeden Fall), dass ein Auftrag mehrere Artikel zugewiesen werden (Material).
Neben dem Auftragskopf existiert dann eine (weitere) Tabelle, die die einzelnen Positionen eines Auftrags beinhaltet. An diese Position würde dann Artikel, Preis, Liefertermin, etc. hinterlegt werden.
Das könntest du aber auch mit den von dir bereits beschrieben Aktivitäten abfrühstücken...
1
Alles klar, danke 😊.
Eine Frage noch zum abbilden, bzw. dem Aufbau der Datenbanken in grafischer Form.
Mit was für einem Tool und wie stellt ihr diesen Aufbau z.B. grafisch dar? Ich denke, dass Ihr sowas in die Richtung durchführt.
Eine Frage noch zum abbilden, bzw. dem Aufbau der Datenbanken in grafischer Form.
Mit was für einem Tool und wie stellt ihr diesen Aufbau z.B. grafisch dar? Ich denke, dass Ihr sowas in die Richtung durchführt.
Mit was für einem Tool und wie stellt ihr diesen Aufbau z.B. grafisch dar? Ich denke, dass Ihr sowas in die Richtung durchführt.
Visual Paradigm https://www.visual-paradigm.com/solution/freeumltool/1
Cool, danke 😉👍
