Announcement

Collapse
No announcement yet.

Left outer join oder SP

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Left outer join oder SP

    Hallo #,<p>
    folgendes habe ich hier:<br>
    1 Tabelle Project mit 5 Feldern, mit Verweis zu einer anderen Tabelle (Personal). Die Felder können NULL sein, oder auf einen Eintrag in der Personaltabelle verweisen.<br>
    Bei vielen Projekten dauert ein left outer join "etwas" lange, so dass ich bis jetzt das ganze über eine lokale Liste mache, wo alle Personen drinstehen. Die Liste wird bei dem Projekt durchlaufen, um die zugehrigen Personen zu ermitteln.
    <p>
    Das ist ein altes Paradox-Projekt (der Code kann immer noch für Wartungszwecke für Paradox compiliert werden).
    <p>
    Jetzt muß ich den Code für Interbase
    Ist ein left outer join oder eine SP (mit for select) schneller, um an alle 5 Personendaten ranzukommen. ? Die SP-Programmierung ist mir nicht geheuer (kein anständiger Debugger).
    <p>
    1000 Einträge Projekt, etwa 100 Personen.
    <p>
    Ich weiß ja, daß man die Datenmodellierung ändern sollte, also immer 0 reinschreiben, in der Personaltabelle eine Dummy-Person mit 0 und dann einen normalen join. Aber das schaffe ich zeitlich einfach nicht ;(
    <p>
    Wie würdet ihr rangehen ? Es muß schnell sein und einfach
    <p>
    Heiko

  • #2
    Hallo Heiko,

    das thema Datenmodellierung hast Du ja schon angesprochen. Deswegen sage ich dazu nichts.

    SP-Programmierung ist prinzipiell nicht so schwer. Bei IBExpert ist in der vollversion ein Debugger integriert. Da IB/FB jedoch keine Debugger-API haben muß der DB-Server praktisch simuliert werden. Demzufolge kann man sich nicht immer 100%ig auf die angezeigten Ergebnisse verlassen. ;-(

    Ich werde heute Abend mal ein wenig mit FB testen.

    Bei dem von Dir genannten datenvolumen sollte das aber alles noch nicht Performancekritisch sein.

    Gruß

    Torste

    Comment


    • #3
      Hallo Heiko,<br>

      1. StoredProcs sind <B>KEIN</B> Hexenwerk.
      Und Stored Proecures brauchen (wenn man einmal das Gefühl dafür bekommen hat) auch nicht debuggt zu werden, zumindest nicht, wenn es sich um relativ simple Selects handelt.<p>
      2. Deine Aussage: <br>
      <pre>Ich weiß ja, daß man die Datenmodellierung ändern sollte, also immer 0 reinschreiben, in der Personaltabelle eine Dummy-Person mit 0 und dann einen normalen join.</PRE><br>kann ich nicht nachvollziehen, sprich: das ist kein "gesundes" Datenmodell. Sind Deine Felder mit einem ForeignKey verbunden? Wenn ja, sollte ein LEFT OUTER JOIN kein Problem darstellen, meistens ist er sogar schneller als ein simpler JOIN.<br>
      Bei Deinem erwähnten Datenaufkommen ist es eh vollkommen irrelevant (100:1000 Relation ist keine grosse Datenmenge).<br>
      Generell bei Joins:<br>
      Die dazugejointe Seite wird (bei Verwendung von ForeignKeys) mit deren PrimaryKey-Index übernommen.<br>
      Bei der Hauptseite des Joins wird je nach WHERE oder ORDER BY-Anweisung ein Index gesucht, ist kein passender vorhanden, ist es NATURAL.<br>
      Wenn es Dir immer noch zu langsam ist, kannst du es ja mal mit einem INNER select probieren, also zB.:<br><PRE>
      SELECT
      T1.FELD,
      ( SELECT T2.FELD FROM T2 WHERE T2.JOINFLED = T1.JOINFELD )
      FROM TABELLE1 T1</PRE>
      Dies ist allerdings eher für kleine Lookup-Tabellen gedacht.<br>
      Also: einfach mal ausprobieren - aber ein Join, wie Du ihn beschrieben hast, sollte selbst von einem PentiumII mit 64MB RAM in ein paar Millisekunden aufgebaut und abgearbeitet sein ;-)
      <p>Luc

      Comment


      • #4
        Hallo Heiko und Luc,

        ich habe es testweise mit FB 1.5 probiert.
        Frisch gebooteter Rechner inklusive Fetch all etwas über 200 Millisekunden.

        In jeder Spalte waren ca. 20% der Datensätze auf "null" gesetzt.

        @Lucas: das SP nicht debuggt werden müssen ist ja wohl ein Witz?

        Gruß

        Torste

        Comment


        • #5
          @Torsten:
          Also Du willst mir doch nicht erzählen, dass eine StoredProcedure, die das SELECT für einen Join abnimmt, debuggt werden muss...<p>
          Luc

          Comment


          • #6
            Hallo Luc,

            natürlich nicht. Aber es gibt ja auch etwas umfangreichere SP. ;o)

            Gruß

            Torste

            Comment


            • #7
              Sicherlich gibt es die.<br>
              Aber andererseits gibt es StoredProcedures auch schon erheblich länger, als es Debugger-Tools (wie zB IBExpert, etc.) gibt.<br>
              Was nicht heissen soll, dass man sich nicht auch ohne Debugger behelfen kann :-)<p>
              Luc

              Comment


              • #8
                Hallo Luc,

                ich weiß, man kann auch alles in einer Logtabelle mitschreiben oder eine UDF verwenden. Das ist aber etwas umständlich für mich als faulen Programmierer. ;-)

                Gruß

                Torste

                Comment


                • #9
                  Hallo ihr 2 ,<p>
                  also in meinem Fall dauert ein join 50 ms, ein left outer join 500 ms.<br>
                  Bedenkt man, dass der Server nicht für mich alleine arbeitet , diese Abfragen von mehreren Clients gestartet werden, dann bringt jede Millisekunde etwas.<p>
                  Ganz unbeleckt bin ich bei sp's nicht, nur das debuggen war etwas schwierig im Vergleich zum schönen Delphi-Debugger.<br>
                  In einem Fall hatte ich 5 left outer joins in der Query (das ging nicht anders, keine Fehler im Datenmodell !). <br>Durch Einsatz einer SP war das Ding dann 10mal schneller *freu*
                  <p>
                  Der Kunde war zufrieden, bis zum nächsten Performance-Problem.
                  <p>
                  Heik

                  Comment

                  Working...
                  X