Zwei Tabellen zusammenführen / Ist Cross Join die beste Lösung?

[ukulele]

Also es ist noch früh, ich weiß nicht ob ich verstehe was du suchst. Wenn du nur Datensätze zählen willst die nicht NULL sind kannst du statt mit count() mit sum() und CASE arbeiten.

SELECT sum(CASE WHEN spalte IS NULL THEN 0 ELSE 1 END) AS anzahl_nicht_NULL FROM tabelle

Bei max() ist NULL ja schon das "untere Ende", ist also quasi egal. Bei sum() haben NULLs ebenfalls keine Auswirkung.

 

[IchHH]

Hallo ukulele,

ich habe folgende Ausgangssituation.

Ich habe eine Spalte mit Materialien, KW, Year und Menge des Wareneinganges. Diese Tabelle habe ich durch Cross Join um fehlende KW aufgefüllt und auf die nächsten 2 Jahre ausgeweitet. Mit der Zählenfunktion habe ich zunächst tatsächlich erreicht, dass er nur die Spalte zählt die Werte haben. Bei der max() ermittlung macht er ebenfalls das was er soll nämlich die Werte zwischen den nicht gefüllten KW´s auffüllen. Aber... er macht es leider auch in den KW´s der folge Jahre, was ja falsch ist. Irgendwo muss ich also etwas nicht berücksichtigt haben oder als Fehler im Code haben. Natürlich will ich auch nicht ausschließen, dass ich nicht ganz durchdrungen habe wie der Code wirklich funktioniert, daher die Bitte um Unterstützung.

 

[ukulele]

Ich glaube du wirst den Code zeigen müssen, idealerweise ein paar Tabellen mit Testdatensätze und dazu das Query, das Result und das gewünschte Result.

 

[IchHH]

Hallo ukulele,

klar. Hier zunächst der Code.

SELECT t.*, max(Kumulierte_Menge) OVER (PARTITION BY [EMATN] ORDER BY WERKS,[TheISOweek],TheISOYear,grp) as new_Value
FROM
(

Select
KalTbl.[Key]
,KalTbl.[MANDT]
,KalTbl.[EMATN]
,KalTbl.[WERKS]
,KalTbl.[TYP]
,KalTbl.[TheISOweek]
,KalTbl.[TheISOYear]
--,WE.FFMNNO
,ISNULL(WE.Menge_WE,0) Menge_WE
,ISNULL(SUM(WE.MENGE_WE)
OVER (PARTITION BY WE.[EMATN] ORDER BY WE.WERKS,WE.[KW],TheISOYear),0) Kumulierte_Menge
,COUNT(WE.MENGE_WE) OVER (PARTITION BY WE.[EMATN] ORDER BY WE.WERKS,[TheISOweek],TheISOYear) as grp
FROM
(
SELECT
[Key]
,[MANDT]
,[EMATN]
,[WERKS]
,[TYP]
--,EBTYP
,TheISOweek
,TheISOYear

FROM
(SELECT DISTINCT
[Key]
,[MANDT]
,[EMATN]
,[WERKS]
,[TYP]
--,EBTYP
FROM
[dbo].[v_LB_Wareneingaenge]
--WHERE [v_LB_Wareneingaenge].EMATN = '000000000000011146' OR [v_LB_Wareneingaenge].EMATN = '000000000000005252'
-- AND [v_LB_Wareneingaenge].WERKS = '1010'
) w

CROSS JOIN

(SELECT DISTINCT
TheIsoweek, TheIsoYear
FROM
[dbo].[DateDimension]
Where TheISOYear between Year(GetDate())-1 and Year(GetDate())+2) a) KalTbl

LEFT JOIN

[dbo].[v_LB_Wareneingaenge_KW] WE
ON WE.MANDT = KalTbl.MANDT
AND WE.EMATN = KalTbl.EMATN
AND WE.WERKS = KalTbl.WERKS
AND RIGHT(WE.KEYDATE,4) = KalTbl.TheISOYear
AND WE.KW = KalTbl.TheISOweek

WHERE CONCAT(KalTbl.TheISOYear,RIGHT(CONCAT('0',KalTbl.[TheISOweek]),2)) >= CONCAT(YEAR(GETDATE()),DATEPART(ISOWK,GETDATE()))

AND (KalTbl.EMATN = '000000000000011146' OR KalTbl.EMATN = '000000000000005252'
AND KalTbl.WERKS = '1010')



--Order by EMATN, KalTbl.TheISOYear, TheISOweek
) t


Order by EMATN, TheISOYear, TheISOweek

Das Ergebnis diese Abfrage ist anbei. Dort ist gut zu erkennen, dass er Ergebnisse für 2023 & 2024 ausgibt, wo ich aber erwartet hätte das er "0" bringt, da er dafür auch kein grp Wert in dem Jahr gebracht hat.

 

[dabadepdu]

ach, und nicht programmierte Wünsche in der dB brauchen keine update in der dB? Ob ich nun die dB update oder die Applikation das macht ja wohl kaum einen Unterschied. Ich brauche mindestens einen Entwickler und das ganze QM und Deployment Team.

Mmh, weiß nicht. Im vorliegenden Fall wäre es jedenfalls unnötig.
Natürlich kann ich auch mit der DB nicht zaubern. Fälle, die im Programm nicht behandelt werden, kann ich in der DB nicht weghexen.
Ich kann in der DB aber ziemlich einfach Stammdaten ergänzen, Views ändern, SP ändern, die an der Schnittstelle zur App nicht zu Reibung führen. Das geht in vielen Fällen onthefly, ohne Wartungsfenster und anderes Theater. Bei einer Webapp ist es ja auch nur ein Austausch, nicht wirklich dramatisch. Bei Fatclient oder Mobile App sieht es mit Applikationsänderungen schon ganz anders aus. Erst Recht, wenn man über offizielle Stores verteilt.

 

[ukulele]

Leider ist das als Außenstehender schwer zu sehen, ich stecke in den Spaltennamen und Zahlen nicht so tief drin. Auch zeigst du zwar Query und Result, ich habe aber keine Testdaten um das nach zu vollziehen.

Im Prinzip passiert folgendes:

Alle Produkte (w) werden per CROSS JOIN mit allen möglichen Zeitinterwallen (KalTbl) gejoint. Das Ergebnis wird dann mit tatsächlichen Datensätzen gejoint (WE).

Für mich sieht das so aus als würde eine Join-Condition im LEFT JOIN fehlen, aber so ganz ist mir nicht klar welche Datensätze wirklich "zu viel" sind. Du solltest das vielleicht mit einigen wenigen Datensätzen in einer Teststellung bauen.