Przede wszystkim są to dwa różne modele danych odpowiednie do różnych celów.
Biorąc to pod uwagę, spodziewam się, że drugi model będzie szybszy do agregacji, po prostu dlatego, że dane są upakowane bardziej kompaktowo, co wymaga mniejszej liczby operacji we/wy:
- GRUPA WG w pierwszym modelu może być spełniona przez pełną skanuj indeks
{size, price}. Alternatywa dla indeksu jest zbyt wolna, gdy dane są zbyt duże, aby zmieścić się w pamięci RAM. - Zapytanie w drugim modelu może zostać spełnione przez pełne skanowanie tabeli. Indeks nie jest potrzebny.
Ponieważ pierwsze podejście wymaga tabeli + indeks, a drugie tylko tabeli, w drugim przypadku wykorzystanie pamięci podręcznej jest lepsze. Nawet jeśli zignorujemy buforowanie i porównamy indeks (bez tabeli) w pierwszym modelu z tabelą w drugim modelu, podejrzewam, że indeks będzie większy niż tabela, po prostu dlatego, że fizycznie rejestruje size i ma niewykorzystane "dziury" typowe dla B-Trees (chociaż to samo dotyczy tabeli, jeśli jest klastrowy
).
I wreszcie, drugi model nie ma narzutu na utrzymanie indeksu, który mógłby wpłynąć na wydajność INSERT/UPDATE/DELETE.
Poza tym możesz rozważyć buforowanie SUM i COUNT w osobnej tabeli zawierającej tylko jeden wiersz. Aktualizuj zarówno SUMA, jak i LICZBA za pomocą wyzwalaczy za każdym razem, gdy wiersz jest wstawiany, aktualizowany lub usuwany w tabeli głównej. Następnie możesz łatwo uzyskać bieżące AVG, dzieląc po prostu SUM i COUNT.
Ale naprawdę powinieneś zmierzyć dla pewności na reprezentatywnych ilościach danych.
Ponieważ w zapytaniu nie ma klauzuli WHERE, wszystkie wiersze zostaną przeskanowane. Indeksy są przydatne tylko do uzyskania stosunkowo małego podzbioru wierszy tabeli (a czasami do skanowania tylko do indeksu ). Ogólna zasada mówi, że jeśli potrzeba więcej niż 10% wierszy w tabeli, indeksy nie pomogą, a DBMS często wybiera pełne skanowanie tabeli, nawet jeśli indeksy są dostępne.
