Optymalizacja zapytań, Jedno zapytanie pobierające wszystkie rekordy, czy kilka z ograniczen Opcje

[Ryder]

Hej,

Mam pytanie co jest bardziej optymalne jedno zapytanie pobierające wszystkie rekordy czy kilka zapytań z klauzulą WHERE.
Przykładowa tabela (liczba rekordów <1000)

article {
- id
- title
- link
- content
- public
- parent
}

Np.
1 | artykuł1 | artykul1 | trest_artykułu1 | 1 | 0
2 | artykuł2 | artykul2 | trest_artykułu2 | 1 | 0
3 | artykuł1-1 | artykul1-1 | trest_artykułu1-1 | 1 | 1
...

Chce pobrać dane, żeby wygenerować menu, submenu, i wyświetlić aktywny artykuł.
Która opcja jest najbardziej korzystna dla niewielkiej strony.

Opcja 1:
Pobranie 1 zapytaniem wszystkich rekordów

[SQL] pobierz, plaintext 
 SELECT * FROM article; 
[SQL] pobierz, plaintext 

Zapisanie danych do tabeli i później operowanie na tej tabeli (foreach, if), żeby wydobyć interesujące dane


Opcja 2
a.) Pobranie menu (Tylko artykuły z parent = 0)

[SQL] pobierz, plaintext 
 SELECT * FROM article WHERE parent = 0;
[SQL] pobierz, plaintext 

b.) Pobranie submenu z podartykułów dla aktywnego artykułu (GET['id'])

[SQL] pobierz, plaintext 
 SELECT * FROM article WHERE parent = GET['id'];
[SQL] pobierz, plaintext 

c.) Pobranie konkretnej tresci artykułu (GET['id'])

[SQL] pobierz, plaintext 
 SELECT * FROM article WHERE id = GET['id']; 
[SQL] pobierz, plaintext 

Opcja 3
Jakieś inne rozwiązania (podzapytania, złączenia, itp)

[nospor]

pobieranie wszystkich rekordow tylko po to by pobrac pare to zły pomysł. Przeciez liczba artykułów bedzie z czasem coraz wieksza.

mozesz pobrac te artykuły abc w jednym zapytaniu poprzez OR w warunku lub mozesz uzyc UNION.
Mozesz te abc rozbic tez na 3 jak to pokazales. Pamietaj jednak, ze a) mozesz spokojnie cachowac. Nie potrzeby za kazdym razem latac do bazy po to.
Na upartego b i c tez mozna cachowac, choc bardziej raczej b

[Pilsener]

A mi się wydaje, że Twoim problemem jest zła organizacja danych, a nie zapytań (wszystko w jednej tabeli). Tworząc model danych należy brać pod uwagę nie tylko "suche" dane, ale także w jaki sposób będą używane, czasami warto trochę skomplikować dodawanie i edycję, by wyświetlanie działało szybciej i sprawniej (np. aktualizować licznik artykułów przy każdej akcji dodania/usunięcia zamiast wykonywać count(*) dla każdego żądania).