Ergebnis der Suchanfrage

• Forum: Datenbanken

  AW: SQL optimieren

   
    by jobo, 22. Sep 2016
  @naphets: Die Lösung find ich auch ok, ich würde meinen Erfahrungen nach allerdings meine Version für "besser"/schneller halten. Die gelten aber eigentlich nicht für große Mengen an Firebirddaten.
  Letztlich zählt, was der Optimizer des jeweilgen DB Systems draus macht.
  
  Meine Strategie wäre letztlich, Menge Tabelle 1 soweit wie möglich eindampfen (mglw über inneres Select), dann Ergebnis mit...
• Forum: Datenbanken

  AW: SQL optimieren

   
    by jobo, 22. Sep 2016
  Also ich habe es so verstanden, dass beide Felder "Hauptnummer" und "Ergänzung" notwendig Join Kriterien sind. Die "anschließende" Null Prüfung auf Feld "Tabelle2.Ergänzung" dient der Feststellung, dass kein Datensatz passender gefunden wurde. (Was auch mit jedem anderen Feld der Tabelle2 möglich wäre, da es ja genau um die nicht gefundenen geht)
• Forum: Datenbanken

  AW: SQL optimieren

   
    by jobo, 22. Sep 2016
  Darum ging es aber doch oder?
  
  man kann es wie schon geposted auch mit not exists machen, mit einem Join plus Not Null Prüfung läuft es aber in dieser Form vermutlich besser.
• Forum: Datenbanken

  AW: SQL optimieren

   
    by jobo, 22. Sep 2016
  Wieviel sind denn "wirklich viele" und wie wenig sind in Tabelle 1 (inkl. der Where Bedingungen?)
  
  Bezüglich der "Indexe überall", viel hilft nicht unbedingt viel. "Storno is null " bringt mit Index eher keine zusätzliche Performance. An solchen Stellen (vermuteter Charakter eines Feldes, das Storno genannt wird) bietet sich die Arbeit mit expliziten Werten an. Also 0/1, True/false oder sowas....