2012-05-10 6 views
0

私の製品のリリースあたりの特定の項目の量を列挙する2列の表があります。私は2つの列間の増加率を計算し、それをテーブルの新しい列に追加する必要がありますが、これに関連するドキュメントは見つかりませんでしたか?私はPostgres 9.0を使用しています。リリース間に欠落/間違ったデータがないことを確認するために、QCプロセスの一環として2つのカラム間の増加率を調べる必要があります。ここで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

リリースごとに* 1つの金額を持つ 'release'テーブルと、すべての/選択されたリリース間の変更を計算するビュー/関数があるように見えます。 ** **リリース間の差分の表ではありません。また、あなたのバージョンのPostgresと計算の目的を明記してください。 –

答えて

0

私は増加率の列を追加すると、次のように行うことができます1時間操作、(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); 

問合せ:

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)とウィンドウ機能lag()は、PostgreSQL 8.4以降が必要です。
結果:

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

これはちょうど*私があなたの答えになる前に、私が提案しようと思っていたものです。冗長な金額の保管はありません。したがって、金額の1つが間違っていると判明した場合は、金額を修正して完了です。冗長コピーを探したり、依存値を再計算する必要はありません。 – kgrittn

+0

@kgrittn:同じ考えです。おそらく、冗長なストレージを避けるための明白な方法だからです。 :) –

関連する問題