[SQL] Efficiente query-iterator

[oogapp0ltje]

Ik wil de performance van mijn SELECT queries op een zeer grote database verbeteren door de resultaten van een query in een interval te omschrijven. Hiervoor denk ik dat het het beste is om de gemiddelde spreiding van ID's uit mijn tables te berekenen (deze zijn niet altijd opeenvolgend) en deze als opeenvolgende limiet te stellen.

het is de bedoeling dat je zoiets krijg als:

code:

select i.id, i.universalname, i.secondid, i.comments as universe
 from items i WHERE i.id >= LOID AND i.id < HIID ORDER BY i.id

LOID en HIID vervang ik in mijn java-code door de intervalswaarden, ik weet alleen niet hoe ik deze kan berekenen de query zelf kan aangepast worden, werken met stringfuncties heeft in mijn geval helaas geen zin, ik gebruik mysql 4.1 dus misschien kan ik het oplossen dmv subqueries?

Bijvoorbaat dank voor jullie informatie

[The Eagle]

Ik zou als ik jou was het probleem eerst een zoeken in indexen en unieke keys. Dat wil vaak heel veel schelen, ipv de query te optimizen

[Verwijderd]

Bedoel je dat je record paging wil maken?

[Soultaker]

Waarom wil je nu precies die limieten gebruiken? Wil je niet liever een LIMIT clause gebruiken? Dat is minstens net zo efficient en een stuk minder gedoe.

[oogapp0ltje]

Soultaker schreef op vrijdag 30 september 2005 @ 14:45:
Waarom wil je nu precies die limieten gebruiken? Wil je niet liever een LIMIT clause gebruiken? Dat is minstens net zo efficient en een stuk minder gedoe.

LIMIT of die WHERE clause komen volgens mij op hetzelfde effect neer, echter wil ik dat de queries voldoen aan de SQL standaard, LIMIT(n1, n2) hoort daar niet bij.

[whoami]

Hmm, waarom wil je persé dat de queries aan de sql standaard voldoen ?
Zo mis je heel wat functionaliteit....

[oogapp0ltje]

Verwijderd schreef op vrijdag 30 september 2005 @ 14:37:
Bedoel je dat je record paging wil maken?

Bedankt voor je tip, ik heb even gegoogle't op deze term en heb inderdaad de oplossing gevonden binnen Java.

code:

PreparedStatement StatementrsEvents = connection.prepareStatement(  
queryText, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE);

StatementrsEvents.setFetchSize(maxNmbrOfQueries);
StatementrsEvents.setMaxRows(maxNmbrOfQueries);

ResultSet resultSet = StatementrsEvents.executeQuery();

Helaas zit ik nu met het probleem dat Java out of HEAP space raakt door het processen van de grote database (1,5 miljoen records).

[oogapp0ltje]

whoami schreef op vrijdag 30 september 2005 @ 15:16:
Hmm, waarom wil je persé dat de queries aan de sql standaard voldoen ?
Zo mis je heel wat functionaliteit....

Om de compatibiliteit met andere DBMSen te vegroten.

[whoami]

Ravenof schreef op vrijdag 30 september 2005 @ 15:18:
[...]

Om de compatibiliteit met andere DBMSen te vegroten.

Mja, dan ben je imo op de verkeerde manier bezig.
Als je op deze manier de compatibiliteit wilt verhogen, ben je 'masochistisch' bezig. Je moet je dan idd aan de standaard houden, en dan moet je soms heksentoeren uithalen, terwijl er in iedere implementatie wel een functie voor bestaat.
Je kan dan beter voor ieder DBMS dat je wilt ondersteunen, en andere DAL laag schrijven.

[Soultaker]

Ravenof schreef op vrijdag 30 september 2005 @ 14:47:
[...]
LIMIT of die WHERE clause komen volgens mij op hetzelfde effect neer, echter wil ik dat de queries voldoen aan de SQL standaard, LIMIT(n1, n2) hoort daar niet bij.

Maar LIMIT n toch wel? Als je dan alleen van voren naar achter de lijst wil doorlopen kun je ID > i LIMIT n doen, waarbij n het aantal rijen is dat je wil hebben en i het laatste id van je vorige batch. Je neemt dan steeds de volgende 'n' rijen. (Maar dat werkt niet als je een batch 'uit het midden' wil nemen natuurlijk).

[ Voor 6% gewijzigd door Soultaker op 30-09-2005 16:09 ]

[Varienaja]

Soultaker schreef op vrijdag 30 september 2005 @ 16:07:
Maar LIMIT n toch wel?

Op MySQL en PostgreSQL heb je de LIMIT n functie.
Bij Oracle doe je 'WHERE rowid<n'
Bij DB2 doe je 'FETCH FIRST n ROWS ONLY'

En inderdaad: met een DAL (zoals Hibernate) ben je van al het gelazer af, en werkt je query (in het geval van Hibernate schrijf je dan HQL ipv SQL) op alle ondersteunde databaseplatforms.