Changes between Version 47 and Version 48 of AdvancedTopics

Timestamp:

05/22/26 01:59:33 (5 days ago)

Author:

231109

Comment:

--

AdvancedTopics

@@ -104 +104 @@
 Со партиционирањето на табелата Train_Trip добиваме поделба на податоците во месечни табели (партиции) според departure_time. На тој начин пребарувањата се многу побрзи, бидејќи системот чита само податоци од конкретниот месец, наместо целата табела. Ова резултира со подобри перформанси, полесно одржување и поефикасна работа со големи количини на податоци.
 
-
 == 2. Payment табела – партиционирање по transaction_date==
 
+Табелата **Payment** претставува централна финансиска табела во системот, бидејќи ги содржи сите информации за извршените плаќања, како што се износот на трансакцијата, датумот и времето на плаќањето, како и поврзаната резервација.
+
+=== Причини за партиционирање
+- **Константен и брз раст на податоци**
+Секојдневно се генерираат голем број нови трансакции. Со тек на време, оваа табела станува една од најголемите во системот, што може значително да ги намали перформансите при пребарување и обработка на финансиски податоци.
+- **Природна временска структура**
+Секое плаќање има точно дефиниран атрибут transaction_date. Овој атрибут е природно погоден за RANGE партиционирање, бидејќи финансиските записи логички се групираат по временски интервали, а исто така одговара на потребите за финансиско известување и ревизија.
+
+Овие операции бараат временско филтрирање, кое со партиционирање се извршува значително побрзо, бидејќи системот пристапува само до релевантната партиција.
+
+- **Како помага партиционирањето**
+Со примена на годишни партиции, PostgreSQL ги изолира податоците по години. Кога сметководството бара извештај за 2026 година, базата целосно ги игнорира (не ги ни чита на хард дискот) податоците за другите години. Ова обезбедува инстантни резултати на SELECT аналитичките операции и овозможува побрзо архивирање на старите податоци.
+
+- **Default партиција**
+Се користи и DEFAULT партиција која служи како сигурносен механизам за стабилноста на апликацијата. Таа ги прифаќа сите плаќања чии датуми поради системска грешка или неусогласено време паѓаат надвор од предвидениот опсег, со што се спречува паѓање на трансакцијата при купување билет.
+
+=== Kод со објаснување
+
+- **STEP 1: Преименување на старата табела**
+
+[[Image("Screenshot 2026-05-21 185825.png", 800px)]]
+
+-Пред да се направи каква било промена, старата табела се преименува во payment_original. На овој начин сите постоечки финансиски записи остануваат недопрени и може да се користат при миграцијата.
+
+- **STEP 2: Креирање на нова партиционирана табела**
+
+[[Image("Screenshot 2026-05-21 190107.png", 500px)]]
+
+-Се креира новата главна табела Payment со PARTITION BY RANGE (transaction_date). Важно е transaction_date да биде вклучен во PRIMARY KEY – тоа е барање на PostgreSQL кога табелата е партиционирана. Оваа табела сама по себе не чува податоци, туку служи само како логичка обвивка над партициите.
+
+- **STEP 3: Партиција по години**
+
+[[Image("Screenshot 2026-05-21 190326.png", 500px)]]
+
+-Ги прима сите редови што не спаѓаат во дефинираните интервали
+
+-Спречува грешки при INSERT
+
+-Многу важно за стабилен систем
+
+- **STEP 4: Креирање DEFAULT партиција**
+
+[[Image("Screenshot 2026-05-21 190326.png", 500px)]]
+
+-Секој запис чиј transaction_date не спаѓа во опсегот, автоматски завршува во оваа партиција. Ова е важен механизам – без него, INSERT со датум надвор од опсегот би предизвикал грешка и би го нарушил работењето на системот
+
+
+- **STEP 5: Миграција на постоечките податоци **
+
+[[Image("Screenshot 2026-05-21 190958.png", 500px)]]
+
+-Сите записи од payment_original се пренесуваат во новата партиционирана табела. PostgreSQL автоматски одлучува во која партиција оди секој запис врз основа на неговиот transaction_date.
+
+=== Заклучок
+
+Со партиционирањето на табелата Payment добиваме поделба на финансиските трансакции во годишни табели (партиции) според transaction_date. На тој начин пребарувањата се многу побрзи, бидејќи системот чита само податоци од конкретната година, наместо целата табела. Ова резултира со подобри перформанси, полесно одржување и поефикасна работа со големи количини на трансакциски податоци.