Everything should be made as simple as
possible, but no simpler

https://www.siepomaga.pl/milosz-mosko

1. bo jesli m$ , Tomasz 22/07/11 15:04
   to wypróbuj COMPUTE BY wraz z grupowaniem.
   
   Menah: to jest suma ogólna a Master szuka sumy przyrostowej

   https://www.siepomaga.pl/milosz-mosko

2. o tym pomysłałem ale ... , Master/Pentium 22/07/11 15:56
   totalnie się na tym nie znam a i kod tego wygląda dość egzotycznie.
   Baza to Oracle.

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)

W sumie to ja nie wierzę w ten internet

1. dobre! , bwana 22/07/11 15:13
   bardzo dobre!:-D

   "you don't need your smile when I cut
   your throat"

2. to jest suma ogólna , Master/Pentium 22/07/11 15:55
   a ja faktycznie potrzebuję przyrostową.

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)

"you don't need your smile when I cut
your throat"

1. tak, Oracle , Master/Pentium 22/07/11 15:53
   ...

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)

   1. no to lecimy , bwana 24/07/11 21:35
      z założenia będzie znacznie wydajniej niż metodami detail join agregat (znacznie wydajniej przy dużym wolumenie danych).
      
      Struktura danych dla przykładu: tabela, gdzie jest po kilka rekordów dla tego samego identyfikatora osoby (person_id) i gdzie object_version_number to jakaś liczba.
      
      
      sumę narastająco liczymy tak:
      
      select person_id, effective_start_date, object_version_number,
      sum(object_version_number) over (partition by person_id order by effective_start_date rows unbounded preceding) sovn
      from per_all_assignments_f
      
      i dostajemy w wyniku (kawałek):
      
      21 1979/03/12 14 14
      21 2002/01/01 40 54
      21 2008/01/07 576 630
      21 2009/07/13 670 1300
      21 2009/10/01 773 2073
      21 2009/12/01 999 3072
      21 2010/09/01 1320 4392
      22 1977/03/17 27 27
      22 2002/01/01 53 80
      22 2008/01/07 690 770
      22 2009/10/20 689 1459
      23 1977/09/15 16 16
      23 2007/10/15 281 297
      23 2008/10/01 478 775
      
      Kluczowe jest to, że po funkcji sum(object_version_number) jest dodana definicja partycji wg której liczymy funkcję sum()
      
      Uwaga! ważna jest np. klauzula order by w definicji partycji - wiersze do sumy częściowej będą układane właśnie w takiej kolejności jak to określono w order by w def. partycji a nie w order by całego zapytania.
      
      Jeśli chcemy mieć tylko jedną partycję to zamiast "partition by person_id" dalibyśmy "partition by null".
      
      "rows unbounded preceding" oznacza - od początku partycji do bieżącego wiersza. Można też zadać okno "rows 5 preceding" - ostatnie pięć wierszy albo "rows 5 following" - NASTĘPNE pięć wierszy. Ogólnie polecam Ci zapoznanie się z tymi funkcjami Oracle SQL bo mają power.
      
      Tu fajne opracowanie: http://www.orafaq.com/node/55

      "you don't need your smile when I cut
      your throat"

http://flickr.com/photos/myhacien
da

Kor2dual3,2hZ overkloc,4Gbit Ram
G-forc 460 gietex,barakudy
Children of Neostrada Association MVP

1. odnoszę wrażenie, że to zapytanie raczej szybko się nie wykona. , Master/Pentium 22/07/11 23:39
   na razie powalczę z funkcjami analitycznymi - wyglądają najbardziej rozsądnie.

   Nie ma tego złego , co by się w gorsze
   obrócić nie mogło - jak nie wierzysz
   włącz komputer :-)