2012-05-10 4 views
0

제품 릴리스 당 특정 항목의 양을 나열하는 2 개의 열이있는 테이블이 있습니다. 두 열 사이의 증가율을 계산하여 테이블의 새 열에 추가해야하지만이와 관련된 문서를 찾지 못했습니다? 필자는 Postgres 9.0을 사용하고 있으며 릴리스 간 누락되거나 잘못된 데이터가 없도록하기 위해 QC 프로세스의 일부로 두 열 사이의 비율 증가를 검사해야합니다. 내가 올바른 비율로를 백분율 증가 열을 추가하고 채울 싶습니다2 열 사이의 변화율을 계산하십시오.

oid oid[] NOT NULL, 
"State" character varying(2)[] NOT NULL, 
release_1121 numeric NOT NULL, 
release_1122 numeric NOT NULL, 
CONSTRAINT oid PRIMARY KEY (oid) 

:

다음은 테이블 정의합니다.

+2

1121, 1122 - 필드 이름이나 값입니까? 제발, 완전한 테이블 정의를 게시하십시오. 지금까지 해 온 것을 보여주십시오. – vyegorov

+1

릴리스 당 * 하나의 양을 가진'release' 테이블과 모든/선택된 릴리즈 사이의 변화를 계산하는 뷰/함수가있는 것처럼 보입니다. ** 아니 ** ** 릴리스 간의 델타에 대한 테이블. 또한, Postgres 버전과 계산 목적을 언급하십시오 (필요한 것을 더 잘 이해할 수 있도록). –

답변

0

나는 증가율 열을 추가하면 다음과 같이 할 수있는 한 시간 작업 (details in the docs)라고 말할 것입니다 :

ALTER TABLE target ADD pct float; 

을 그리고 당신은 새 값으로 채우기, 테이블을 업데이트 할 수 있습니다 :

UPDATE target SET pct = (after::float - before::float)/before::float; 
+0

내가 그것을 필요로하는 정확하게 것이다, 그렇게 많이 고마워한다! –

3

나는 이것이 당신이 실제로 필요하다 생각 :

표 뭔가 리튬을 찾아야한다 KE이 : ​​

CREATE TABLE release (
release_id integer PRIMARY KEY, -- pk is NOT NULL automatically 
-- state varchar(2)[] NOT NULL, -- ?? 
amount numeric NOT NULL 
); 

테스트 데이터 :

INSERT INTO release VALUES (release_id, amount) 
(1121, 25) 
,(1122, 30) 
,(1123, 90) 
,(1124, 10); 

검색어 : lag()는 PostgreSQL을 8.4 이상이 필요

WITH x AS (
    SELECT * 
      ,lag(amount) OVER (ORDER BY release_id) as last_amount 
    FROM release 
    ) 
SELECT release_id, amount 
     ,(amount - last_amount) AS abs_change 
     ,round((100 * (amount - last_amount))/last_amount, 2) AS percent_change 
FROM x 
ORDER BY 1; 

CTE (With clause) 창 기능.
결과 :

release_id | amount | abs_change | percent_change 
-----------+--------+------------+--------------- 
1121  | 25  | <NULL>  | <NULL> 
1122  | 30  | 5   | 20.00 
1123  | 90  | 60   | 200.00 
1124  | 10  | -80  | -88.89 
  • 가 기본 키로 oid를 사용하지 마십시오! 그것은 나쁜 습관입니다. PostgreSQL 9.0에서는 기본값이 WITHOUT OIDS입니다. Read more here.

  • 회피 할 수없는 경우 mixed case identifiers ("주")을 사용하지 마십시오.

+0

이것은 단지 당신의 답을 얻기 전에 제가 제안하려고 생각했던 것입니다. 불필요한 금액 저장이 없으므로 하나의 금액이 정확하지 않은 것으로 확인되면 해당 금액을 수정하고 완료됩니다. 중복 사본을 찾아 내거나 종속 값을 다시 계산할 필요가 없습니다. – kgrittn

+0

@kgrittn : 중복 스토리지를 피하는 것이 확실한 경로이기 때문에 같은 생각입니다. :) –

관련 문제