Open Source Release
30 lines
1.6 KiB
SQL
30 lines
1.6 KiB
SQL
-- +goose Up
|
|
|
|
-- PC configurator (like DNS-shop/Regard's component picker) reuses the
|
|
-- existing retail-parts catalog rather than a parallel table — a CPU or
|
|
-- GPU sold to a client is fundamentally the same kind of row as any other
|
|
-- retail part (stock, FIFO cost, sale_price, the existing Продажи
|
|
-- checkout), it just also needs compatibility-relevant attributes no
|
|
-- other part type has. pc_component_type is NULL for every ordinary
|
|
-- repair part (screens, batteries, toner...) — only staff who explicitly
|
|
-- tag a part as a PC component populate it.
|
|
--
|
|
-- pc_spec is JSONB rather than dedicated columns per type — the eight
|
|
-- component types need almost entirely different attribute sets (a
|
|
-- motherboard's max_ram_gb/ram_slots/form_factor have no CPU equivalent),
|
|
-- and a rigid per-type table would mean either eight near-empty tables or
|
|
-- one parts table bloated with thirty mostly-NULL columns. Same
|
|
-- "structured-enough JSONB on a core table" idiom orders.custom_fields
|
|
-- already established (migrations/009) — internal/pcbuilder's
|
|
-- compatibility checker is the one place that needs to know the shape per
|
|
-- type, not the database.
|
|
ALTER TABLE parts ADD COLUMN pc_component_type TEXT
|
|
CHECK (pc_component_type IN ('cpu', 'motherboard', 'ram', 'gpu', 'psu', 'case', 'cooler', 'storage'));
|
|
ALTER TABLE parts ADD COLUMN pc_spec JSONB;
|
|
CREATE INDEX parts_pc_component_type_idx ON parts (pc_component_type) WHERE pc_component_type IS NOT NULL;
|
|
|
|
-- +goose Down
|
|
DROP INDEX parts_pc_component_type_idx;
|
|
ALTER TABLE parts DROP COLUMN pc_component_type;
|
|
ALTER TABLE parts DROP COLUMN pc_spec;
|