"OR" im SelectStatement

[Furtbichler]

Zitat:

Zitat von jobo (Beitrag 1203609)

Zitat:

Zitat von Furtbichler (Beitrag 1203563)

Ein 'OR' kann auch ein Indiz für optimierungsbedürftiges Design sein.

AND genauso

Blödsinn. Bei weitem nicht 'genauso'.

[jobo]

Du formulierst in der ursprünglichen Aussage lediglich die Möglichkeit, und diese Aussage kann man genauso für 'AND' formulieren, ebenso wie für Group By oder andere Sprachkonstrukte.
Ich will mich aber gar nicht darüber streiten, ich wollte lediglich andeuten, wie pauschal und beliebig Deine Aussage ist, damit dann auch wenig hilfreich.

[Blup]

Zitat:

Zitat von p80286 (Beitrag 1203567)

Code:

where name='Schmitz'
  and (wohnort='Köln' or wohnort='Düsseldorf')

das halte ich für ein typisches 'OR' wie sollte da das Design geändert werden?

Gruß
K-H

Im günstigsten Fall gibt es einen gemeinsamen Index für beide Felder in der Reihenfolge name,wohnort,...
Nach meiner Erfahrung ist "in" deutlich problematischer als "or" (Speicherbedarf und Geschwindigkeit).

[Elvis]

Zitat:

Zitat von Blup (Beitrag 1203648)

Nach meiner Erfahrung ist "in" deutlich problematischer als "or" (Speicherbedarf und Geschwindigkeit).

Hö?
Entweder ist es exakt equivalent zu mehreren or- verknüpften Ausdrücen, oder es ist ein Sub-Select und hat damit nix mit der eigentlichen Frage zu tun.

Zum Thema:
Natürlich kann ein

Delphi-Quellcode:

or

in der reinen Theorie zu langsameren Abfragen führen weil, theoretisch, mehrere Ausdrücke evaluiert werden müssen.
Aber in der Praxis, ohne ganz spezielle Rahmenbedingungen, ist das doch ausgemachter Unsinn. Wenn du nunmal Datensätze haben willst, die dieses oder jenes enthalten, dann musst du das deinem DBMS auch so mitteilen.
Das Mittel hierfür ist nunmal

Delphi-Quellcode:

or

oder

Delphi-Quellcode:

in

[mkinzler]

Der einzige Unterschied zwischen and und or ist nur, dass and tendenziell die Ergebnismenge verkleinert und or vergrößert.