Kurz Forum es geht. Es gibt eine (Access)-Datenbank mit Hörbüchern/Hörspielen, die der User per Web einsehen und nach mehreren Kriterien (Genre, Typ...) sortieren kann.
Zudem kann er einen Titel als bereits gehört makieren oder in seine Favoriten (also nicht die IE-Fav's ) packen.
Als kleine "Stöberergänung" kann er dann bei der Suche auch als Kriterium angeben, dass er keine Favoriten bzw. bereits gehörten angezeigt bekommt.
Also ich habe folgende SQL-Abfrage:
Code:
SELECT autor_vorname,autor_nachname,Titel, Genre, Sprache, Lesung, gekuertzt, id,
Date_Added, Auf_Platte
FROM audiobooks
WHERE ID>0
AND id NOT IN (SELECT AbHeardID FROM Audiobooks_User_Heard WHERE userID=13)
AND id NOT IN (SELECT RememberID FROM Audiobooks_User_Remember WHERE userID=13)
ORDER BY Autor_Nachname, Autor_Vorname, Sprache, Titel
Das ist jetzt eine Abfrage ohne weitere Eingrenzungen ausser, dass keine Fav's/Gehörten angezeigt werden sollen (der rot makierte Teil).
Das Problem ist, dass er bei 1900 Titeln etwa 6-7 Sekunden braucht um diese Abfrage durchzuführen (Prozessorlast beim P3 600 auf 100%), d.h. er braucht für ca. 250 Datensätze eine Sekunde. Find ich etwas krass!
Kann man jetzt die SQL-Abfrage sinnvoller stellen um nur die Titel in der Tabelle "Audiobooks" die keine Entsprechung bei 'UserID' und 'TitelID' in den Tabellen "Audiobooks_User_Heard" (als gehört eingetragen) und "Audiobooks_User_Remember" (Favoriten) haben?
Wenn sich jemand schon bishier durchgekämpft hat schonmal danke
Also comments zur Prozessorlast sind reine Spekulation
Falls Du da alle Felder der Tabelle audiobooks ausliest,
wäre vermutlich ein * sinnvoller (probiere, messe Zeit)
Ich vermute das deine Abfrage schneller laufen würde,
wenn Du zuerst die ausgeschlossenen ID's ermittelst
und dann die Felder von audiobooks ausliest.
Oder Du liest 'Select * FROM audiobooks' ein und
blendest nur die Anzeige der max. 2 Datensätze aus
(welche vorher mittels Abfrage in eine Variable kommen
und dann mittels if Bedingung nicht angezeigt werden)
Nun wiederhole ich mich hier erstmals:
Im Zweifel hilft ein vollständiges Beispiel
Original geschrieben von HeikoBerlin Also comments zur Prozessorlast sind reine Spekulation
Naja, die dllhost.exe geht genau bei der Abfrage für x Sekunden auf 100%...
Zitat:
Falls Du da alle Felder der Tabelle audiobooks ausliest,
wäre vermutlich ein * sinnvoller (probiere, messe Zeit)
Nein tu ich nicht, aber im Grunde ist es trotzdem sicher nicht falsch insofern nur wenige Felder nicht genutzt werden
Zitat:
Ich vermute das deine Abfrage schneller laufen würde,
wenn Du zuerst die ausgeschlossenen ID's ermittelst
und dann die Felder von audiobooks ausliest.
Das versteh ich nicht ganz. Ermitteln kann ich die zwar, aber wenn ich hundert ausgeschlossene ID's habe - wie soll ich die dann filtern ohne eine SQL-Abfrage mit 100 "AND id <>'xy'" (die zudem nicht genommen wird, weil zu komplex)?
Zitat:
Oder Du liest 'Select * FROM audiobooks' ein und
blendest nur die Anzeige der max. 2 Datensätze aus
(welche vorher mittels Abfrage in eine Variable kommen
und dann mittels if Bedingung nicht angezeigt werden)
Naja, sind schon mehr als zwei und da ergibt sich das selbe Problem wie oben
Zitat:
Nun wiederhole ich mich hier erstmals:
Im Zweifel hilft ein vollständiges Beispiel
Hmm, also ich häng mal die zwei ASP-Seiten (Formular+Suche) an und das Layout der DB, aber ob das hilft?
nur mal so generell in's Blaue geraten:
in audiobooks sollte id Teil des Primärschlüssels sein
in Audiobooks_User_Heard sollten AbHeardID und userid zusammen den Primäschlüssel bilden.
in Audiobooks_User_Remember sollten RememberID und userid zusammen den Primäschlüssel bilden.
in audiobooks könnte ein gemeinsamer Index auf Autor_Nachname, Autor_Vorname, Sprache und Titel Sinn machen.
Eventuell lässt sich noch durch eine Union-Abfrage etwas beschleunigen (es kann aber auch langsamer werden, jenachdem ob intern eine temporäre Tabelle auf Platte angelegt wird).
Code:
SELECT autor_vorname,autor_nachname,Titel, Genre, Sprache, Lesung, gekuertzt, id,
Date_Added, Auf_Platte
FROM audiobooks
WHERE ID>0
AND id NOT IN (SELECT AbHeardID FROM Audiobooks_User_Heard WHERE userID=13
UNION SELECT RememberID FROM Audiobooks_User_Remember WHERE userID=13)
ORDER BY Autor_Nachname, Autor_Vorname, Sprache, Titel
Was auch klappen könnte ist folgendes etwas unansehnliche Konstrukt (kann allerdings wegen dem OR auch schlimmer werden):
Code:
SELECT
audiobooks.autor_vorname,
audiobooks.autor_nachname,
audiobooks.Titel,
audiobooks.Genre,
audiobooks.Sprache,
audiobooks.Lesung,
audiobooks.gekuertzt,
audiobooks.id,
audiobooks.Date_Added,
audiobooks.Auf_Platte
FROM
audiobooks
left join Audiobooks_User_Heard on audiobooks.id=Audiobooks_User_Heard.AbHeardID
left join Audiobooks_User_Remember on audiobooks.id=Audiobooks_User_Remember.RememberID
where Audiobooks_User_Heard.AbHeardID is NULL
OR Audiobooks_User_Remember.RememberID is NULL
Erklärung: merkwürdig sieht zwar aus, dass id = AbHeardID sein soll und AbHeardID = NULL, aber bei einem left join stimmt das erste = nicht wirklich, deshalb wird alles rausgefiltert, wo AbHeardID nicht drin ist.
Viel Spass beim Experimentieren, ich habe den Kram nicht getestet.
Navigation
SQL-Syntax "verfeinern" - wer mal gucken will
) packen.
Linear-Darstellung
