02.03.2021

1945

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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 657795

Url: https://administrator.de/contentid/657795

Ausgedruckt am: 04.12.2024 um 08:12 Uhr

14 Kommentare

Neuester Kommentar

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.

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.

Moin,

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.aktivnr

Macht Sinn? Les dich mal ein bischen in ERM und Normalisierung ein

lg,
Slainte

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.

Zitat von @Gerber:
Hallo zusammen,

Moin

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

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.

Siehe Beispiel @SlainteMhath

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).

Gruß
em-pie

so erfüllt das Query deine Anforderungen:

Danke hierfür.

Macht Sinn? Les dich mal ein bischen in ERM und Normalisierung ein

face-smile

werde 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).

Verstanden.

Also direkt nochmals die Tabellen neu aufbauen 👍👍.

Shiiiit, Arbeit umsonst 😅😅.

Wie heißt es. Nur zur Übung nicht zur Strafe.

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 ala

tAktivitaetenMaerial
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 oben

Zitat von @Gerber:
[Die Tabellen]

Sehen soweit gut aus

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.
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.

Korrekt

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.

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.
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

Anders herum. In der Aktivität das Feld materialnr einbinden.

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.

Grüße
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.

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))

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.

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

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.
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...

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.