Оптимизација на прашалници и погледи

View 1: Најава на корисник (Login view)

1. Филтри: Примарен филтер за погледот v_user_login ќе биде според username, а дополнително се филтрира само на корисници со статус ACTIVE.

2. Употреба: е процесот на логирање на клиент во системот. Погледот обезбедува брз пристап до корисничкото име, и статусот на сметката.

3. Иницијално време: Иницијалното време за извршување на погледот е 0.315ms. Ова е прифатливо време за апликацијата.

4. Најбавните операции се две Index Scan операции:
   • Index Scan на табела client_user преку индексот client_user_username_key - Actual Total Time: 0.039ms
   • Index Scan на табела client преку индексот client_pkey - Actual Total Time: 0.013ms

• Вкупниот Nested Loop завршува за само 0.056ms. Бидејќи се работи за Index Scan (не Full Scan), операциите не можат значително да се подобрат со дополнителни индекси.

• Времето изминато во извршување на операциите insert и update изнесува

5. Нема потреба да се преуреди прашалникот.

6. Време на извршување на операциите insert и update останува исто.

View 2: Извештаи (Receipt view)

1. Филтри: Примарен филтер за погледот v_client_receipts ќе биде според client_id, а дополнително може да се користи и според transaction_date (по временски период - месец и година).

2. Употреба: Примарен случај на употреба е преглед на издадени сметки за клиент по одреден период. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување.

3. Иницијално време: Иницијалното време за извршување на погледот e 705ms. Ова е прифатливо време за апликацијата.

4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

5. Нема потреба да се преуреди прашалникот.

6. Време на извршување на операциите insert и update останува исто.

View 3: Рати (Loan installments view)

1. Филтри: Примарен филтер за погледот v_loan_installments ќе биде според loan_id.

2. Употреба: Примарен случај на употреба е кога клиентот или банкарскиот персонал сака да ги прегледа ратите за конкретен кредит. За овој поглед ни се важни перформансите.

3. Иницијално време: Иницијалното време за извршување на погледот е 250.5ms. Ова е прифатливо време за апликацијата.

4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Пребарувањето по loan_id секогаш враќа мал број рати за конкретен кредит, па табелата не се пребарува со висока фреквенција истовремено. Времето на операциите insert и update изнесува

5. Нема потреба да се преуреди прашалникот.

6. Времето на извршување на операциите insert и update останува исто.

View 4: Преглед на кредити

1. Филтри: Примарен филтер за погледот v_loan_details може да биде според loan_id, или според client_id.

2. Употреба: Примарен случај на употреба е целосен преглед на кредитна апликација. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување.

3. Иницијално време: Иницијалното време за извршување на погледот e 1s 735ms. Времето е побавно поради повеќе JOIN операции и full scan на табелите Account и Collateral. Ова не е прифатливо за апликацијата.

4. Најбавните операции се JOIN-овите на Account и Collateral преку loan_id, кои немаат индекси на надворешниот клуч.

• Времето изминато во извршување на операциите insert и update изнесува

5. Времето изминато во извршување на query-то со индекси изнесува 781ms, и тоа е прифатливо време.

6. Времето изминато во извршување на операцијата update по индексирање изнесува

View 5: Трансфери меѓу сметки, трансакции

1. Филтри: Примарен филтер за погледот v_client_transfers ќе биде според sender_client_id, а дополнително и според transaction_date.

2. Употреба: Примарен случај на употреба е кога клиентот сака да ги прегледа своите извршени трансфери. За овој поглед ни се важни перформансите.

3. Иницијално време: Иницијалното време за извршување на погледот е 68ms. Времето е прифатливо, бидејќи JOIN операциите се базираат на примарни и надворешни клучеви кои веќе имаат индекси.

4. Најбавните операции не претставуваат значителен проблем. Двојниот JOIN на Account и Client (за испраќач и примач) се изведува ефикасно преку постојните индекси.

• Времето на операциите insert и update изнесува

5. Нема потреба да се преуредува прашалникот.

6. Времето на извршување на операциите insert и update останува исто.

View 6: Сомнителни трансакции

1. Филтри: Примарен филтер за погледот v_suspicious_transactions е amount > 9000 AND status IN ('PENDING', 'FAILED').

2. Употреба: Примарен случај на употреба е мониторинг на потенцијално сомнителна активност. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување.

3. Иницијално време: Иницијалното време за извршување на погледот е 8s 15ms. Времето за извршување е побавно поради full scan на табелата Transaction за да се пронајдат записите со висок износ. Ова не е прифатливо за апликацијата, па затоа пристапуваме кон индексирање.

4. Најбавните операции се full scan на Transaction за филтрирање по amount и status, и JOIN со Account без индекс на client_id.

• Времето изминато во извршување на insert и update изнесува

5. Времето изминато во извршување на query-то со индекси изнесува 669ms, и тоа е прифатливо време.

6. Времето изминато во извршување на операцијата update по индексирање изнесува

View 7: Вкупна состојба на клиент

1. Филтри: Примарен филтер за погледот v_account_balance ќе биде според client_id.

2. Употреба: Примарен случај на употреба е кога клиентот сака да го провери балансот на своите сметки. Овде се битни перформансите, затоа што сакаме апликацијата да функционира без застој.

3. Иницијално време: Иницијалното време за извршување на овој поглед изнесува 88ms. Времето е мало и прифатливо, бидејќи JOIN-овите се на примарни клучеви.

4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операции insert и update изнесува

5. Нема потреба да се преуреди прашалникот.

6. Време на извршување на операциите insert и update останува исто.

View 8: Следење на доцнења (Loan Default Monitoring)

1. Филтри: Примарен филтер за погледот v_loan_default_monitoring ќе биде според installment_status IN ('PENDING','LATE') и due_date, со услов paid_date IS NULL.

2. Употреба: Примарен случај на употреба е кога банкарскиот персонал сака да ги идентификува клиентите кои задоцниле со плаќање. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување.

3. Иницијално време: Иницијалното време за извршување на погледот е 9s 289ms. Иницијалното време за извршување на погледот беше побавно поради full scan на табелата Loan_installment. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање.

4. Најбавните операции се full scan на Loan_installment без филтрирање на платените рати, и JOIN со Account без covering индекс.

• Времето изминато во извршување на INSERT и UPDATE пред изнесува

5. Времето изминато во извршување на query-то со индекси изнесува 597.9ms, и тоа е прифатливо време.

6. Времето изминато во извршување на операциите insert и update по индексирање изнесува

View 9: Accounts (сметки)

1. Филтри: Примарен филтер за погледот v_accounts ќе биде според client_id.

2. Употреба: Примарен случај на употреба е преглед на сите сметки на клиент при услуги на шалтер. Овде се битни перформансите.

3. Иницијално време: Иницијалното време за извршување на овој поглед е 100ms, што е прифатливо, па затоа нема да имаме потреба од индексирање.

4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

5. Нема потреба да се преуредува прашалникот.

6. Времето на извршување на операциите insert и update останува исто.

View 10: Камати по штедни сметки

1. Филтри: Примарен филтер за погледот v_savings_interest_payments ќе биде според client_id.

2. Употреба: Примарен случај на употреба е кога клиентот сака да ги прегледа добиените камати по период. Овде се важни перформансите.

3. Иницијално време: Иницијалното време за извршување на овој поглед е 214ms, што е прифатливо, па затоа нема да имаме потреба од индексирање.

4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

5. Нема потреба да се преуредува прашалникот.

6. Времето на извршување на операциите insert и update останува исто.

View 11: Дневен извештај на филијала

1. Филтри: Примарен филтер за погледот v_daily_branch_report може биде според branch_id, а дополнително и според report_date.

2. Употреба: Примарен случај на употреба е кога раководството на филијалата или централниот менаџмент сака да ги следи дневните активности. Овде се битни перформансите.

3. Иницијално време: Иницијалното време за извршување на погледот е 385ms. Ова е прифатливо време за апликацијата.

4. Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е

5. Нема потреба да се преуредува прашалникот.

6. Времето на извршување на операциите insert и update останува исто.