Oracle 11からPostgres 9.5への移行時に、仮想列を処理するためには、アプリケーション内のデータベース関連のコードを変更する必要はありません。トリガーは大きなデータセットを扱う場合と比べて高価です)。OracleからPostgresへの仮想列の変換
同様の質問があります。Computed/calculated columns in PostgreSQLですが、このソリューションは移行のシナリオに役立ちません。
Oracle 11からPostgres 9.5への移行時に、仮想列を処理するためには、アプリケーション内のデータベース関連のコードを変更する必要はありません。トリガーは大きなデータセットを扱う場合と比べて高価です)。OracleからPostgresへの仮想列の変換
同様の質問があります。Computed/calculated columns in PostgreSQLですが、このソリューションは移行のシナリオに役立ちません。
BEFORE INSERT
トリガーを使用すると、実際に書き込まれる前に挿入された値を変更できます。それほど高価ではありません。最先端のパフォーマンスが必要な場合は、Cでトリガー機能を記述してください。
しかし、私はビューが最良の解決策だと思います。更新可能なビューを使用すると、アプリケーションコードを変更する必要がなくなります。
CREATE TABLE data(
id integer PRIMARY KEY,
factor1 integer NOT NULL,
factor2 integer NOT NULL
);
CREATE VIEW interface AS
SELECT id, factor1, factor2,
factor1 * factor2 AS product
FROM data;
test=> INSERT INTO interface VALUES (1, 6, 7), (2, 3, 14);
INSERT 0 2
test=> UPDATE interface SET factor1 = 7 WHERE id = 1;
UPDATE 1
test=> DELETE FROM interface WHERE id = 1;
DELETE 1
test=> SELECT * FROM interface;
┌────┬─────────┬─────────┬─────────┐
│ id │ factor1 │ factor2 │ product │
├────┼─────────┼─────────┼─────────┤
│ 2 │ 3 │ 14 │ 42 │
└────┴─────────┴─────────┴─────────┘
(1 row)
私たちが思いついた唯一の戦略だと思います。痛みを伴う部分はデータの移行であり、私たちはテーブルやビューを正しく取得するだけで驚いています – happybuddha
唯一の解決策は、関数の値を計算するトリガーです。 –