== Query Optimization

== View 1: Live offers for customer 

1. Примарен случај на употреба на овој поглед е за добивање на моменталните активни понуди за еден корисник при побарување на такси.

2. Примарен филтер за овој поглед е атрибутот customer_id во релацијата offer

3. Иницијално време на извршување на погледот е 1s и 533ms

[[Image(1.png, width=820px)]]

Ова време е задоволително (помало од 3 секунди), па затоа не е потребно да се извршува оптимизирање на прашалникот.

4. Нема потреба од правење на план за извршување поради тоа што времето е задоволително.
 
5. Иницијалното време за insert и update во табелата offer е:

[[Image(2.png, width=820px)]]
[[Image(3.png, width=820px)]]

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

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

== View 2: Available drivers

1. Примарен случај на употреба на овој поглед е за добивање на слободните возачи во моментот за дадена компанија.

2. Примарен филтер за овој поглед е атрибутот company_id во релацијата employmenthistory.

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

[[Image(4.png, width=820px)]]

Ова време не е прифатливо за нашата апликација, па затоа пристапуваме кон индексизање за оптимизација на прашалникот

4. Најскапи операции се full scan на табелата ride и driver_vehicle:

[[Image(5.png, width=820px)]]

5. Иницијалното време на insert и update во ride и driver_vehicle е:

[[Image(6.png, width=820px)]]
[[Image(7.png, width=820px)]]
[[Image(8.png, width=820px)]]
[[Image(9.png, width=820px)]]

6. Времето потребно за извршување на прашалникот после вметнување на индекс на customerpreferences по атрибутот company_id изнесува 984ms што е прифатливо време:

[[Image(10.png, width=820px)]]
[[Image(11.png, width=820px)]]
[[Image(12.png, width=820px)]]

7. Времето потребно за извршување на insert и update во ride и driver_vehicle изнесува:

[[Image(13.png, width=820px)]]
[[Image(14.png, width=820px)]]
[[Image(15.png, width=820px)]]
[[Image(16.png, width=820px)]]

== View 3: Unassigned requests

1. Примарен случај на употреба овој поглед ќе се користи за добивање на недоделените барања за такси од страна на компаниите во зависност од преференците на корисниците.

2. Примаре филтер би бил атрибутот company_id во customerpreference релацијата.

3. Иницијалното извршување на погледот е 5s и 109ms:

[[Image(17.png, width=820px)]]

Ова време е неприфатливо за апликацијата па затоа извршуваме оптимизирање со користење на индексирање.

4. Најскапи операции се full scan на табелите request и customerpreference:

[[Image(18.png, width=820px)]]

5. Иницијалното време на insert и update на табелата requests е:

[[Image(19.png, width=820px)]]
[[Image(20.png, width=820px)]]

6. Времето потребно за извршување на прашалникот после вметнување на индекс на customerpreferences по атрибутот company_id изнесува 702ms што е прифатливо време:

[[Image(21.png, width=820px)]]
[[Image(22.png, width=820px)]]
[[Image(23.png, width=820px)]]

7. Времето потребно за извршување на insert и update во request после индексирање:

[[Image(24.png, width=820px)]]
[[Image(25.png, width=820px)]]

8. И покрај тоа што се справивме со full scan на табелата ride сеуште времето е незадоволително. Па затоа за подобрување на перформансите прашалникот може да се реструктуира така што ќе се користи limit и offset за имплементација на пагинација при користење на апликацијата:

[[Image(26.png, width=820px)]]

Овој поглед во иднина ќе биде оптимизиран со помош на PostGIS така што ќе се земаат барања во радиус од неколку километри и бројот на редици ќе се намали, а со тоа и потребното време за извршување.

== View 4: Customer payments for rides

1. Примарен случај на употреба на погледот customer_payments_ride е добивање на извештај за сите уплати за возења кои еден корисник ги извршил. 

[[Image(view1k.jpg, width=820px)]]

2. Примарен филтер за овој поглед е атрибутот user_id од релацијата Customer.

3. Иницијално време на извршување на пребарување во погледот customer_payments_ride е 925ms.

[[Image(optimization1k.jpg,width=820px)]]

4. Времето на извршување е задоволително и нема потреба од дополнително оптимизирање. Се зема во предвид и фактот дека корисниците кои ќе ја користат апликацијата најверојатно ретко ќе бараат увид во сите нивни плаќања.

5. Иницијално време на внес на нов запис во табелата Payment е 461ms. 

[[Image(optimization2k.jpg,width=820px)]]

6. Сметаме дека времето е доволно брзо за insert операција во табелата Payment, од таа причина нема потреба од индексирање.

== View 5: Reviews on drivers

1. Примарен случај на употреба на погледот reviews_on_drivers е добивање на преглед на сите оценки и коментари кои биле оставени за еден возач.

2. Примарен филтер на овој поглед е атрибутот user_id од релацоијата Driver.

[[Image(view2k.png,width=820px)]]

3. Иницијално време на извршување на едно пребарување врз погледот е 1s 656ms. Во продолжение е даден планот за извршување на прашалникот и информации за секоја од операциите.

[[Image(optimization3k.png,width=820px)]]
[[Image(analyze1k.png,width=820px)]]
[[Image(analyze2k.png,width=820px)]]

4. Времето на извршување е задоволително и нема потреба од дополнително оптимизирање.

5. Иницијално време за внес на нови вредности во табелата Review e 725ms.

[[Image(optimization4k.jpg.png,width=820px)]]

6. Ова време е прифатливо за корисниците кои за едно возење смеат да остават само еден review.

== View 6: Reports on drivers during rides

1. Примарен случај на употреба на погледот reports_on_drivers_rides е добивање на преглед на пријави поднесени од патници за возачите. 

2. Примарен филтер над овој поглед е атрибутот user_id од ентитетот Driver. 

[[Image(view3k.png,width=820px)]]

3. Иницијално време на извршување на пребарување во погледот е 3s 33ms.

[[Image(optimization5k.png,width=820px)]]
[[Image(analyze3k.png,width=820px)]]
[[Image(analyze4k.png,width=820px)]]

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

5. Иницијално времето на внес на нов запис-пријава во табелата Report e 100ms. 

[[Image(optimization6k.png,width=820px)]]

6. Ова време е идеално за ситуацијата, бидејќи репортите се пријави кои корисниците можат да ги поднесат за време на возењето и истите треба да бидат брзо внесени во системот.