ستون محاسباتی مجازی در PostgreSQL 18؛ چه زمانی ذخیره نکنیم؟

BEGIN;
CREATE TEMP TABLE demo_line_items (
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12,2) NOT NULL CHECK (unit_price >= 0),
    total numeric GENERATED ALWAYS AS
        (quantity * unit_price) VIRTUAL
);
INSERT INTO demo_line_items (quantity, unit_price)
VALUES (3, 12.50);
SELECT quantity, unit_price, total FROM demo_line_items;
ROLLBACK;

روی PostgreSQL 18 انتظار total برابر 37.50 داریم. ROLLBACK همه تغییرهای این مثال را برمی‌گرداند. روی نسخه قدیمی‌تر نحو VIRTUAL ممکن است پذیرفته نشود. مثال تخفیف، مالیات و واحد پول را مدل نمی‌کند.

در این نشست آزمایشی دو نوع ستون از یک فرمول و داده یکسان ساخته می‌شوند. مقدار generated را در INSERT نمی‌نویسیم؛ فقط داده پایه را می‌دهیم تا رابطه در مدل داده حفظ شود.

-- PostgreSQL 18; disposable session.
BEGIN;
CREATE TEMP TABLE generated_price_demo (
    id integer PRIMARY KEY,
    quantity integer NOT NULL CHECK(quantity > 0),
    unit_price numeric(12,2) NOT NULL CHECK(unit_price >= 0),
    virtual_total numeric GENERATED ALWAYS AS
        (quantity * unit_price) VIRTUAL,
    stored_total numeric GENERATED ALWAYS AS
        (quantity * unit_price) STORED
);
INSERT INTO generated_price_demo(id,quantity,unit_price)
VALUES(1,3,12.50);
SELECT id,virtual_total,stored_total FROM generated_price_demo;
UPDATE generated_price_demo SET quantity=4 WHERE id=1;
SELECT id,virtual_total,stored_total FROM generated_price_demo;
ROLLBACK;

خروجی اول برای هر دو 37.50 و خروجی دوم 50.00 است. یکسانی مقدار به معنی یکسانی محل هزینه محاسبه نیست. ROLLBACK نمونه را پاک می‌کند و جدول تجاری شما تغییری نمی‌کند.

متادیتا را بخوانید تا ابزار مهاجرت یا ORM بداند total ستون معمولی قابل نوشتن نیست. سپس ورودی مرزی نامعتبر را داخل یک بلوک کنترل‌شده می‌فرستیم؛ شکست مورد انتظار نباید کل نشست آزمایش را بی‌توضیح متوقف کند.

-- PostgreSQL 18.
BEGIN;
CREATE TEMP TABLE generated_validation_demo (
    quantity integer NOT NULL CHECK(quantity > 0),
    price numeric(12,2) NOT NULL CHECK(price >= 0),
    total numeric GENERATED ALWAYS AS (quantity * price) VIRTUAL
);
SELECT column_name,is_generated,generation_expression
FROM information_schema.columns
WHERE table_name='generated_validation_demo'
  AND table_schema LIKE 'pg_temp_%'
ORDER BY ordinal_position;

DO $$
BEGIN
    BEGIN
        INSERT INTO generated_validation_demo(quantity,price) VALUES(0,10);
        RAISE EXCEPTION 'Expected a check violation';
    EXCEPTION WHEN check_violation THEN
        RAISE NOTICE 'Invalid quantity rejected as expected';
    END;
END $$;
SELECT count(*) AS rows_after_rejected_insert
FROM generated_validation_demo;
ROLLBACK;

باید NOTICE مربوط به ردشدن تعداد صفر و شمارش نهایی صفر را ببینید. اگر محدودیت حذف شود، RAISE EXCEPTION آزمون را ناموفق می‌کند. کنترل قاعده تجاری در CHECK مستقل از نوع ذخیره یا مجازی ستون است.

هدف این آزمایش دیدن پلان و تأیید برابری نتیجه است. چون هر دو ستون در یک جدول‌اند، از آن نتیجه قطعی درباره صرفه‌جویی فضای دو طراحی جدا نگیرید. برای تصمیم تولید، دو طرح مستقل با الگوی واقعی نوشتن و خواندن بسازید.

-- PostgreSQL 18; 10,000 synthetic rows, no performance promise.
BEGIN;
CREATE TEMP TABLE generated_read_demo (
    quantity integer NOT NULL,
    price numeric NOT NULL,
    virtual_total numeric GENERATED ALWAYS AS (quantity * price) VIRTUAL,
    stored_total numeric GENERATED ALWAYS AS (quantity * price) STORED
);
INSERT INTO generated_read_demo(quantity,price)
SELECT (n % 5) + 1, (n % 100) + 0.50
FROM generate_series(1,10000) AS numbers(n);
ANALYZE generated_read_demo;
EXPLAIN (ANALYZE, BUFFERS)
SELECT sum(virtual_total) FROM generated_read_demo;
EXPLAIN (ANALYZE, BUFFERS)
SELECT sum(stored_total) FROM generated_read_demo;
SELECT sum(virtual_total)=sum(stored_total) AS equal_results
FROM generated_read_demo;
ROLLBACK;

equal_results باید true باشد. اجرای EXPLAIN ANALYZE واقعاً پرس‌وجو را اجرا می‌کند؛ آن را با دستور تغییردهنده ناشناخته روی داده اصلی به کار نبرید. ترتیب اجرا و کش می‌تواند زمان را تغییر دهد؛ یک بار سریع‌ترشدن، معیار انتخاب معماری نیست.