Firebird IN, EXISTS Langsam

[Gruber_Hans_12345]

Zitat von jobo:

Ich glaub, Du hast mich falsch verstanden. Es ging mir nicht ums Group, das innere Statement ist ja nur eine Kopie des von mir favorisierten Statement von TBx. Ich hab lediglich das "V_AUFTRAG_PO" gegen "POSITION" getauscht, um zu verdeutlichen, dass Du den komplexen View erstmal beiseite lässt.

Hast Du Dir mal den Optimizer Link angeschaut?

JA, das problem ist die komplexe Abfrage mit 3 Tabellen per Joins ist in der inneren SQL - Also dort wo geschaut wird, ob diese Artikel in der Positions Tabelle verhanden sind (Verlinkt mit Auftrag Tabelle und einer Auftrags informations Tabelle) deshalb ist es da problematisch ...

... habs zwar gelesen, aber hab mir nicht wirklich was raussuchen können, was mir helfen könnte in diesem fall


Ich habe einfach das problem, das so eine "primitive" sache, wo es eigentlich nur darum geht eine SELECT zu machen (die 0.05 sekunden dauert) und von dieser dann ID's aus einer anderen Abfrage abzuziehen (die auch 0.05 sekunden dauert) - das dann 26 sekunden dauert ... das geht enfach nicht in meinen kopf, das man das nicht mit "normalen einfachen" SQL Mitteln zumindest auf 0.5 Sekudnen oder so optimieren kann
Und das müsste ja eigentlich auch OHNE einen Index auf Artikel_ID funktionieren ... (Schon klar ich werde morgen den Index drauf legen ... aber ist mir noch immer nicht ganz logisch, das es nicht ohne den geht ... )

[omata]

Deine DB-Struktur sieht also folgendermaßen aus...

SQL-Code:

CREATE TABLE artikel (
  artikel_id int,
  CONSTRAINT PK_artikel 
    PRIMARY KEY (artikel_id)
);

CREATE TABLE position (
  position_id int,  
  CONSTRAINT PK_position 
    PRIMARY KEY (position_id)
);

CREATE TABLE artikel_position (
  artikel_id int,
  position_id int,  
  CONSTRAINT PK_artikel_position 
    PRIMARY KEY (artikel_id, position_id),
  CONSTRAINT FK_artikel_position_artikel 
    FOREIGN KEY (artikel_id) REFERENCES artikel (artikel_id),
  CONSTRAINT FK_artikel_position_position 
    FOREIGN KEY (position_id) REFERENCES position (position_id)
);

Ist das richtig?

[Gruber_Hans_12345]

Also das ist die original Abfrage

Code:

SELECT A.ARTIKELNUMMER 
FROM ARTIKEL A
/*Hier wäre noch joins drinnen, aber die habe ich mal weggelassen, da diese keine zeit in anspruch nehmen */
WHERE A.ID NOT IN
(
SELECT T.ARTIKEL_ID
FROM AUFTRAG VA, AUFTRAG_INFO AF, POSITIONEN T
WHERE (AF.ID = VA.INFO_ID) AND (T.AUFTRAG_ID = VA.ID) AND (VA.MesseSTATUS > 0)
AND ((CAST(AF.MesseBis AS Date) >= CURRENT_TIMESTAMP) And (Cast(AF.MesseVon AS Date) <= CURRENT_TIMESTAMP + 10))
)

[EDIT}Also das erzeugen eines Index auf POSITIONEN(ARTIKEL_ID) hat es gebracht ... nun dauerrts ca 0.05 sekunden ... ich verstehe zwar nicht warum er das braucht aber, vielleicht merke ich es mir nun .... [/EDIT]

[omata]

Schade, das du keine Fragen beantwortest. Naja, dein Problem ist ja gelöst, verstehen wird auch überbewertet.

[Gruber_Hans_12345]

Zitat von omata:

Schade, das du keine Fragen beantwortest. Naja, dein Problem ist ja gelöst, verstehen wird auch überbewertet.

Also dachte mit meiner original Abfarge wäre es so halbwegs geklärt wie die DB aussieht ....

so versuche es noch einmal :

Code:

CREATE TABLE ARTIKEL (
  ID INTEGER NOT NULL
, ARTIKELNUMMER VARCHAR(100)
, PRIMARY KEY("ID"));

CREATE TABLE AUFTRAG (
  ID INTEGER NOT NULL
, MesseBis TIMESTAMP
, MesseVon TIMESTMAP
, PRIMARY KEY("ID"));

CREAT TABLE AUFTRAG_INFO  (
  ID INTEGER NOT NULL
, INFO_ID INTEGER
, MESSESTATUS INTEGER
, PRIMARY KEY("ID"));

CREATE TABLE POSITIONEN  (
  ID INTEGER NOT NULL
, AUFTRAG_ID INTEGER
, ARTIKEL_ID INTEGER
, PRIMARY KEY("ID"));

[idefix2]

Zitat:

ich verstehe zwar nicht warum er das braucht aber, vielleicht merke ich es mir nun

Die SQL Engine muss doch für jede Artikel id prüfen, ob diese Artikel id in der Positionen Tabelle (nicht) vorkommt. Für jede Artikel id muss sie also die Positionen Tabelle durchgehen und schauen, ob die Artikel id vorkommt. Wenn ein Index auf die Artikel id vorhanden ist, geht das fast in Nullzeit, andernfalls muss sie aber im Schnitt die halbe Positionen Tabelle durchsuchen für Artikel Ids, die sie findet, und immer die ganze Tabelle, wenn eine Artikel Id nicht vorkommt, weil ja erst nach dem Durchsuchen der ganzen Tabelle feststeht, dass die Artikel id nicht vorkommt.

[tsteinmaurer]

Hallo,

es sind hier keine Foreign-Key Constraints angegeben. Würden FK-Constraints angelegt worden sein, dann wären automatisch auch auf den entsprechenden FK-Felder Indizes sein und das Performance-Problem wäre nie entstanden.

Nur so ein Gedanke.

Thomas

[omata]

Zitat von tsteinmaurer:

Würden FK-Constraints angelegt worden sein, dann wären automatisch auch auf den entsprechenden FK-Felder Indizes sein und das Performance-Problem wäre nie entstanden

Genau darauf wollte ich hinaus