Beantwortet JTL1.6 Wo finde ich die Lieferadresse in der SQL DB ?

[s.broeker]

Hallo Läute

kann mir einer sagen, wo sich die Lieferadresse in der 1.6 hin verzogen haben?

Es gab ja mal die Tabelle Lieferadressen in der 1.5

die tAdresse Tabelle ist es auf jeden Fall nicht. Zumindest passen die kLieferAdresse Ids nicht zu der Tabelle.

 

[mh1]

weiß ja nicht, was du vor hast.
Falls du nur gschwind mal was nachkucken willst, kannst du ja mal im DEPRECATED Schema den entsprechenden VIEW nehmen.

 

[mh1]

die tAdresse Tabelle ist es auf jeden Fall nicht. Zumindest passen die kLieferAdresse Ids nicht zu der Tabelle.

Wenn ich mir aber hier https://wawi-db.jtl-software.de/tables/1.6.43.0
die dbo.tAdresse anschaue, hat die ein Feld nTyp und in der Beschreibung steht: "0=Lieferadresse, 1=Rechnungsadresse und 2=Sonstige Adresse".
Demnach würde ich jetzt, ohne die 1.6 genau zu kennen, ein SELECT * FROM tAdresse WHERE nTyp=0 machen.

 

[s.broeker]

Hallo so ich habe es gefunden, das ganze ist un Verkauf gelandet

tAdresse ist auf jeden fall falsch aber auch egal im Verkauf.tAuftragAdresse
findet man die Adressen, also Kundenadresse und Lieferadresse

hier mal die fertige SQL Abfrage

SELECT B.* FROM Verkauf.tAuftrag AS A
INNER JOIN Verkauf.tAuftragAdresse AS B ON (B.kAuftrag = A.kAuftrag AND B.nTyp = '0')
WHERE A.cAuftragsNr='2020093040389AB'

 

[mh1]

Klasse, dass du gefunden hast, was du gesucht hast

SELECT B.* FROM Verkauf.tAuftrag AS A
INNER JOIN Verkauf.tAuftragAdresse AS B ON (B.kAuftrag = A.kAuftrag AND B.nTyp = '0')
WHERE A.cAuftragsNr='2020093040389AB'

Anmerkung: Ich habe keine Ahnung, was in tAuftrag und in tAuftragsadresse drin steht. Falls da eh nur ein paar Hundert Datensätze drin sind, wird sich meine Anmerkung kaum spürbar auswirken, aber falls dort zig Tausende......
In deiner Abfrage muss die Datenbank beide Tabellen komplett sortieren und verknüpfen.
Wenn du aber den JOIN nur mit einer Teilmenge ausführst (pre-aggregation), kannst du die Ausführungszeit vielleicht spürbar verringern. Also dann SELECT ... FROM (SELECT ... FROM ... WHERE ...) JOIN .......

 

[s.broeker]

Klasse, dass du gefunden hast, was du gesucht hast


Anmerkung: Ich habe keine Ahnung, was in tAuftrag und in tAuftragsadresse drin steht. Falls da eh nur ein paar Hundert Datensätze drin sind, wird sich meine Anmerkung kaum spürbar auswirken, aber falls dort zig Tausende......
In deiner Abfrage muss die Datenbank beide Tabellen komplett sortieren und verknüpfen.
Wenn du aber den JOIN nur mit einer Teilmenge ausführst (pre-aggregation), kannst du die Ausführungszeit vielleicht spürbar verringern. Also dann SELECT ... FROM (SELECT ... FROM ... WHERE ...) JOIN .......

Hallo Michael

Also es geht mir nicht um die Ausfuhrzeit, das mit den INNER JOIN ist halt das einfachste die abfrage zu gestalten, dennoch bin ich immer interessiert neues zu lernen

Ich habe grade mal etwas gegoogelt, aber auch noch nicht wirklich verstanden, wie du das gemeint hast.

Wie würdest du den die abfrage von mir gestalten, vielleicht hast du ja mal ein Beispiel, wo ich dran anknüpfen kann.

 

[mh1]

Schau mal:
du hast jetzt also Datensätze aus tAuftrag (ich nenne das mal Menge A)
und Datensätze aus tAuftragsadresse (das nennen wir Menge B)

In deiner ursprünglichen Abrage nimmst du die gesamte Menge A und die gesamte Menge B und läßt diese nach irgendwelchen Kriterien verknüpfen. Wenn in A und B jetzt hunderttausende Datensätze drinstehen, muss der arme SQL-Server eben auch sehr viele Daten bewegen.

Mein Vorschlag war, nicht die gesamten Mengen verknüpfen zu lassen, sondern nur kleinere Teilmengen nämlich nur die Mengen, die dich interessieren.
Der SQL-Server muss dann nicht mehr so viele Daten bewegen (sortieren und zusammenführen).

Ich kann dir deine Abfrage nicht 100%ig erstellen, da ich nicht genau weiß, was in den Tabellen drin steht und wie dein Ergebnis aussehen soll. Darum kann ich nicht genau sagen, wie vernüpft werden soll (INNER JOIN, OUTER JOIN? LEFT, RIGHT?).
Aber vom Prinzip so:

SELECT * FROM
   (SELECT * FROM Verkauf.tAuftrag WHERE cAuftragsNr='2020093040389AB') A
JOIN
   (SELECT * FROM Verkauf.tAuftragAdresse WHERE nTyp = '0') B
ON B.kAuftrag = A.kAuftrag

 

[s.broeker]

Ah also, das finde ich interessant, habe das auch direkt mal mit zwei, drei anderen Tabellen getestet, und muss zugeben der Unterschied ist wirklich zu merken, ich habe das einfach mal mit einer großen Tabelle getestet und

SET STATISTICS TIME ON;

mal aktiviert. Man konnte es wirklich messen und der Unterschied ist wirklich auch merkbar. In meinem Test habe ich die Abfrage mit einer Tabelle mit 600.000 Datensätzen ausprobiert und habe fast 9ms Ersparnis.

Bei dem Beispiel mit den Adressen ist der Unterschied nicht messbar, da beide Abfragen 0ms ausgeben
CPU-Zeit = 0 ms, verstrichene Zeit = 0 ms.

Aber vielen Dank für deinen Tipp, ich werde mich mal damit mehr beschäftigen. Ist ein interessantes Thema, finde ich.

 

[mh1]

Ja, die Thematik ist interesant.
Bei den SQL Abfragen bzw. deren Optimierung kann man teilweise erstaunliche Oprimierungen erzielen.
Das und die richtige Indizierung sind effektive Tuning Möglichkeiten bei Datenbanken. Wobei du natürlich im Falle JTL keinen Einfluss auf die Indizierung hast.

 

[sebjo82]

Deswegen stehen gute SQL-Programmierer auch immer hoch im Kurs