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

1. Jaki sens dawać indeks polu z wartościami 0 i 1? MySQL nawet z niego nie skorzysta.
2. Dodatkowe pole w ORDER BY nie powinno być zabójcze, ale im szybciej, tym lepiej.
3. Cache to dobre wyjście, ale sam cache nie zastąpi implementacji tego wszystkiego.

Zróbmy przykład:

[SQL] pobierz, plaintext 
SELECT * FROM newsy n LEFT JOIN uzytkownicy u ON n.autor = u.ID
WHERE n.kategoria = 1 AND n.opublikowany = 1
ORDER BY n.pin DESC, n.ID DESC
LIMIT 0,10
[SQL] pobierz, plaintext 

Ile dodatkowe pole pin w komendzie ORDER BY spowolni wykonanie zapytania przy dużej i małej ilości danych?

In some cases, MySQL can use an index to satisfy an ORDER BY clause without doing any extra sorting.

Podobny przykład: http://dev.mysql.com/doc/refman/5.0/en/ord...timization.html

MySQL może użyć klucza ID do komendy WHERE, ale sortowanie już odbywa się bez indeksów.

Dodatkowe pole + więcej sortowania - to musi trwać dłużej. Zobaczę, co powie EXPLAIN.