რა არის სქემები PostgreSQL-ში?

Question

Accepted Answer

PostgreSQL-ში **სქემა** არის **namespace** ბაზის შიგნით — ლოგიკური კონტეინერი, რომელიც დაკავშირებულ ტაბლებს, ხედებს, ფუნქციებს და სხვა ობიექტებს ჯგუფირებს. სქემები საშუალებას გაძლევთ ორგანიზება გაუკეთოთ ობიექტებს და თავიდან აიცილოთ სახელების კოლიზიები; ნაგულიسი სქემა არის `public`.

## სქემები ორგანიზაციას უკეთებენ ობიექტებს ბაზის შიგნით

```text
A PostgreSQL server can have multiple DATABASES.
Each database can have multiple SCHEMAS (namespaces).
Each schema contains TABLES, views, functions, etc.
→ Hierarchy: server → database → schema → tables/objects
```

```sql
CREATE SCHEMA sales;                    -- create a schema
CREATE TABLE sales.orders (...);         -- a table IN the sales schema (qualified name)
SELECT * FROM sales.orders;              -- reference with schema.table

-- the default schema is `public` — unqualified objects go there
CREATE TABLE users (...);                -- actually public.users
```

ობიექტებს ეწოდება `schema.object`. სქემის პრეფიქსის გარეშე, Postgres იყენებს **search path**-ს (ნაგულიssი: `public`).

## Search path-ი

```sql
SHOW search_path;                        -- default: "$user", public
SET search_path TO sales, public;        -- look in sales first, then public
SELECT * FROM orders;                    -- finds sales.orders (no prefix needed)
```

**search path** განსაზღვრავს, რომელი სქემებში ეძებს Postgres არაკვალიფიციური სახელებისთვის — მისი დაყენება შეგიძლიათ უმოკლო სახელებისთვის არჩეული სქემის გამოყენება.

## რატომ გამოვიყენოთ სქემები

```text
✓ ORGANIZATION — group related objects (e.g. `sales`, `inventory`, `auth` schemas)
✓ Avoid naming collisions — two schemas can each have an `orders` table
✓ MULTI-TENANCY — a schema per tenant (isolating each customer's data)
✓ SECURITY/permissions — grant access per schema
✓ Separating concerns — e.g. an `app` schema vs an `analytics` schema
```

ჩვეულებრივი პაттერნი არის **სქემა თითო დამკვეთელზე** მულტი-ტენანტული აპლიკაციებში, ან დომენის/მოდულის მიხედვით ჯგუფირება.

## რატომ არის ეს მნიშვნელოვანი

სქემები არის სასარგებლო PostgreSQL ფუნქციონალობა **ბაზის ობიექტების ორგანიზაციისთვის**, და მათი გაცნობიერება ღირებული არის ბაზების კარგი სტრუქტურირებისთვის, განსაკუთრებით როდესაც ისინი იზრდებიან ან მრავალი დამკვეთელს ემსახურებიან.

ის რომ გაითავსოთ, რომ სქემა არის namespace ბაზის შიგნით (ტაბლებს, ხედებს, ფუნქციებს ჯგუფირებს) — სერვერის იერარქიით → ბაზა → სქემა → ობიექტები — ს ცხადჰყოფს თუ როგორ ორგანიზაციას უკეთებს Postgres ობიექტებს და როგორ უნდა მოიხსენიოთ მათ (`schema.object`, ან rely `search path`-ზე არაკვალიფიციური სახელებისთვის, რომელიც `public`-ს აბრუნებს).

**პრაქტიკული გამოყენების** ცოდნა არის ძირითადი ღირებულება: სქემები უზრუნველყოფენ ორგანიზაციას (დაკავშირებული ობიექტების დომენის/მოდულის მიხედვით გაკრიტიკებას — `auth`, `sales`, `analytics`), თავიდან აიცილებენ სახელების კოლიზიებს (სხვადსხვა სქემებს შეუძლიათ ერთი და იგივე სახელის ტაბლები ჰქონდეთ), ხელმისაწვდომობას იძლევენ სქემის დონის უსაფრთხოებას/ნებართვებს, და ძირითადად აჭარბებენ **მულტი-ტენანტობას** (ჩვეულებრივი პატერნი თითო სქემა ერთი დამკვეთელზე მონაცემების იზოლაციის სახით — მნიშვნელოვანი არქიტექტურული ვარიანტი SaaS აპლიკაციებისთვის).

სქემებისა და search path-ის გაცნობიერება ეხმარებათ ბაზა ნათლად ორგანიზება გაუკეთოთ, თავიდან აიცილოთ `public`-ში ყველაფრის დაყენების აირია და კოლიზიები, და განახორციელოთ პატერნები როგორიცაა მულტი-ტენანტობა.

როდესაც ბაზის ობიექტების ლოგიკური ორგანიზაცია მნიშვნელოვანია შენარჩუნებისთვის (განსაკუთრებით დიდ აპლიკაციებში), და რადგან სქემები ხელმისაწვდომობას იძლევენ მნიშვნელოვან პატერნებს (დომენის გამიჯვნა, მულტი-ტენანტობა, სქემის დონის უსაფრთხოება), PostgreSQL სქემების გაცნობიერება — რა არის ისინი, search path, და მათი პრაქტიკული გამოყენება — ღირებული, პრაქტიკულად შესაბამისი ცოდნა Postgres ბაზების ეფექტურად სტრუქტურირებისთვის, განსაკუთრებით აქტუალური დიდი ან მულტი-ტენანტული აპლიკაციებისთვის სადაც კარგი ობიექტების ორგანიზაცია მნიშვნელოვანია.