[PGSQL] groepeer rijen die ongeveer ongeveer dezelfde waarde

[Travelan]

Hallo,

Ik heb een tabel in PostgreSQL waarin ik een kolom heb met reële getallen. Nu is het zo dat als er meer dan 1 rij is met getallen in die kolom die dicht bij elkaar liggen (dus bijv. 3 rijen, met de waarden 33,5 33,6 en 33,3) geconverteerd moet worden in 1 rij. Dat kan en mag heel simpel door de andere 2 te negeren, maar als er een elegantere oplossing is, is dat natuurlijk mooier. In de uiteindelijke rij is het het mooiste als de waarde die er in komt het gemiddelde is van alle bijeengevoegde waarden.
Ik wil dat graag in een view doen. Ik kan en wil geen rijen verwijderen uit de tabel.
De tabel bevat alleen maar strings, een id (integer) en een REAL met dus dit getal waar ik het over heb.

Ik kom er dus zelf niet uit en ik hoop dat iemand mij er mee kan helpen..!

Alvast bedankt!

Bas

[ Voor 14% gewijzigd door Travelan op 20-06-2010 13:31 . Reden: typo en verduidelijken ]

[kluyze]

Het is niet heel duidelijk wat je nu wilt doen, wil je echt de rijen verwijderen of alleen niet selecteren?

Alleen selecteren:
Hoe groot mag het verschil zijn? Je kan een group by doen op een formule. Bv

SQL:

GROUP BY ROUND(getal, 0)

Misschien kan je met wat vindingrijkheid de formule zo opstellen dat je groepeert op getallen die een bepaald maximum van elkaar afwijken.

[ Voor 3% gewijzigd door kluyze op 20-06-2010 13:37 ]

[Travelan]

Bedankt! Ik ga er even mee spelen. Ik bedenk met nu ook dat het best wel mogelijk is dat de waarden 2 verschillen, en toch bij elkaar geraapt moeten worden. Is daar ook nog iets voor?

Het probleem wat ik nu ook heb is namelijk dat de volgende waarden niet samengepakt worden: 34,4 en 34,5...
In dit voorbeeld moet dan de waarde 36,6 wel een nieuwe rij opleveren.

[ Voor 33% gewijzigd door Travelan op 20-06-2010 13:49 ]

[kluyze]

Als je round gebruikt dan wordt 33.4 bij 33 gegroupeerd en 33.5 bij 34 omdat round bij de dichts bijzijnde integer afrond, je hebt bv ook de formules floor() en ceil(), bij floor() bv gaat alles wat 33.xx als getal heeft bij 33 gegroepeerd worden. Het nadeel dan is dat als er ergens 33.9 en 34.1 in zit, deze niet gegroepeerd worden.

Om echt waarden die dicht bij elkaar liggen te groeperen moet je eens met wat formules spelen, ook niet beperken tot afrondingsformules, maar ga ook eens spelen met MOD() en zo. Een kant en klare formule heb ik nu onmiddellijk ook niet in mijn hoofd, maar dit kan je misschien wel een zetje geven in de goede richting.

Ik ben zelfs niet heel zeker of wat je wil ook mogelijk is, maar daar kan je zelf wel achter komen. Of misschien mensen die meer SQL ervaring hebben, die je wat beter kunnen helpen.

[Gomez12]

Zou je niet gewoon een extra kolom oid kunnen toevoegen waarin je via een batch-process de bij elkaar geraapte waardes vult?

Dan heb je veel meer vrijheden ( je kan het laten vullen door meerdere batch-processen, bijv het 1e process raapt de 2 verschillen bij elkaar, 2e proces raapt de 1 verschillen bij elkaar etc etc ) ipv dat je alles in een onmogelijke group by moet gaan vatten.

Sowieso vraag ik me af hoe een pgsql zich houdt als je grotere berekeningen in de group by gaat doen...
Btw een verschil van 2 lijkt me goed te bepalen door round(getal/2,0) te doen.

kluyze schreef op zondag 20 juni 2010 @ 13:57:
Om echt waarden die dicht bij elkaar liggen te groeperen moet je eens met wat formules spelen, ook niet beperken tot afrondingsformules, maar ga ook eens spelen met MOD() en zo. Een kant en klare formule heb ik nu onmiddellijk ook niet in mijn hoofd, maar dit kan je misschien wel een zetje geven in de goede richting.

Ik ben zelfs niet heel zeker of wat je wil ook mogelijk is, maar daar kan je zelf wel achter komen. Of misschien mensen die meer SQL ervaring hebben, die je wat beter kunnen helpen.

In principe kan je het in sql zo gek maken als je zelf wilt, met wat if / else dingen kan je scheiden etc etc. De grote vraag is alleen of dit qua performance nog wel haalbaar is.
Als je voor je group by 1 miljoen records in je resultset hebt zitten dan moeten al deze bewerkingen over die 1 miljoen records gaan ( en berekeningen gaan veelal zonder indexen etc )

Persoonlijk zou ik gewoon 1 veld extra aanmaken en dan daarin de uitkomst van de berekening gooien en dan een index erop.

[ Voor 49% gewijzigd door Gomez12 op 20-06-2010 14:06 ]