Spezielle SQL Abfrage

[Loipe]

Hallo zusammen,

ich möchte gerne eine SQL Abfrage machen, weiß aber nicht wie ich das lösen kann.
Aktuell habe ich folgenden Afrage

[highlight=sql]
SELECT KOMPONENTEN.VORGANG AS Vorgang,
MATERIALTEXTE.MATERIALTEXT AS Bezeichnung,
KOMPONENTEN.KOMPONENTE AS Komponente,
KOMPONENTEN.ANZAHL AS Anzahl,
KOMPONENTEN.EINHEIT AS Einheit
FROM KOMPONENTEN
LEFT JOIN MATERIALTEXTE ON KOMPONENTEN.KOMPONENTE = MATERIALTEXTE.MATERIALNUMMER
[/highlight=sql]


Beispielergebnis:

Vorgang	Bezeichnung	Komponente	Anzahl	Einheit
0510	Kolben	111111111	1	ST
0510	Sechkantschraube	222222222	4	ST
0560	Ringe	333333333	6	ST
0590	Buchse	444444444	1	ST
0590	Lagerschale	555555555	6	ST

So nun sollte es eine weitere Tabelle geben mit der noch alternative Komponenten eingeben werden.
Wie sie Tabelle aufgebaut wird ist mir jetzt noch egal. Aber der Sinn der Tabelle sollte so sein, das mehrere Komponentennummer gleichwertig sein sollen.

Also ein Beispiel:
111111113=11111111=11111112

Als Ergebnis solle dann folgendes erscheinen

Vorgang	Bezeichnung	Komponente	Anzahl	Einheit
0510	Kolben	111111111	1	ST
0510	Kolben	111111112	1	ST
0510	Kolben	111111113	1	ST
0510	Sechkantschraube	222222222	4	ST
0560	Ringe	333333333	6	ST
0590	Buchse	444444444	1	ST
0590	Lagerschale	555555555	6	ST

Die anderen Werte (Vorgang, Bezeichnung, Anzahl und Einheit sollen von dem ursprünglichen Ergebnis übernommen werden).

Bin für jeden Vorschlag dankbar.

Gruß Alex

[Christian Marquardt]

Wie soll logisch diese Gleichheit hergestellt werden?
111111113=11111111=11111112
Wenn es immer eine laufende Nr. ist-> wie weit läuft die?
Ansonsten wäre bsp.
select
(select VORGANG from KOMPONENTEN where LEFT(Komponente, 7)=LEFT(KOMPONENTEN.KOMPONENTE, 7) ) as VORGANG,
......
eine Möglichkeit

[defo2]

Das sieht mir eher nach einer Zuordnung aus. Ich schätze, wenn es um Fertigungsplanung /-anweisung geht, muss das explizit definiert werden.

Dabei wäre die Frage, ob man
eine explizite Definition von Äquivalenzen nimmt oder
eine Klassenspalte anlegt für die gilt, Identische Werte stehen für austauschbare Komponenten

Entsprechend wäre dann zu modellieren und zu joinen.

[defo2]

konkreter:
Eine exakte Zuordnung von Komponente zu Komponente erlaubt gerichtete Ersatzangaben:
OriginalID | Ersatz
111111 | 111112
111111 | 111113
111112 | 111113
111113 | NULL

Eine Klasse definiert eine allgemeine Baugleichheit/ Beliebigkeit.
KomponenteID | Bauart
1111111 | Kolben
1111112 | Kolben
1111113 | Kolben AFP Stahl

Austauschbarkeit im 2. Beispiel ist relativ beliebig (innerhalb der Bauart "Kolben"), im ersten gibt es keine Beliebigkeit.

[Loipe]

defo2 hat es schon richtig verstanden. Wenn es eine Komponente gibt, bei der auch andere verbaut werden dürfen, dann sollen diese in der Abfrage ebefalls aufgeführt werden. Die Nummer der Komponente ist nicht fortlaufend aussteigen, die kann irgendwie heissen. Wie die Tabelle aufgebaut wird ist mir aktuelle auch noch egal, da es diese noch nicht gibt. Ich wollte die freiheit lassen um die Abfrage möglichst einfach zu gestalten und da keine großen Vorgaben machen. Könnte mir die Tabelle so vorstellen wie es defo2 bereits angedeutet hat. Allerdings bekomme cih die Abfrage nicht hin. Auch nicht, das dann die anderen Spalten mit den ursprünglichen Werten befüllt

[defo2]

Naja, du darfst Dich schon gerne genauer ausdrücken. Die Funktionalität sollte sich ja nicht primär dadurch definieren, welche Abfrage netter ist.
Es geht alles mögliche. Fachlich sehe ich keine großen Mengen, also auch kein Performanceproblem.
Am Ende klingt das was Du haben möchtest doch etwas nach "hinten dran definiert", es gibt eine bestehende Lösung und "jetzt brauchen wir aber noch ". Macht auf Dauer ein System zum Krüppel.

Was ist angesagt: Flexibilität und Präzision und Pflegeaufwand
oder "was nicht passt wird passend gemacht"

[Loipe]

Aber so läuft das doch immer ab. Es läuft ein System und irgendwann muss es erweitert oder verbessert werden. Da kann man doch nicht immer alles komplett neu überdenken. Also brauchen wir noch eine Tabelle mit AlternativKomponenten.
Am liebesten wäre mir eine Tabelle in der die alternative Komponente, die alternativ verwendet werden können, in einer Reihe stehen. Z.B.

ID	Komponente1	Komponente2	Komponente3	Komponente4	Komponente5
23	111111113	111111111	111111112	346542233
24	543325342	654343323	332321111

Ist nun in der Abfrage irgendwo die Komponente in der Tabelle AlternativKomponenten zu finden, dann müssen alle Komponente, in der ganzen Zeile, aufgeführt werden. Inklusive aller andere Spalten von der ersten Abfrage.

Ich bekomme von einem übergeordnetetm System eine Stückliste. Dort steht z.B. drin, der Kolben mit der Nummer 111111111 soll verbaut werden. Allerdings gibt es für mache Bauteile auch die Möglichkeit Gleichteile zu verbauen (evtl. von einem anderen Hersteller). Deshalb sollten immer alle möglichen Nummer aufgeführt werden.

[defo2]

Ja klar, so ist es. Es war auch nur der obligatorische Hinweis.
Dein Vorschlag ist nicht sehr gelungen und erklärt auch die Mühe, die es machen würde, eine passende Abfrage zu bauen bzw. das zu verwalten.

Datenmodelle mit durchnummerierten Spalten sind immer ein guter Indikator für fehlende Normalisierung. Für den einen Fall, dass neben dem erforderlichen Teil noch 1 oder 2 alternativen stehen sollen, mag es ok wirken, aber zur Pflege, in Reports usw. ist es Horror. Aber so wie Du es vorschlägst, ist es selbst in Deinem Fall keine gute Idee.

Irgendwelche Informationen in Listen statt in Zeilen aufzuführen ist auch jenseits von Datenmodellen state of the art.
Es gibt keine Einkaufszeilen, sondern Einkaufslisten. In Spalten wird gleichartiges untereinander aufgeführt.

Sorry, also mit meiner Aussage "es geht alles mögliche" meinte ich nicht sowas wie in Deinem Vorschlag. Ausnahme wäre, Du nennst extrem gute Gründe, das so zu machen.

Wie soll aus Deiner einzigen Zeile mit 3 (4) Komponenten denn Deine eigene Zielvorstellung werden mit 3 (4) Zeilen?
Und was wäre mit der 6.Komponente? Listen sind auch deswegen Listen, weil man sie immer weiter verlängern kann (Tabellen eben, das Verbreitern einer Tabelle ist ungleich schwieriger, nicht so sehr vom Statement her, aber was Dynamik und praktische Anwendung angeht)

[defo2]

Hier ist eine einfache Variante, die schon mal ein mögliches Prinzip zeigt.

SELECT KOMPONENTEN.VORGANG        AS Vorgang,
       MATERIALTEXTE.MATERIALTEXT AS Bezeichnung,
       /*--KOMPONENTEN.KOMPONENTE     AS Komponente,   -- würde immer orignal Komponente zeigen  */
       alt.MATERIALNUMMER         AS Komponente        /*zeigt alternative Komponente */
       KOMPONENTEN.ANZAHL         AS Anzahl,
       KOMPONENTEN.EINHEIT        AS Einheit
  FROM KOMPONENTEN
  JOIN MATERIALTEXTE                                   /* left zur Anschaulichkeit erstmal raus*/
    ON KOMPONENTEN.KOMPONENTE = MATERIALTEXTE.MATERIALNUMMER
  LEFT JOIN MATERIALTEXTE alt                          /* self join auf Bestandstexte für alternative Komponenten*/
    ON MATERIALTEXTE.MATERIALTEXT = alt.MATERIALTEXT

[Loipe]

Habe jetzt ein bisschen gebastelt und was hinbekommen. Allerdings mit einem UNION Befehlt. Weiß nicht ob das auch besser funktioniert. Vor allem müsste ich zum Schluss noch eine Sortierung mittels order by einbauen. Jetzt werden mir die orginalen und die alternative Komponente in einer Abfrage angezeigt. Ich brauche immer beide Einträge!
Die Tabelle AlternativSachnummer hat nun nur zwei Spalten. Sachnummer_org und Sachnummer_alternativ.

SELECT
KOMPONENTEN.VORGANG,
KOMPONENTEN.KOMPONENTE as Komponente,
MATERIALTEXTE.MATERIALTEXT,
KOMPONENTEN.ANZAHL,
KOMPONENTEN.EINHEIT
FROM KOMPONENTEN
JOIN MATERIALTEXTE ON KOMPONENTEN.KOMPONENTE = MATERIALTEXTE.MATERIALNUMMER
LEFT JOIN ALTERNATIVSNR ON ALTERNATIVSNR.SACHNUMMER_org = KOMPONENTEN.KOMPONENTE
UNION
SELECT
KOMPONENTEN.VORGANG,
ALTERNATIVSNR.SACHNUMMER_alternativ as Komponente,
MATERIALTEXTE.MATERIALTEXT,
KOMPONENTEN.ANZAHL,
KOMPONENTEN.EINHEIT
FROM KOMPONENTEN
JOIN MATERIALTEXTE ON KOMPONENTEN.KOMPONENTE = MATERIALTEXTE.MATERIALNUMMER
LEFT JOIN ALTERNATIVSNR ON ALTERNATIVSNR.SACHNUMMER_org = KOMPONENTEN.KOMPONENTE
WHERE ALTERNATIVSNR.SACHNUMMER_alternativ is not null

[defo2]

Nicht schlecht! Untereinander ist doch besser als nebeneinander oder?
Dann hab ich mir umsonst "die Finger schmutzig gemacht". Was gefällt Dir an meinem Vorschlag nicht?

Und zu Deiner Lösung:
1 - Du hast entgegen deines ursprünglichen Statements den Left Join zwischen Komponente und Materialtext zu einem Inner Join gemacht
2 - Left ist nun "nur noch" der neue Join zu der Alt. Tabelle
3 - den schränkst Du dafür mit dem is not null ein
4 - die beiden Union Teile sind ~99 % identisch, bis auf die Ausgabe der Spalte "Komponente"

zu 1: Ich kenne Dein Modell nicht, schau Dir genau an, was Du für Daten hast, was Dein Modell erlaubt und was ein Left Join macht
zu 2,3, siehe 1, ist es vielleicht auch hier ein Inner Join?
zu 4: Wenn die 2 Statements eigentlich identisch sind und Du nur einen typabhängigen Spaltenwechsel bräuchstest, kannst Du das in der Select Clause mit Case machen, Du brauchst nur den richtigen Aufhänger.
Probier das doch mal

Was mir grad nicht richtig in die Birne geht: Die alternativen Komponenten müssen bei dem identischen Grundstatement ja eigentlich auch schon alle als Komponente da sein und würden mit ihren eigenen Daten aufgelistet werden - was ja nicht gewollt ist-. Wo sind sie? Warum müssen sie nicht rausgefiltert werden?

[Loipe]

Ich glaube ihr Vorschlag funktioniert nur wenn immer ein Eintrag in der Tabelle ALTERNATIVSNR drin steht. In meinem Falls ist es aber so, das dort nur Einträge drin stehen, die eine Alternativsachnummer besitzten. Deshalb geht das bei ihrem Vorschlag nicht. Vermute ich mal. Bin ja nicht so der SQL Crack.
zu 1. Stimmt, da hab ich icht richtig aufgepasst. Muss natürlich ein LEFT JOIN sein, sonst könnte es sein das evtl ein paar Ergebnis rausfallen, wenn kein Materialtext vorhanden ist.
Hier nochmal kurz zum Verständnis der Inhalt der Tabellen:
Tabelle Vorgänge: Das ist ie Haupttabelle. Dort stehen alle Nummer drin die benötigt werden. + Anzahl und Einheit und noch ein paar andere Daten zum Filtern
Tabelle Materialtexte: Das ist der Text zu den Nummern. Es kann sein das nicht für jede Nummer ein Text angelegt wurde.
Tabelle AlternativSNR: Dort ist ein Liste enthalten, wenn es für eine Nummer eine alternative Nummer gibt. Dort sind nicht alle Nummer enthalten.

Ich habe jetzt nochmal ein wenig rumgebastelt und bin zu diesem Ergebnis gekommen.

WITH Abfrage AS (
SELECT
KOMPONENTEN.VORGANG,
CASE WHEN ALTERNATIVSNR.SACHNUMMER_alternativ is not null
   THEN ALTERNATIVSNR.SACHNUMMER_alternativ
   ELSE KOMPONENTEN.KOMPONENTE
END as Komponente,
KOMPONENTEN.ANZAHL,
KOMPONENTEN.EINHEIT,
KOMPONENTEN.POSITION
FROM KOMPONENTEN
LEFT JOIN ALTERNATIVSNR ON ALTERNATIVSNR.SACHNUMMER_org = KOMPONENTEN.KOMPONENTE)

SELECT Abfrage.*, MATERIALTEXTE.MATERIALTEXT FROM Abfrage
LEFT JOIN MATERIALTEXTE ON Abfrage.KOMPONENTE = MATERIALTEXTE.MATERIALNUMMER
ORDER BY Abfrage.VORGANG ASC, Abfrage.POSITION ASC, Abfrage.Komponente

Mit dieser Lösung kann ich leben. Das einzige Manko ist noch das ich in der Tabelle AlternativSNR auch immer die Ursprüngliche Nummer in beiden Feldern drin stehen muss

Sachnummer_org	Sachnummer_alternativ
111111111	111111111
111111111	111111112
111111111	111111113