Query Optimization

View1: Baggage Details

1. Примарното филтрирање на погледот BaggageDetails ќе биде според id на картата (ticketId).
2. Примарен случај на употреба ќе биде пребарување на статусот (локацијата) на одреден багаж (кој припаѓа на одреден патник или е на одреден лет).
3. Иницијалното време за извршување на погледот е 1s 524ms.

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

4. Најбавните операции се full scan на табелите baggage и baggageStatus.
5. Времето изминато во извршување на операциите insert и update изнесувa

Креирање на индекс во табелата baggage на ticketId

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

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

View2: Airplane Availability

1. Примарното филтрирање на погледот AirplaneAvailability ќе биде според местото на последната дестинација на авионот (LastFlightDestination).
2. Примарен случај на употреба ќе биде пребарување на авион којшто се наоѓа на потребната локација.
3. Иницијалното време на извршување на погледот е 1min 20s 558ms

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

4. Најбавните операции се full scan на табелата flight
5. Времето изминато во извршување на операциите insert и update пред индексирање изнесува:

Креирање на композитен индекс на табелата flight на аirplaneId и departure

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

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

View3: Cargo Details

1. Примарното филтрирање на погледот CargoDetails ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде приказ на тоа кој багаж припаѓа на патниците, а кој е дополнителен багаж на летот.
3. Иницијалното време на извршување на погледот е 2s 518ms.

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

4. Најбавните операции се full scan на табелите baggage, ticket и additionalCargo.

5. Времето изминато во извршување на операциите insert и update во табелите additionalCargo и baggage изнесувa:

Креираме индекс на табелата ticket на flightId

6. Времето изминато во извршување на query-то со индекси изнесува 1s 862ms, и тоа може да се каже дека е прифатливо време (бидејќи табелите содржат 10 милиони записи).

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

View4: Certification Expiry Status

1. Примарното филтрирање на погледот CertificationExpiryStatus ќе биде според id на вработениот (employeeId).
2. Примарен случај на употреба ќе биде статусот на сертификатите на вработен во авиокомпанијата.
3. Иницијалното време на извршување на погледот е 519ms.

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

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

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

View5: Crew Availability

1. Примарното филтрирање на погледот CrewAvailability ќе биде според последната дестинација на летот (lastFlightDestination) и според типот на вработениот (employeeType).
2. Примарен случај на употреба ќе биде приказ на тоа кој тип на вработен каде се наоѓа според неговиот последен лет.
3. Иницијалното време на извршување на погледот е 23min 52s 786ms.

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

4. Најбавните операции се full scan на табелата flight.
5. Времето изминато во извршување на операциите insert и update во табелата flight изнесувa:

Креираме композитни индекси на табелата flight на pilot и departure, како и на copilot и departure

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

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

View6: Flight Cargo Statistics (materialized view)

1. Примарното филтрирање на погледот FlightCargoStatistics ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде извештај со статистика за багажот на одреден лет.
3. Времето на креирање на погледот е 12s 23ms, за извршување изнесува 409ms, а времето за refresh на погледот е 10s 915ms.

Креирање на погледот

Извршување

Refresh

Ова е прифатливо време за апликацијата, бидејќи query-то нема да се извршува многу често, па нема потреба од оптимизација. Времето изминато во извршување на операциите insert и update изнесува:

View7: Flight Details

1. Примарното филтрирање на погледот FlightDetails ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде приказ на детали за сите летови.
3. Иницијалното време на извршување на погледот е 355ms.

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

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

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

View8: Item Flight Details

1. Примарното филтрирање на погледот ItemFlightDetails ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде приказ на тоа кои производи се продаваат на одреден лет и детали за број на продадени производи и заработка од тоа.
3. Иницијалното време на извршување на погледот е 354ms.

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

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

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

View9: Meal Flight Details

1. Примарното филтрирање на погледот MealFlightDetails ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде приказ на тоа кои оброци се служат на одреден лет и детали за број на послужени и останати оброци.
3. Иницијалното време на извршување на погледот е 350ms.

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

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

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

View10: Mechanic Details

1. Примарното филтрирање на погледот MechanicDetails ќе биде според id на механичарот (mechanicId).
2. Примарен случај на употреба ќе биде приказ на тоа кои поправки ги правел даден механичар.
3. Иницијалното време на извршување на погледот е 340ms.

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

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

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

View11: Passenger Loyalty Program (materialized view)

1. Примарното филтрирање на погледот PassengerLoyaltyProgram ќе биде според id на патникот (passengerId).
2. Примарен случај на употреба ќе биде извештај со поените на патникот добиени од програмата за лојалност, колку пати летал, број на потрошени средства, најфреквентното место од каде што лета, како и најпосетуваната дестинација.
3. Времето на креирање на погледот е 17s 739ms, за извршување изнесува 409ms, а времето за refresh на погледот е 10s 915ms.

Креирање на погледот

Извршување

Refresh

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

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

View12: Repair Details

1. Примарното филтрирање на погледот RepairDetails ќе биде според id на авионот (flightId).
2. Примарен случај на употреба ќе биде приказ на детали за поправките на одреден авион.
3. Иницијалното време на извршување на погледот е 345ms.

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

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

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

View13: Seat Availability

1. Примарното филтрирање на погледот SeatAvailability ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде приказ на тоа кои седишта се слободни, а кои не на одреден лет.
3. Иницијалното време на извршување на погледот е 441ms.

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

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

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

View14: Ticket Details

1. Примарното филтрирање на погледот TicketDetails ќе биде според id на летот (flightId) или според id на патникот (passengerId).
2. Примарен случај на употреба ќе биде приказ на тоа кои карти ги има купено одреден патник, или кои патници треба да летаат на одреден лет.
3. Иницијалното време на извршување на погледот е 1s 88ms кога филтрираме според flightId, а кога филтрираме според passengerId изнесува 1s 333ms.

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

4. Најбавните операции се full scan на табелата ticket.
5. Времето изминато во извршување на операциите insert и update изнесувa:

Креираме индекс на табелата ticket на flightId

6. Времињата изминати во извршување на прашалниците со индекси изнесуваат 347ms и 352ms, и тоа е прифатливо време на извршување.
7. Времето изминато во извршување на операциите insert и update по индексирање изнесува:

View15: Ticket Revenue Details (materialized view)

1. Примарното филтрирање на погледот TicketRevenueDetails ќе биде според id на летот (flightId).
2. Примарен случај на употреба ќе биде извештај вкупна заработка од продадени карти за летови.
3. Времето на креирање на погледот е 3s 675ms, за извршување изнесува 384ms, а времето за refresh на погледот е 3s 501ms.

Креирање на погледот

Извршување

Refresh

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

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