[MSSQL] SELECT elk 3e resultaat

[JSchut]

Ik heb een simpele query

code:

SELECT
    name
FROM
    table
WHERE 
    parent=1
ORDER BY
    name

Nu wil ik alleen resultaten 1,4,7,10,13 enz hebben.... hij moet er telkens 2 overslaan..... is dit in de query zelf in te bakken?
Ik heb al geprobeerd het rijnummer er uit te krijgen maar dat lukt ook niet

[Feyd-Rautha]

Misschien kun je er een Stored Procedure voor schrijven, hand in hand met een cursor.

[JSchut]

Feyd-Rautha schreef op 22 april 2004 @ 12:54:
Misschien kun je er een Stored Procedure voor schrijven, hand in hand met een cursor.

Zou je dit iets toe willen lichten?

[easydisk]

Misschien kan je inbakken dat dat id = 1 + "Een getal is deelbaar door 3, als de som van de cijfers deelbaar is door 3."

[ Voor 7% gewijzigd door easydisk op 22-04-2004 12:58 ]

[cameodski]

Je kunt je data eerst in een temporary table zetten waarin een autonumber kolom (IDENTITY) zit.
Op die manier heb je dan een soort rijnummers.

Feyd-Rautha schreef op 22 april 2004 @ 12:54:
Misschien kun je er een Stored Procedure voor schrijven, hand in hand met een cursor.

Cursors moet je zoveel mogelijk vermijden, want dat is erg slecht voor je performance.

[JSchut]

easydisk schreef op 22 april 2004 @ 12:58:
Misschien kan je inbakken dat dat id = 1 + "Een getal is deelbaar door 3, als de som van de cijfers deelbaar is door 3."

Het probleem is dat de id's niet op volgorde staan.....

cameodski schreef op 22 april 2004 @ 12:58:
Je kunt je data eerst in een temporary table zetten waarin een autonumber kolom (IDENTITY) zit.
Op die manier heb je dan een soort rijnummers.


[...]

Cursors moet je zoveel mogelijk vermijden, want dat is erg slecht voor je performance.

Een temp table is geen optie

[ Voor 43% gewijzigd door JSchut op 22-04-2004 13:04 ]

[Jails]

Volgens mij moet je een Stored Procedure schrijven die een parameter-list accepteert.

Voordat je je SQL uitvoert bouw je je lijst met ID's op, en die geef je vervolgens mee in je Stored procedure....

[Feyd-Rautha]

cameodski schreef op 22 april 2004 @ 12:58:
Je kunt je data eerst in een temporary table zetten waarin een autonumber kolom (IDENTITY) zit.
Op die manier heb je dan een soort rijnummers.

Het moven van de data naar een temp-table lijkt me nogtans ook niet echt performant.
Je overloopt eerst je originele table en daarna moet die temptable dan nog eens overlopen.

Ik heb wel geen echt idee hoe inperformant cursors zijn...

[whoami]

Een CURSOR met een FETCH RELATIVE oid zou idd een oplossing zijn.

JSchut schreef op 22 april 2004 @ 13:00:
[...]

Een temp table is geen optie

Waarom niet?

[ Voor 55% gewijzigd door whoami op 22-04-2004 13:05 ]

[cameodski]

Feyd-Rautha schreef op 22 april 2004 @ 13:03:
[...]

Het moven van de data naar een temp-table lijkt me nogtans ook niet echt performant.
Je overloopt eerst je originele table en daarna moet die temptable dan nog eens overlopen.

Ik heb wel geen echt idee hoe inperformant cursors zijn...

Ja, je doet inderdaad dubbel werk, maar als je alleen de PK's in de temp table opneemt, scheelt dat al een heleboel.
Overigens heb je met een cursor ook een temp table nodig, want je zult toch je resultset ergens moeten opbouwen.

JSchut schreef op 22 april 2004 @ 13:00:
[...]
Een temp table is geen optie

Een temp table is geen optie? Je mag het ook in een permanente table doen als je dat leuker vindt.
Ik denk dat je niet veel keus hebt. Of je moet een hele super intelligente query bouwen, maar ik kan er in ieder geval nog niet één bedenken.

Als je trouwens MSSQL 2000 gebruikt, kun je ook gebruik maken van het table datatype.

Jails schreef op 22 april 2004 @ 13:02:
Volgens mij moet je een Stored Procedure schrijven die een parameter-list accepteert.

Voordat je je SQL uitvoert bouw je je lijst met ID's op, en die geef je vervolgens mee in je Stored procedure....

En hoe wilde je die ID's dan gaan bepalen. Lijkt me toch dat je dat ook met een query zult moeten doen. En die query kun je dus ook in je stored procudure zetten en dan hoef je dus ook geen lijst met ID's mee te geven.
Lijsten met ID's zijn overigens ook erg vies en als het kan, moet je die vermijden.

[ Voor 54% gewijzigd door cameodski op 22-04-2004 13:16 ]

[Verwijderd]

Volgens mij is het wel met een query te doen. ik neem aan dat de namen in je tabel uniek zijn en dat de volgorde van de namen belangrijk is om te bepalen welke (elke 3de) in het resultaat moet verschijnen.

De eerste stap is om te bepalen welke positie elke naam heeft. Dit is natuurlijk om te bepalen welke naam wel (elke 3de) en welke naam niet (elke 1ste en 2de) in het resultaat moet komen. De positie van elke naam in de lijst is eenvoudig te bepalen als je bedenkt dat de positie van een naam gelijk is aan de count van het aantal namen dat kleiner is dan zichzelf.

Dit kan met deze query:

code:

select  name
,       (select count(*) from table t2 where t2.name < t1.name and parent=1) "position"
from    table t1
where   parent=1
order by t1.name

Nu heb je dus een lijst met namen en hun positie. Deze lijst kan je dan weer verwerken in een nieuwe query die alleen maar de namen selecteert waarvan de positie deelbaar is door 3.

Als volgt:

code:

select  name, position
from    (    select  name
             ,       (select count(*) from table t2 where t2.name < t1.name and parent=1) "position"
             from    table t1
             and     parent = 1
        ) as temptable
where   position % 3 = 0
order by name

Dit zou moeten werken. Ik heb het niet helemaal kunnen testen omdat ik geen tabel heb met de naam "table" maar even een snelle test op een andere tabel leek wel te werken. Over performance heb ik niet nagedacht. Je moet zelf maar bekijken of het in jouw situatie bruikbaar is.

[ Voor 5% gewijzigd door Verwijderd op 22-04-2004 14:17 ]

[cameodski]

Verwijderd schreef op 22 april 2004 @ 13:42:
Over performance heb ik niet nagedacht. Je moet zelf maar bekijken of het in jouw situatie bruikbaar is.

Aan deze optie heb ik inderdaad ook zitten denken, maar omdat subqueries op deze manier erg slecht zijn voor de performance, heb ik dit alternatief maar weggelaten.

[Verwijderd]

cameodski schreef op 22 april 2004 @ 13:48:
maar omdat subqueries op deze manier erg slecht zijn voor de performance, heb ik dit alternatief maar weggelaten.

Tja, wat is performance. Omdat de topic starter helemaal niets verteld over zijn environment is het ook moeilijk om uitspraken te doen over performance. Ik weet b.v. niet hoe groot zijn tabellen zijn en hoevaak deze query uitgevoerd moet worden.
Als zijn tabel 1.000.000 records bevat en de query moet 1000x per minuut uitgevoerd worden dan heb je waarschijnlijk een probleem. Maar als de tabel maar 1000 records bevat of de query hoeft maar 1x per dag uitgevoerd te worden dan is het een heel ander verhaal.

Daarom heb ik deze oplossing maar wel gepost.

[cameodski]

Verwijderd schreef op 22 april 2004 @ 13:56:
[...]


Tja, wat is performance. Omdat de topic starter helemaal niets verteld over zijn environment is het ook moeilijk om uitspraken te doen over performance. Ik weet b.v. niet hoe groot zijn tabellen zijn en hoevaak deze query uitgevoerd moet worden.
Als zijn tabel 1.000.000 records bevat en de query moet 1000x per minuut uitgevoerd worden dan heb je waarschijnlijk een probleem. Maar als de tabel maar 1000 records bevat of de query hoeft maar 1x per dag uitgevoerd te worden dan is het een heel ander verhaal.

Daarom heb ik deze oplossing maar wel gepost.

Tja, het is maar wat voor insteek je kiest. Ik heb zoveel ellende meegemaakt met dergelijke trage subqueries, dat ik zoiets niet meer durf te posten als er een beter alternatief is.