Query Optimization

View 1: Live offers for customer

1. Примарен случај на употреба на овој поглед е за добивање на моменталните активни понуди за еден корисник при побарување на такси.
2. Примарен филтер за овој поглед е атрибутот customer_id во релацијата offer
3. Иницијално време на извршување на погледот е 1s и 533ms

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

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

6. Нема потреба да се преуреди прашалникот
7. Времето на извршување на операциите останува исто

View 2: Available drivers

1. Примарен случај на употреба на овој поглед е за добивање на слободните возачи во моментот за дадена компанија.
2. Примарен филтер за овој поглед е атрибутот company_id во релацијата employmenthistory.
3. Иницијално време на извршување на погледот е 3s и 982ms:

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

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

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

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

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

View 3: Unassigned requests

1. Примарен случај на употреба овој поглед ќе се користи за добивање на недоделените барања за такси од страна на компаниите во зависност од преференците на корисниците.
2. Примаре филтер би бил атрибутот company_id во customerpreference релацијата.
3. Иницијалното извршување на погледот е 5s и 109ms:

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

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

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

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

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

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

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

View 4: Customer payments for rides

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

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

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

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

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

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

View 5: Reviews on drivers