== Оптимизација на прашалници и погледи == [[html( Optimizacija i Prashalnici)]] == Оптимизација на прашалници и погледи == ---- == View 1: Најава на корисник (Login view) == * '''Филтри:''' Примарен филтер за погледот `v_user_login` ќе биде според `username`, а дополнително се филтрира само на корисници со статус `ACTIVE`. * '''Употреба:''' е процесот на логирање на клиент во системот. Погледот обезбедува брз пристап до корисничкото име, и статусот на сметката. * '''Иницијално време:''' Иницијалното време за извршување на погледот е 0.315ms. Ова е прифатливо време за апликацијата. * Најбавните операции се две 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 изнесува * Нема потреба да се преуреди прашалникот. * Време на извршување на операциите insert и update останува исто. ---- == View 2: Извештаи (Receipt view) == * '''Филтри:''' Примарен филтер за погледот `v_client_receipts` ќе биде според `client_id`, а дополнително може да се користи и според `transaction_date` (по временски период - месец и година). * '''Употреба:''' Примарен случај на употреба е преглед на издадени сметки за клиент по одреден период. За овој поглед ни се важни перформансите, бидејќи без него се губи време при извршување. * '''Иницијално време:''' Иницијалното време за извршување на погледот e 705ms. Ова е прифатливо време за апликацијата. * Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е * Нема потреба да се преуреди прашалникот. * Време на извршување на операциите insert и update останува исто. ---- == View 3: Рати (Loan installments view) == * '''Филтри:''' Примарен филтер за погледот `v_loan_installments` ќе биде според `loan_id`. * '''Употреба:''' Примарен случај на употреба е кога клиентот или банкарскиот персонал сака да ги прегледа ратите за конкретен кредит. За овој поглед ни се важни перформансите. * '''Иницијално време:''' Иницијалното време за извршување на погледот е 250.5ms. Ова е прифатливо време за апликацијата. * Нема потреба од правење план на извршување, бидејќи времето е задоволително. Пребарувањето по `loan_id` секогаш враќа мал број рати за конкретен кредит, па табелата не се пребарува со висока фреквенција истовремено. Времето на операциите insert и update изнесува * Нема потреба да се преуреди прашалникот. * Времето на извршување на операциите insert и update останува исто. ---- == View 4: Преглед на кредити == * '''Филтри:''' Примарен филтер за погледот `v_loan_details` ќе биде според `loan_id`, а исто така и според `client_id`. * '''Употреба:''' Примарен случај на употреба е целосен преглед на кредитна апликација. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување. * '''Иницијално време:''' Иницијалното време за извршување на погледот e 1s 735ms. Времето е побавно поради повеќе JOIN операции и full scan на табелите Account и Collateral. Ова не е прифатливо за апликацијата. * Најбавните операции се JOIN-овите на Account и Collateral преку `loan_id`, кои немаат индекси на надворешниот клуч. * Времето изминато во извршување на операциите insert и update изнесува * Времето изминато во извршување на query-то со индекси изнесува 781ms, и тоа е прифатливо време. * Времето изминато во извршување на операцијата update по индексирање изнесува ---- == View 5: Трансфери меѓу сметки, трансакции == * '''Филтри:''' Примарен филтер за погледот `v_client_transfers` ќе биде според `sender_client_id`, а дополнително и според `transaction_date`. * '''Употреба:''' Примарен случај на употреба е кога клиентот сака да ги прегледа своите извршени трансфери. За овој поглед ни се важни перформансите. * '''Иницијално време:''' Иницијалното време за извршување на погледот е 68ms. Времето е прифатливо, бидејќи JOIN операциите се базираат на примарни и надворешни клучеви кои веќе имаат индекси. * Најбавните операции не претставуваат значителен проблем. Двојниот JOIN на Account и Client (за испраќач и примач) се изведува ефикасно преку постојните индекси. * Времето на операциите insert и update изнесува * Нема потреба да се преуредува прашалникот. * Времето на извршување на операциите insert и update останува исто. ---- == View 6: Сомнителни трансакции == * '''Филтри:''' Примарен филтер за погледот `v_suspicious_transactions` е `amount > 9000 AND status IN ('PENDING', 'FAILED')`. * '''Употреба:''' Примарен случај на употреба е мониторинг на потенцијално сомнителна активност (AML). За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување. * '''Иницијално време:''' Иницијалното време за извршување на погледот е 8s 15ms. Времето за извршување е побавно поради full scan на табелата Transaction за да се пронајдат записите со висок износ. Ова не е прифатливо за апликацијата, па затоа пристапуваме кон индексирање. * Најбавните операции се full scan на Transaction за филтрирање по `amount` и `status`, и JOIN со Account без индекс на `client_id`. * Времето изминато во извршување на insert и update изнесува * Времето изминато во извршување на query-то со индекси изнесува 669ms, и тоа е прифатливо време. * Времето изминато во извршување на операцијата update по индексирање изнесува ---- == View 7: Вкупна состојба на клиент == * '''Филтри:''' Примарен филтер за погледот `v_account_balance` ќе биде според `client_id`. * '''Употреба:''' Примарен случај на употреба е кога клиентот сака да го провери балансот на своите сметки. Овде се битни перформансите, затоа што сакаме апликацијата да функционира без застој. * '''Иницијално време:''' Иницијалното време за извршување на овој поглед изнесува 88ms. Времето е мало и прифатливо, бидејќи JOIN-овите се на примарни клучеви. * Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операции insert и update изнесува * Нема потреба да се преуреди прашалникот. * Време на извршување на операциите insert и update останува исто. ---- == View 8: Следење на доцнења (Loan Default Monitoring) == * '''Филтри:''' Примарен филтер за погледот `v_loan_default_monitoring` ќе биде според `installment_status IN ('PENDING','LATE')` и `due_date`, со услов `paid_date IS NULL`. * '''Употреба:''' Примарен случај на употреба е кога банкарскиот персонал сака да ги идентификува клиентите кои задоцниле со плаќање. За овој поглед ни се важни перформансите, бидејќи без него се губи многу време при извршување. * '''Иницијално време:''' Иницијалното време за извршување на погледот е 9s 289ms. Иницијалното време за извршување на погледот беше побавно поради full scan на табелата Loan_installment. Ова не е прифатливо време за апликацијата па затоа пристапуваме кон индексирање. * Најбавните операции се full scan на `Loan_installment` без филтрирање на платените рати, и JOIN со Account без covering индекс. * Времето изминато во извршување на INSERT и UPDATE пред изнесува * Времето изминато во извршување на query-то со индекси изнесува 597.9ms, и тоа е прифатливо време. * Времето изминато во извршување на операциите insert и update по индексирање изнесува ---- == View 9: Accounts (сметки) == * '''Филтри:''' Примарен филтер за погледот `v_accounts` ќе биде според `client_id`. * '''Употреба:''' Примарен случај на употреба е преглед на сите сметки на клиент при услуги на шалтер. Овде се битни перформансите. * '''Иницијално време:''' Иницијалното време за извршување на овој поглед е 100ms, што е прифатливо, па затоа нема да имаме потреба од индексирање. * Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е * Нема потреба да се преуредува прашалникот. * Времето на извршување на операциите insert и update останува исто. ---- == View 10: Камати по штедни сметки == * '''Филтри:''' Примарен филтер за погледот `v_savings_interest_payments` ќе биде според `client_id`. * '''Употреба:''' Примарен случај на употреба е кога клиентот сака да ги прегледа добиените камати по период. Овде се важни перформансите. * '''Иницијално време:''' Иницијалното време за извршување на овој поглед е 214ms, што е прифатливо, па затоа нема да имаме потреба од индексирање. * Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е * Нема потреба да се преуредува прашалникот. * Времето на извршување на операциите insert и update останува исто. ---- == View 11: Дневен извештај на филијала == * '''Филтри:''' Примарен филтер за погледот `v_daily_branch_report` ќе биде според `branch_id`, а дополнително и според `report_date`. * '''Употреба:''' Примарен случај на употреба е кога раководството на филијалата или централниот менаџмент сака да ги следи дневните активности. Овде се битни перформансите. * '''Иницијално време:''' Иницијалното време за извршување на погледот е 385ms. Ова е прифатливо време за апликацијата. * Нема потреба од правење план на извршување, бидејќи времето е задоволително. Времето на операциите insert и update е * Нема потреба да се преуредува прашалникот. * Времето на извршување на операциите insert и update останува исто. ---- '''Членови на тим:''' Михаела Ковчегарска 231068[[BR]] Јована Мечева 231124[[BR]] Емилија Костова 231107