Designproblem wegen Thread oder Datenbankviews



  • Für einen Primary Key wird automatisch ein Index angelegt, ja.
    Was für eine DBS benutzt du denn?
    Sind in deinen Abfrageb sehr viele JOINs usw.?

    Wie speicherst du die Daten zwischen? Nicht das auch noch viel Zeit beim Allokieren in deinem Programm draufgeht.



  • Pellaeon schrieb:

    Für einen Primary Key wird automatisch ein Index angelegt, ja.

    Puh, doch was gelernt. 🙂

    Was für eine DBS benutzt du denn?

    Microsoft SQL Server 2000 SP3 Desktop Edition (Ja, ich weiß es gibt ne neuere, aber wie kompatibel die ist, kann mir keiner 100%ig sagen...

    Sind in deinen Abfrageb sehr viele JOINs usw.?

    Im Gegenteil, bisher mache ich 99% ohne Views. Jedes Recordset ist eine Tabelle die sich dann den Rest "erfragt".
    Views wären jetzt mein Ansatz, um es schneller zu kriegen.

    Wie speicherst du die Daten zwischen? Nicht das auch noch viel Zeit beim Allokieren in deinem Programm draufgeht.

    Das läuft alles über lokale Recordsets in der jeweiligen Funktion.
    Ich fürchte, genau das ist es und forsche auch schon in der Richtung. Nur nach was muss man da suchen und wie wird es schneller? 😕



  • Wieviel Datensätze liefert denn eine Abfrage? Ist das sehr viel? Und speicherst du die dann in einem vector, oder wird das gleich weiter verarbeitet?



  • Also, in den Fällen liefert jede Abfrage nur einen Datensatz (weil ich auf eine bestimmte ID abfrage).
    Der Datensatz meldet sich dann beim Druckprogramm (ist eine Funktion in den Recordsets), läd ggf. noch abhängige Daten nach und veranlasst deren Weitergabe ans Druckprogramm und wird danach wieder vergessen.


  • Mod

    Wenn Du einen primären Schlüssel hast, dann ist dieser ID auch clustered und indiziert!

    Die Frage wäre: Benötigst Du die ganzen Queries einzeln, oder kann Dir das System die Daten einfacher liefern?
    Welchen Cursor Typ verwendest Du? Das hat immensen Einfluss auf die Geschwindigkeit!
    Hast Du mal den SQL Profiler mitlaufen lassen?

    Es ist in jedem Fall besser wenn man dem SQL Server weniger Anfragen stellt und möglichst viele Daten in einem Rutsch zurückbekommt (JOINs).
    Eine komplette komplexe Abfrage kann der SQL Server oft besser optimieren.



  • Martin Richter schrieb:

    Die Frage wäre: Benötigst Du die ganzen Queries einzeln, oder kann Dir das System die Daten einfacher liefern?

    Was wäre einfacher? Ich fand das bisher immer einfach. 😉

    Welchen Cursor Typ verwendest Du? Das hat immensen Einfluss auf die Geschwindigkeit!

    Ich verwende den Defaulttyp. Ich habe es aber eben mal mit CRecordset::forwardOnly versucht, da bekomme ich:
    Connection is busy with results for another hstmt

    Hast Du mal den SQL Profiler mitlaufen lassen?

    Nein, da ich nicht weiß, nach was ich gucken muss.

    Es ist in jedem Fall besser wenn man dem SQL Server weniger Anfragen stellt und möglichst viele Daten in einem Rutsch zurückbekommt (JOINs).
    Eine komplette komplexe Abfrage kann der SQL Server oft besser optimieren.

    Das hatte ich befürchtet. 😞



  • So, ich habe jetzt wieder an einer Stelle 2 von 3 Querys gespart und das hat nochmal 3 Sekunden gebracht.
    Es wird wohl wirklich auf die Views hinauslaufen. 🙄



  • Hast Du denn schon mal geprüft, ob es sich lohnen würde noch andere Spalten, als die Primary Keys, zu indizieren? Oftmals hat man doch solche Anfragen wie:
    SELECT idFoo FROM foo WHERE foo.foo_name = 'bar'.
    Dann ist es meist besser auch foo_name zu indidzieren. Oftmals sind auch temporäre Tabellen das Problem, die müssen erst von Hand indiziert werden.


  • Mod

    forwardonly ist aber der schnellste Cursor Typ!



  • Martin Richter schrieb:

    forwardonly ist aber der schnellste Cursor Typ!

    Ich weiß, den Tip hast du mir schon mal gegeben. 🙂
    Leider scheint der Einschränkungen zu haben, die dann die Meldung verursachen und solange ich nicht weiß, was da genau schief läuft, muss ich den Default verwenden.

    connan schrieb:

    Hast Du denn schon mal geprüft, ob es sich lohnen würde noch andere Spalten, als die Primary Keys, zu indizieren? Oftmals hat man doch solche Anfragen wie:
    SELECT idFoo FROM foo WHERE foo.foo_name = 'bar'.
    Dann ist es meist besser auch foo_name zu indidzieren.

    An der kritischen Stelle wird wirklich ausschließlich nach den IDs gefiltert. 🙂
    Die Filterung nach anderen Spalten ist so selten, dass sie sich nicht lohnt.

    Oftmals sind auch temporäre Tabellen das Problem, die müssen erst von Hand indiziert werden.

    Ich glaube, soetwas verwende ich nicht. 😕



  • estartu schrieb:

    Oftmals sind auch temporäre Tabellen das Problem, die müssen erst von Hand indiziert werden.

    Ich glaube, soetwas verwende ich nicht. 😕

    Vieleicht ist das dann eine Lösung für dein Problem. Man hat dadurch den Vorteil, dass man sich keine Ergebnisse aus der Datenbank zurückgeben lassen muss um nachher mit diesen Daten wieder eine Anfrage zu starten (was ich immer sehr nervig finde 😉 ). Inwieweit sich dadurch ein Geschwindigkeitsvorteil ergibt habe ich noch nicht geprüft, würde ich in Deinem Fall aber versuchen.
    Das Statement sieht folgendermaßen aus:

    temp. Tabelle erstellen:

    CREATE TEMPORARY TABLE tmp_foobar (SELECT idFoo FROM bar,foo WHERE bar.idFoo = foo.idFoo )
    

    temp. Tabelle benutzen:

    SELECT * FROM tmp_foobar
    

    temp. Tabelle indizieren:

    ALTER TABLE `tmp_foobar` ADD INDEX `tmp_foobar_FKIndex1` ( `idFoo` )
    

    temp. Tabelle löschen:

    DROP TEMPORARY TABLE tmp_foobar
    

    Eine temporäre Tabelle an der richtigen Stelle kann das Leben ungemein vereinfachen 😉



  • Erst macht es Probleme und dann soll es die lösen... 😕
    Versteh einer diese Software. 😉

    Danke für die Befehlssammlung. 👍

    Wenn ich so eine Tabelle innerhalb einer Transaktion erstelle und wieder lösche, dann hat die ja kein anderer gesehen, oder?
    Mit Transaktionen verheddere ich mich aber immer schnell, gibt es da einen besseren Trick für die Tabellennamen?
    Weil es muss möglich sein, dass mehrere Leute gleichzeitig drucken können.

    Dadrüber muss ich mal nachdenken...



  • Diese Tabellen sind nur für den Sichtbar der sie erstellt, keine Sorge.

    Edit: Sofern jeder auch seine eigene Verbindung zu Datenbank hat!!


  • Mod

    Tabellennamen mit tmp voranzustellen ist nicht das was ich unter temporären Tabelen verstehe, die sich vor allem auch selbst wieder aufräumen.

    Siehe:
    Abschnitt Temporary Tables in
    http://msdn2.microsoft.com/en-us/library/aa258255(SQL.80).aspx

    Prefix local temporary table names with single number sign (#table_name), and prefix global temporary table names with a double number sign (##table_name).

    Temporary tables are automatically dropped when they go out of scope, unless explicitly dropped using DROP TABLE:

    A local temporary table created in a stored procedure is dropped automatically when the stored procedure completes. The table can be referenced by any nested stored procedures executed by the stored procedure that created the table. The table cannot be referenced by the process which called the stored procedure that created the table.

    All other local temporary tables are dropped automatically at the end of the current session.

    Global temporary tables are automatically dropped when the session that created the table ends and all other tasks have stopped referencing them. The association between a task and a table is maintained only for the life of a single Transact-SQL statement. This means that a global temporary table is dropped at the completion of the last Transact-SQL statement that was actively referencing the table when the creating session ended.
    A local temporary table created within a stored procedure or trigger can have the same name as a temporary table created before the stored procedure or trigger is called. However, if a query references a temporary table, and two temporary tables with the same name exist at that time, it is not defined which table the query is resolved against. Nested stored procedures can also create temporary tables with the same name as a temporary table created by the stored procedure that called it.



  • Hey Danke 😃 wieder was gelernt, hab ich allerdings so noch nie gesehen. Bei mir läuft aber auch ein mysql-Server 🙄 . Heißt das jetzt eigentlich, daß es beim microsoft-SQL-Server nur so funktioniert (mit #,##)?


Anmelden zum Antworten