[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.

[Noidea]

Tak jak wyżej wspomniałeś mysql nie korzysta z indeksów nałożonych na kolumnach ze zbyt małym zróżnicowaniem danych, bo mu się to nie opłaca. Z tym, że w przypadku 1000 tematów, z czego 2 są przypięte, indeks znalazłby zastosowanie. Powody mogą być dwa:
- Optymalizator widzi coś, czego ty nie widzisz
- Optymalizator jest zbyt głupi i trzeba mu podpowiedzieć, żeby korzystał z indeksu (LINK)

Ja obstawiam pierwszą wersję. Indeks pin to drzewo o 2 gałęziach, a w każdej z nich jest lista z adresami wierszy. Jako że indeksy działają tylko w jedną stronę (na podstawie wartości indeksu da się odnaleźć adres wiersza, ale na podstawie adresu nie da się odnaleźć wartości), to indeks ID staje się bezużyteczny. Więc masz 2 grupy adresów wierszy, które trzeba odczytać, wyciągnąć z nich pole ID i posortować - także zysku w wydajności nad zwykłym filesortem nie ma. I tak tez twierdzi optymalizator mysql.
Zamiast indeksu na kolumnie `pin`, utwórz indeks na parze kolumn: `pin`, `ID`

PS. Ilość wierszy tabeli też ma wpływ na decyzje optymalizatora, wiec testuj to na więcej niż 3 wierszach (IMG:style_emoticons/default/smile.gif)
PS2. Dodatkowa lektura:
http://stackoverflow.com/questions/231125/...d-in-sql-server
http://webmonkeyuk.wordpress.com/2010/09/2...-2-cardinality/

Ten post edytował Noidea 19.08.2011, 08:56:31