[CMS] Przypinanie newsów na szczyt, wydajny sposób, aby to osiągnąć Opcje

[WebCM]

Dużo serwisów wyświetla wybraną nowość na pierwszym miejscu, aby była cały czas widoczna i nie uciekła na inną stronę. Zazwyczaj są one wyróżnione. Czy taka funkcja w CMS-ach jest szczególnie przydatna?

Sposób 1. Opcja "Przypnij"
Dodajemy dodatkowe pole `pin` do tabeli `news`. Redaktor zaznacza opcję Przypnij newsa i już jest na samej górze. Wada tego rozwiązania: większa złożoność obliczeniowa mimo niekorzystania z tej funkcji:

[SQL] pobierz, plaintext 
SELECT * FROM news ORDER BY pin DESC, ID DESC
[SQL] pobierz, plaintext 

Indeks jest tylko na polu ID. Jak widać, trzeba dodatkowo sortować po polu `pin` bez indeksu. To musi trwać dłużej. Pole `pin` przyjmuje wartości 0 lub 1, chyba że dopuścimy większe.

Sposób 2. Data modyfikacji, data zdjęcia
Dodatkowe pole `expiry_time` pozwala wyświetlać news na szczycie do pewnego momentu. Podobnie jak wyżej, rozszerzamy komendę ORDER BY. Wady podobne, a zaleta - news zdejmie się automatycznie.

Sposób 3. Inny sposób?
Jak to zrobić, aby jak najmniej obciążać bazę danych i nie spowalniać generowania strony? Dodatkowo trzeba te newsy wyróżnić - prawdopodobnie po stronie PHP, a w szablonach może być tak:

A może wprowadzić taką funkcję tylko dla stron głównych, które byłyby cachowane?

Kod

<!-- START wyroznione -->
Tu wyróżnione newsy
<!-- STOP -->

<!-- START newsy -->
Tu zwykłe newsy
<!-- STOP -->

To można zastosować też do artykułów, plików i wszystkich typów zawartości.

[WebCM]

Co wyświetla polecenie EXPLAIN?

Gdy sortujemy tylko po kluczu podstawowym ID DESC - using where
Gdy sortujemy dodatkowo po polu pin bez indeksu pin DESC, ID DESC - using where, using filesort
Gdy sortujemy dodatkowo po polu pin z indeksem pin DESC, ID DESC - using where, using filesort

Nie da się posortować newsów, korzystając wyłącznie z indeksów. Trzeba przelecieć całą tabelę. Gdy jest 1000 newsów w 1 kategorii, MySQL uruchamia algorytm quicksort dla 1000 rekordów - tylko po to, aby wyróżnić 1 lub kilka newsów!

Eksperyment z datą

Nałożyłem zwykły indeks na pole date i sortuję po dacie i ID. Nie obędzie się bez algorytmu filesort. Sortuję tylko po dacie - to samo. Dlatego, że w ORDER BY odwołujemy się do innego indeksu niż w instrukcji WHERE.

Kiedy MySQL nie użyje indeksów?

Czytajcie tu: Optymalizacja ORDER BY - kiedy MySQL nie użyje indeksów i algorytm filesort

Mam jeszcze inny pomysł (być może) stosowany w wielu serwisach. Załóżmy, że wyświetlamy 10 newsów na stronie. Baza sortuje tylko po ID lub dacie. Wyróżnionego newsa szukamy po stronie PHP.

Kod

if($news['pin'])
{
  $wyroznione[] = array( /* dane z bazy */ );
}
else
{
  $zwykle[] = array( /* dane z bazy */ );
}

Jeżeli news spadnie na kolejną stronę, nie będzie już wyświetlany na szczycie pierwszej strony!

Które rozwiązanie jest najlepsze?
1) Dodatkowe pole `pin` do przypinania newsów i sortowanie po polu pin i ID
2) Możliwość zmiany daty i sortowanie po dacie
3) Dodatkowe pole `pin`, ale nie sortujemy po nim (przypięte newsy spadną na kolejne strony)
4) Rozwiązać to inaczej - jak?
5) Zbędna funkcja niepotrzebnie obciążająca bazę
6) Dać wybór, jak będą sortowane newsy

Test wykonałem tylko na 3 rekordach. Jutro wstawię losowe wartości i przetestuję na 1000.

Ten post edytował WebCM 19.08.2011, 00:14:43