Params im ADOQuery nicht angenommen.

[Leuselator]

[Edit]Und auch hier habe ich noch nicht nachgedacht:[/Edit]
Hi Alex!

Ich verstehe Deine Ausführungen, aber in Bezug auf Die Query muß ich bei meiner Einschätzung bleiben - sie ist definitiv gleich select * from Stopper - d.h. Du erreichst das gewünschte Ziel so nicht.
Was Du tust ist nämlich:

Select * from Tabelle Where Bedingung
+
Select * from Tabelle Where nicht Bedingung
=
Select * from Tabelle ohne Bedingung

Wenn Du mir eine Tabellendefinition gibst, formulier ich Dir gern ein Statement, das auch tut, was Du von ihm erwartest.

Gruß

[ahachmann]

Das Statement funktionert bei mir aber.
Die WHERE NOT EXISTS Bedinung gibt true oder false zurück, je nachdem ob schon ein Röhrchen in der Tabelle der r_articlesproduct ist oder nicht. Sobald keines mehr drinne ist, wird WHERE NOT EXISTS immer True und alle Stopper werden ausgegeben. Wenn nun aber ein Röhrchen in der Relation drinne ist, dann ist es immer false. Somit wird das UNION Select leer sein und nur die Obere Select Anweisung wirft Datensätze aus.
Aber für Bessere Lösungen bin ich immer offen.

Vielen Dank,
Alexander

[Robert_G]

OffTopic:
Wie interpretiert die DB diese Statements (vorsicht sehr lang!)

DB: Oracle

Der dargestellte "explain plan" zeigt in welcher Reihenfolge welche Operation ausgeführt wurde.


Not Exists mit SELECT *

SQL-Code:

SELECT t.PkSeq,
       t.PkDTc,
       t.PkYN,
       t.PkHH,
       t.PkMM,
       t.PkDT,
       t.PkTM,
       t.SubKey
FROM   MM07.PKPROFLO_update t
WHERE  Not Exists (SELECT *
                   FROM   MM07.ENROLL_data e
                   WHERE  e.Subject_ID = t.Subject_ID)
ORDER  By t.PkSeq

Optimizer Plan:

Code:

                                             Cost  Cardinality  Optimizer       Options         Operation            Timestamp           Bytes    
SELECT STATEMENT, GOAL = CHOOSE                 3       1       CHOOSE                          SELECT STATEMENT     17.02.2004 15:53:50            101    
 SORT ORDER BY                                  3       1                       ORDER BY        SORT                 17.02.2004 15:53:50            101    
  FILTER                                                                                        FILTER               17.02.2004 15:53:50                
   TABLE ACCESS FULL   MM07   PKPROFLO_UPDATE   1       1       ANALYZED        FULL            TABLE ACCESS         17.02.2004 15:53:50            101   1 
   INDEX UNIQUE SCAN   MM07   ENROLL_DBIDX      1       1                       UNIQUE SCAN     INDEX                17.02.2004 15:53:50            3

__________________________________________________ __________________________________________________ _______________________

Not Exists mit SELECT 1 num. Spalte

SQL-Code:

SELECT t.PkSeq,
       t.PkDTc,
       t.PkYN,
       t.PkHH,
       t.PkMM,
       t.PkDT,
       t.PkTM,
       t.SubKey
FROM   MM07.PKPROFLO_update t
WHERE  Not Exists (SELECT e.Subject_ID
                   FROM   MM07.ENROLL_data e
                   WHERE  e.Subject_ID = t.Subject_ID)
ORDER  By t.PkSeq

Optimizer Plan:

Code:

SELECT STATEMENT, GOAL = CHOOSE                 3       1       CHOOSE                          SELECT STATEMENT     17.02.2004 15:54:08            101    
 SORT ORDER BY                                  3       1                       ORDER BY        SORT                 17.02.2004 15:54:08            101    
  FILTER                                                                                        FILTER               17.02.2004 15:54:08                
   TABLE ACCESS FULL   MM07   PKPROFLO_UPDATE   1       1       ANALYZED        FULL            TABLE ACCESS         17.02.2004 15:54:08            101   1 
   INDEX UNIQUE SCAN   MM07   ENROLL_DBIDX      1       1                       UNIQUE SCAN     INDEX                17.02.2004 15:54:08            3

__________________________________________________ _________________________________

Not in (SELECT...)

SQL-Code:

SELECT t.PkSeq,
       t.PkDTc,
       t.PkYN,
       t.PkHH,
       t.PkMM,
       t.PkDT,
       t.PkTM,
       t.SubKey
FROM   MM07.PKPROFLO_update t
WHERE  t.Subject_ID Not In (SELECT e.Subject_ID
                            FROM   MM07.ENROLL_data e)
ORDER  By t.PkSeq

Optimizer:

Code:

SELECT STATEMENT, GOAL = CHOOSE                 3       1       CHOOSE                          SELECT STATEMENT     17.02.2004 15:54:08            101    
 SORT ORDER BY                                  3       1                       ORDER BY        SORT                 17.02.2004 15:54:08            101    
  FILTER                                                                                        FILTER               17.02.2004 15:54:08                
   TABLE ACCESS FULL   MM07   PKPROFLO_UPDATE   1       1       ANALYZED        FULL            TABLE ACCESS         17.02.2004 15:54:08            101   1 
   INDEX UNIQUE SCAN   MM07   ENROLL_DBIDX      1       1                       UNIQUE SCAN     INDEX                17.02.2004 15:54:08            3

[Robert_G]

Wie man sieht, ist es für die DB egal, ob man not in () oder not Eists() verwendet.
"In ()" und "Exists ()" sind aber nicht äquivalent!!!

[ahachmann]

Ähh, da hast Du halb recht.
Denn SELECT * FROM Stopper WHERE NOT EXISTS () ist was anderes als
SELECT * FROM Stopper WHERE article_id NOT IN ().

Die Obere Bedingung verknüpft nicht mit einem Attribut im SELECT, sondern ist WHERE 1 oder WHERE 0;
Somit werden alle angezeigt, wenn es keine Tube in r_articlesproduct gibt.

Wenn es welche gibt, muß dann noch die Bedingung artcile_id NOT IN () stimmen.
Somit ist es nicht die direkte verneinung.

(A ^ B) v (C ^ not B)

A = Select FROM Stopper Where NOT EXISTS B
C = Select FROM Stopper Where article ID IN B
B = Die Menge der Röhrchen die Zu dem Produkt gehören.


gruß,
Alexander

[Robert_G]

Es ging mir hauptsächlich darum, dass ein Select * in einen NOT Exists nicht langsamer als ein Select ID ist.
Ich habe einfach eine Abfrage genommen, die ich gerade in irgendeinem Fenster hatte und habe sie danch umgeformt.
Im diesem Fall sind alle 3 Abfragen absolut identisch!

[Leuselator]

@George: das wiederum hängt stark vom Optimizer der verwendeten DB ab, und ist somit keine verläßliche Größe - das mit dem Stern kann man sich abgewöhnen. Tut nicht weh. und ist im Zweifel schneller. Und gerade bei komplexeren Querys kann man somit dem Optimizer (so er vorhanden/gut ist) unter die Arme greifen.

[Leuselator]

@ahachmann: Ich muß Abbitte leisten! Du hast Recht, was das Not Exists angeht.
Da hatte Ich einen Knoten im Kopf der in Richtung: "where id not in(...)" ging.
Sorry!
*AschekübelNimmtUndÜberKopfStülpt*
Gruß

[Leuselator]

Jeweils 1 join eingespart:

SQL-Code:

    SELECT S.*
      FROM r_articleproduct AP

INNER JOIN r_tubestopper TS
        ON TS.tube_id = AP.article_id

INNER JOIN stopper S
        ON S.article_id = AP.article_id
       AND S.article_id = TS.stopper_id

     WHERE AP.name = 'test'

UNION

     SELECT *
       FROM stopper

      WHERE NOT EXISTS(     SELECT S.*
                              FROM r_articleproduct AP
                        INNER JOIN r_tubestopper TS
                                ON TS.tube_id = AP.article_id
                        INNER JOIN stopper S
                                ON S.article_id = AP.article_id
                               AND S.article_id = TS.stopper_id
                             WHERE AP.name = 'test'
                       )

[Edit]Konnte auf diese Abkürzung nur kommen, weil mir ahachmann per PN das DB-Modell
zukommen lassen hat - aus dem ursprünglichen Post wäre man wohl nicht darauf gekommen.[/Edit]
*BlamageSchweissVonStirnWischt*
Gruß