Տվյալների բազայի նախագծում

01Entity-ներ և կապեր

Սկսեք բիզնեսից, ոչ թե աղյուսակներից։ Թվարկեք գոյականները (հաճախորդ, ապրանք, պատվեր, վճարում) և դրանք կապող բայերը (հաճախորդը պատվերներ է տալիս, պատվերը պարունակում է ապրանքներ)։ Յուրաքանչյուր կարևոր գոյական դառնում է աղյուսակ՝ entity։ Այնուհետև որոշեք յուրաքանչյուր կապի cardinality-ն։ One-to-many-ն ամենատարածվածն է. մեկ հաճախորդն ունի շատ պատվերներ, ուստի orders-ը ստանում է customer_id foreign key։ Many-to-many-ն, ինչպես ապրանքներն ու կատեգորիաները, պահանջում է join աղյուսակ (product_categories)՝ երկու foreign key-երով և composite primary key-ով։ One-to-one-ը հազվադեպ է և սովորաբար նշանակում է ոչ պարտադիր լրացուցիչ տվյալներ, օրինակ՝ հաճախորդի պրոֆիլ։ Foreign key-երը ստիպում են տվյալների բազային մերժել «որբ» տողերը. ON DELETE վարքագիծը ընտրեք գիտակցաբար՝ RESTRICT բիզնես գրառումների համար, CASCADE՝ միայն իսկական «երեխաների» համար, ինչպես draft զամբյուղի order item-ները։

• Գոյականները դառնում են աղյուսակներ, բայերը՝ կապեր։
• 1:N. foreign key «շատ» կողմում։
• N:M. join աղյուսակ՝ composite key-ով։
• Անվանեք միատեսակ. աղյուսակները՝ հոգնակի, foreign key-երը՝ singular_id, snake_case։

02Նորմալիզացիա և դենորմալիզացիա

Նորմալիզացիան նշանակում է յուրաքանչյուր փաստը պահել մեկ անգամ։ Գործնականում թիրախը երրորդ նորմալ ձևն է (3NF). յուրաքանչյուր սյունակ կախված է key-ից, ամբողջ key-ից և ոչ մի բանից, բացի key-ից։ Եթե հաճախորդի email-ը պատճենված է յուրաքանչյուր պատվերում, այն փոխելը նշանակում է թարմացնել շատ տողեր, և որոշները բաց կթողնվեն։ Դենորմալիզացիան տվյալների դիտավորյալ պատճենումն է՝ արագության կամ պատմության համար։ Երկու դեպք ոչ միայն թույլատրելի են, այլև պարտադիր։ Snapshot-ներ. order item-ը պետք է պահի ապրանքի անունը և միավորի գինը գնման պահին, որովհետև ապրանքը հետագայում կփոխվի։ Read model-ներ. customers-ի վրա cache արված order_count կամ search index։ Լռելյայն նորմալիզացրեք, դենորմալիզացրեք գիտակցաբար և փաստաթղթավորեք, թե ով է պատճենը համաժամեցված պահում՝ trigger, job, թե հավելվածը։

03Key-եր. natural, թե՞ surrogate, UUID, թե՞ bigint

Natural key-ը իրական աշխարհի արժեք է, ինչպես email-ը կամ SKU-ն. surrogate key-ը իմաստ չունեցող գեներացված id է։ Natural արժեքները փոխվում են (մարդիկ փոխում են email-ները, SKU-ները վերանվանվում են), ուստի օգտագործեք surrogate primary key և natural արժեքը պաշտպանեք UNIQUE constraint-ով։ Surrogate-ի համար bigint auto-increment-ը կոմպակտ է (8 բայթ), արագ և B-tree-ում insert-ները հերթականությամբ է պահում, բայց id-ները գուշակելի են և պետք է գեներացվեն տվյալների բազայի կողմից։ UUID-ները (16 բայթ) կարող են գեներացվել ցանկացած տեղում, ինչը հարմար է բաշխված համակարգերի, offline կլիենտների և հանրային URL-ների համար։ Պատահական UUIDv4-ը insert-ները ցրում է ամբողջ index-ով և մեծ մասշտաբում վնասում գրելու արագությանը. ժամանակով դասավորված UUIDv7-ը լուծում է դա։ PostgreSQL 18-ն ունի ներկառուցված uuidv7() ֆունկցիա, մյուս դեպքերում v7-ը գեներացրեք հավելվածում։

• bigint. ներքին աղյուսակներ, join-եր, գրելու մեծ ծավալ։
• UUIDv7. հանրային id-ներ, offline կամ բազմահամակարգ ստեղծում։
• Երբեք մի բացահայտեք հաջորդական id-ներ այնտեղ, որտեղ թվարկումը (enumeration) ռիսկ է։
• Natural key-երը պահեք որպես UNIQUE սյունակներ, ոչ թե primary key-եր։

04Index-ների ռազմավարություն

Index-ը որոշ սյունակների դասավորված պատճենն է, որը թույլ է տալիս տվյալների բազային գտնել տողերը՝ առանց ամբողջ աղյուսակը scan անելու, ինչպես գրքի վերջում գտնվող առարկայական ցանկը։ Յուրաքանչյուր primary key և unique constraint ունի այդպիսին։ Ավելացրեք մյուսները այն հարցումների համար, որոնք իսկապես կատարում եք. join-երում օգտագործվող foreign key-եր, հաճախակի WHERE և ORDER BY կետերում հանդիպող սյունակներ։ Composite index-ում սյունակների հերթականությունը կարևոր է։ Leftmost-prefix կանոնի համաձայն՝ (customer_id, created_at) index-ն օգնում է customer_id-ով կամ customer_id-ով և ամսաթվերի միջակայքով ֆիլտրող հարցումներին, բայց ոչ միայն created_at-ով ֆիլտրողներին։ Հավասարության սյունակները դրեք առաջինը, իսկ միջակայքի կամ դասավորման սյունակները՝ վերջում։ Index-ները անվճար չեն. յուրաքանչյուրը դանդաղեցնում է գրելը և հիշողություն է զբաղեցնում, ուստի հեռացրեք չօգտագործվողները։ Միշտ հաստատեք EXPLAIN-ով։

1-- "latest orders of a customer" in one index scan
2CREATE INDEX orders_customer_created_idx
3  ON orders (customer_id, created_at DESC);
4 
5EXPLAIN
6SELECT id, total_minor, status
7FROM orders
8WHERE customer_id = 42
9ORDER BY created_at DESC
10LIMIT 20;

05Գումար և ժամանակ

Երբեք գումար մի պահեք floating-point սյունակում. բինար float-ներում 0.1 + 0.2-ը հավասար չէ 0.3-ի, և կլորացման սխալները կուտակվում են հազարավոր պատվերներում։ Օգտագործեք ամբողջ թվով մանր միավորներ (ցենտեր) bigint-ում կամ DECIMAL/NUMERIC՝ ֆիքսված scale-ով, և գումարի կողքին միշտ պահեք արժույթի կոդը (ISO 4217, օրինակ՝ EUR կամ USD)։ Գները, զեղչերը, հարկը և ընդհանուր գումարները պահեք հենց պատվերի վրա, որպեսզի պատմությունը երբեք չփոխվի։ Ժամանակի համար պահեք պահերը UTC-ով։ PostgreSQL-ի timestamptz-ը պահում է UTC և ցուցադրելիս փոխարկում. MySQL-ում DATETIME-ը time zone չունի, ուստի պայմանավորվածությամբ պահեք UTC, և խուսափեք TIMESTAMP-ից հեռավոր ապագայի ամսաթվերի համար, որովհետև այն ավարտվում է 2038-ին։ Ապագա տեղական իրադարձությունների համար, օրինակ՝ որևէ քաղաքում ժամը 10:00-ին ամրագրում, պահեք տեղական ժամը գումարած IANA time zone-ի անունը, օրինակ՝ Asia/Yerevan, որովհետև time zone-ների կանոնները կարող են փոխվել։

• Գումարներ. bigint մանր միավորներ կամ NUMERIC(19,4), երբեք float։
• Գումարի կողքին միշտ պահեք արժույթը։
• Պահերը՝ UTC-ով, ապագա տեղական իրադարձությունները՝ տեղական ժամ + IANA zone։

06Soft delete-ներ և անվտանգ migration-ներ

Soft delete-ը տողը նշում է որպես ջնջված (deleted_at timestamp)՝ այն հեռացնելու փոխարեն, որպեսզի կարողանաք վերականգնել այն և պահպանել պատմությունը։ Գինը՝ յուրաքանչյուր հարցում պետք է ֆիլտրի այն, իսկ unique constraint-ները պետք է անտեսեն ջնջված տողերը։ PostgreSQL-ում դա լուծում է partial unique index-ը, MySQL-ում օգտագործեք generated column։ Soft delete-ներ օգտագործեք օգտատիրոջը տեսանելի կոնտենտի համար, ոչ թե ամեն ինչի. audit-ի կարիքների համար append-only history աղյուսակը հաճախ ավելի մաքուր է, իսկ գաղտնիության օրենքները կարող են պահանջել իրական ջնջում։ Migration-ները փոխում են կենդանի սխեման, ուստի դրանք դարձրեք հետադարձ համատեղելի աշխատող կոդի հետ՝ expand and contract մոտեցմամբ. ավելացրեք նոր nullable սյունակը, deploy արեք կոդ, որը գրում է երկուսում էլ, backfill արեք խմբաքանակներով, փոխեք կարդալը, ապա ավելի ուշ release-ում հեռացրեք հին սյունակը։ Մեծ index-ները կառուցեք առանց գրելը արգելափակելու (PostgreSQL-ում՝ CREATE INDEX CONCURRENTLY)։

1-- PostgreSQL: email unique only among non-deleted customers
2CREATE UNIQUE INDEX customers_email_live_uq
3  ON customers (lower(email))
4  WHERE deleted_at IS NULL;
5 
6-- expand step: safe on a live table
7ALTER TABLE orders ADD COLUMN currency char(3);
8-- backfill in batches, then in a later release:
9-- ALTER TABLE orders ALTER COLUMN currency SET NOT NULL;

07Օրինակ. e-commerce-ի հիմնական սխեմա

Ահա կոմպակտ հիմք, որը ցույց է տալիս գաղափարները միասին։ Products-ը պահում է ընդհանուր տեղեկատվությունը, variants-ը՝ այն, ինչ իրականում վաճառվում է (չափս, գույն, SKU, գին)։ Պատվերները պատկանում են հաճախորդին, պահում են իրենց արժույթն ու ընդհանուր գումարները և ունեն կարգավիճակ՝ CHECK constraint-ով։ Order item-ները հղվում են variant-ին, բայց նաև snapshot են անում անունը և միավորի գինը, որպեսզի հինգ տարի անց տպված պատվերը դեռ ցույց տա, թե ինչ է վճարել հաճախորդը։ Վճարումները առանձին աղյուսակ են, որովհետև մեկ պատվերը կարող է ունենալ մի քանի փորձ, refund կամ մասնակի capture։ Այս հիմքի շուրջ կավելացնեիք հասցեներ (որոնք նույնպես snapshot են արվում պատվերի վրա), պահեստի շարժեր, կիրառված ակցիաներ և կարգավիճակների պատմության աղյուսակ՝ audit-ի համար։

1CREATE TABLE products (id bigint PRIMARY KEY GENERATED ALWAYS AS IDENTITY, name text NOT NULL);
2CREATE TABLE variants (
3  id bigint PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
4  product_id bigint NOT NULL REFERENCES products(id),
5  sku text NOT NULL UNIQUE,
6  price_minor bigint NOT NULL CHECK (price_minor >= 0));
7CREATE TABLE orders (
8  id bigint PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
9  customer_id bigint NOT NULL REFERENCES customers(id),
10  status text NOT NULL CHECK (status IN ('pending','paid','shipped','cancelled','refunded')),
11  currency char(3) NOT NULL,
12  total_minor bigint NOT NULL,
13  created_at timestamptz NOT NULL DEFAULT now());
14CREATE TABLE order_items (
15  order_id bigint NOT NULL REFERENCES orders(id),
16  variant_id bigint NOT NULL REFERENCES variants(id),
17  name_snapshot text NOT NULL,
18  unit_price_minor bigint NOT NULL,
19  qty int NOT NULL CHECK (qty > 0),
20  PRIMARY KEY (order_id, variant_id));

08Ծառերի մոդելավորում՝ adjacency list, materialised path և closure table

Կատեգորիաները, մեկնաբանությունների շղթաները, կազմակերպության կառուցվածքները և թղթապանակները ծառեր են, և SQL-ում դրանք պահելու մի քանի եղանակ կա։ Adjacency list-ում յուրաքանչյուր տող ունի parent_id՝ պարզ է, հանգույցը տեղափոխելը էժան է, իսկ ռեկուրսիվ CTE-ներով (WITH RECURSIVE, որոնք աջակցում են PostgreSQL-ը և MySQL 8-ը) ենթածառ կարդալը չափավոր խորության դեպքում լավ է աշխատում։ Materialised path-ը պահում է ամբողջ ուղին որպես տող, օրինակ՝ /1/7/42/․ բոլոր հետնորդներին գտնելը արագ prefix որոնում է, բայց ճյուղը տեղափոխելիս պետք է վերագրել դրանից ներքև գտնվող բոլոր ուղիները։ PostgreSQL-ի ltree ընդլայնումը այս մոտեցումը դարձնում է լիարժեք։ Closure table-ը առանձին աղյուսակում պահում է նախնի-հետնորդ բոլոր զույգերը՝ խորության հետ միասին․ ցանկացած ենթածառ կամ նախնիների շղթա կարդալը դառնում է մեկ ինդեքսավորված join, բայց գինը ավելի շատ տողերն են և ավելի շատ աշխատանքը ավելացնելու ու տեղափոխելու ժամանակ։ Nested sets-ը արագ է կարդալու համար, բայց թարմացնելը ցավոտ է, և այսօր հազվադեպ է արժանի։ Ընտրեք ըստ գերակշռող գործողության․ հաճախակի տեղափոխությունների դեպքում՝ adjacency list, ենթածառերի ծանր ընթերցման դեպքում՝ path կամ closure table։

1CREATE TABLE category_paths (
2  ancestor_id   bigint NOT NULL REFERENCES categories(id),
3  descendant_id bigint NOT NULL REFERENCES categories(id),
4  depth         int    NOT NULL,
5  PRIMARY KEY (ancestor_id, descendant_id)
6);
7 
8-- all products in category 7 and every subcategory, one join
9SELECT p.*
10FROM category_paths cp
11JOIN products p ON p.category_id = cp.descendant_id
12WHERE cp.ancestor_id = 7;

09Ամբողջականություն զուգահեռության պայմաններում՝ constraint-ներ, upsert և optimistic locking

Հավելվածի ստուգումները, օրինակ՝ «եթե email-ը չկա, ավելացրու», race condition են․ երկու հարցում կարող են միաժամանակ անցնել ստուգումը և երկուսն էլ ավելացնել տող։ Միայն տվյալների բազան կարող է կանոնները ատոմար կերպով ապահովել, ուստի դրանք դրեք հենց այնտեղ։ UNIQUE constraint-ը upsert-ի հետ միասին (PostgreSQL-ում INSERT ... ON CONFLICT, MySQL-ում ON DUPLICATE KEY UPDATE) կրկնօրինակները դարձնում է կանխատեսելի արդյունք։ Արտաքին կրկնությունների համար, ինչպես վճարման webhook-ը կամ երկու անգամ սեղմված checkout-ը, պահեք idempotency key unique constraint-ով և կրկնության դեպքում վերադարձրեք պահված արդյունքը։ PostgreSQL-ի exclusion constraint-ները կարող են արգելել համընկնող միջակայքերը, ինչը կրկնակի ամրագրումները կանխելու ճիշտ եղանակն է։ Մարդկանց կողմից խմբագրվող գրառումների համար optimistic locking-ը թույլ է տալիս lock չպահել, մինչ ինչ-որ մեկը տպում է․ պահեք version սյունակ, թարմացրեք WHERE version = կարդացած արժեքը, և զրո փոփոխված տողը համարեք կոնֆլիկտ, որը պետք է ցույց տալ օգտատիրոջը։ Pessimistic lock-երը (SELECT ... FOR UPDATE) հարմար են կարճ և «տաք» ուղիների համար, ինչպես պահեստի մնացորդի նվազեցումը։

1-- optimistic lock: succeeds only if nobody changed the row since we read version 7
2UPDATE products
3SET price_cents = 1990, version = version + 1
4WHERE id = 42 AND version = 7;
5-- 0 rows affected => someone else saved first; reload and ask the user
6 
7-- PostgreSQL: no two bookings of a room may overlap
8CREATE EXTENSION IF NOT EXISTS btree_gist;
9ALTER TABLE bookings ADD CONSTRAINT no_overlap
10  EXCLUDE USING gist (room_id WITH =, during WITH &&);

10Աճ՝ partitioning, պահպանման ժամկետ և արխիվացում

Աղյուսակների մեծ մասին partitioning երբեք պետք չի գալիս։ Բայց հիմնականում append-ով աճող աղյուսակները, որոնք հասնում են հարյուրավոր միլիոնների տողերի, ինչպես events-ը, log-երը, audit trail-երը կամ հին պատվերները, վաղ թե ուշ դրա կարիքն ունեն։ Partitioning-ը մեկ տրամաբանական աղյուսակը բաժանում է ֆիզիկական մասերի ըստ բանալու, սովորաբար՝ ամսական ժամանակային միջակայքով։ Այդ բանալիով ֆիլտրող հարցումները դիպչում են միայն համապատասխան partition-ներին (partition pruning), ինդեքսները մնում են բավական փոքր, որ տեղավորվեն հիշողության մեջ, իսկ պահպանման ժամկետի կիրառումը դառնում է ակնթարթային․ հին partition-ի detach-ը կամ drop-ը փոխարինում է միլիոնավոր տողերի DELETE-ին, որը կուռճացներ աղյուսակը և կծանրաբեռներ replication-ը։ Կանոններ, որոնք պետք է իմանալ․ primary key-ը և յուրաքանչյուր unique constraint պետք է ներառեն partition key-ը՝ և՛ PostgreSQL-ում, և՛ MySQL-ում, բանալիով չֆիլտրող հարցումները սկանավորում են բոլոր partition-ները, և չափազանց շատ partition-ները դանդաղեցնում են պլանավորումը․ հարյուրավորը նորմալ է, տասնյակ հազարները՝ ոչ։ Ապագա partition-ները ստեղծեք նախապես՝ պլանավորված job-ով կամ pg_partman-ի նման ընդլայնմամբ։ Եթե պարտավոր եք պահել detach արված partition-ները, արխիվացրեք դրանք ավելի էժան պահոց։

1CREATE TABLE events (
2  id         bigint GENERATED ALWAYS AS IDENTITY,
3  created_at timestamptz NOT NULL,
4  type       text NOT NULL,
5  payload    jsonb,
6  PRIMARY KEY (id, created_at)
7) PARTITION BY RANGE (created_at);
8 
9CREATE TABLE events_2026_11 PARTITION OF events
10  FOR VALUES FROM ('2026-11-01') TO ('2026-12-01');
11 
12-- retention: instant, no row-by-row delete
13ALTER TABLE events DETACH PARTITION events_2025_11;
14DROP TABLE events_2025_11;

11Բազայի դեմ աշխատող pattern-ներ՝ polymorphic կապեր, EAV և cross-tenant հղումներ

Որոշ տարածված pattern-ներ աննկատ զոհաբերում են ամբողջականությունը։ Polymorphic association-ները, օրինակ՝ մեկնաբանություններ commentable_type-ով և commentable_id-ով, չեն կարող ունենալ foreign key, ուստի որբ տողերն ու տառասխալները աննկատ են մնում։ Այլընտրանքներ՝ յուրաքանչյուր ծնող տիպի համար մեկ nullable foreign key և CHECK, որ ճիշտ մեկն է լրացված, կամ յուրաքանչյուր ծնողի համար առանձին join աղյուսակ։ Entity-attribute-value աղյուսակները (entity_id, attribute, value) ճկուն են թվում, բայց յուրաքանչյուր ընթերցում դարձնում են բազմաթիվ join-եր և ամեն արժեք պահում են որպես տեքստ․ փոփոխական մասի համար JSONB սյունակը, իսկ այն ամենի համար, ինչով ֆիլտրում եք՝ իրական սյունակներ, գրեթե միշտ ավելի լավ է։ Multi-tenant սխեմաներում միայն customer_id-ի վրա foreign key-ը չի խանգարում, որ պատվերը հղի այլ tenant-ի հաճախորդի։ Tenant-ը դարձրեք բանալու մաս․ ծնող աղյուսակում unique constraint (tenant_id, id)-ի վրա, իսկ զավակում՝ composite foreign key (tenant_id, customer_id)։ Այդ դեպքում cross-tenant հղումներն անհնար են հենց կառուցվածքով, ոչ թե code review-ով։

1ALTER TABLE customers ADD CONSTRAINT uq_customers_tenant_id UNIQUE (tenant_id, id);
2 
3ALTER TABLE orders ADD CONSTRAINT fk_orders_customer_same_tenant
4  FOREIGN KEY (tenant_id, customer_id) REFERENCES customers (tenant_id, id);
5 
6-- exclusive arc instead of a polymorphic pair
7ALTER TABLE comments ADD CONSTRAINT one_parent CHECK (
8  num_nonnulls(post_id, product_id) = 1
9);