Poczytałem trochę o SQLu i dręczy mnie jedna rzecz.. Szybciej i efektywniej stworzyć kilka procedur i perspektyw w bazie danych, by wszystkim zarządzać, czy do SQLa wysyłać jedynie proste zapytania generowane przez php?
Myślę o tym pod kątem CMSa połączonego z forum.. Przecież można zwykłe zliczanie postów usera zostawić bazie danych, a nie w php. Kodu w php będzie wtedy mniej, ale czy to będzie szybsze?

IMHO baza.

Trochę psuje mi to szyki, bo zmusza mnie do ponownego przemyślenia całego projektu, jaki miałem zamiar pisać.. Oznacza też 'papa' dla phpMyAdmina, do którego się przyzwyczaiłem. No chyba, że ma on gdzieś jakąś możliwość zarządzania zapisanymi w bazie triggerami, procedurami, widokami...

Może ktoś ma inne zdanie i jest w stanie to jakoś ładnie uargumentować?

Zasada jest prosta: Jeśli tylko baza potrafi coś zrobić, to zrobienie tego powinno się na nią zrzucić. Baza zawsze będziesz szybsza przy obróbce zwracanych danych, niż php, które te dane dostanie.

Wybierasz z bazy dane. Przesyłasz je do php a potem musisz w jakichś pętlach (czy nawet nie koniecznie) te dane zmieniać (formatować datę, e.t.c.) - strata czasu.
Lepiej skorzystać z możliwości nazy danych i dostarczyć php dane gotowe do użycia.

phpMyAdmina zamień na SQLyog'a

Mam jeszcze jeden dylemat..
Będę tworzył własny system portalowy, razem z forum i innymi bajerami, co każdy chyba choć raz próbował robić.
W sytuacji, kiedy wiem, że lepiej do php przesyłać jak najlepiej opracowane dane, nie wiem, czy:

pobierając dane powiedzmy dla postów typu:
dane usera, dane posta

robić to w miarę możliwości jednym zapytaniem i potem tylko wstawiać dane do szablonu

czy rozbić jak się da wszystkie dane, osobno czytać dane usera (które się tak często nie zmieniają), osobno każdy post (one również się tak często nie zmieniają), dzięki czemu mogę mocno ograniczyć komunikację z bazą przez użycie cache'a.

Która metoda będzie optymalniejsza? Jeden select, który mi to wszystko przechwyci, czy rozbicie, potencjalne cache'owanie i łączenie w samym php?

Optymalnie jeden select byłby najlepszy (zakładając, że wszystkie dane są Ci potrzebne).. jednak w rzeczywistości tylko z bardzo prostej bazy uda Ci się wyciągnąć wszystkie dane za pomocą jednego selecta. Oczywiście mówię tu o racjonalnych zapytaniach zbudowanych na JOIN'ach a nie zagnieżdżone selecty dopytujące osobną każdą z tabel w bazie.. bo tak też się teoretycznie da wszystko wyjąć na raz ale na pewno jest to bardzo zła droga.
Myślę, że wszystko Ci wyjdzie w praniu..
Na tym forum na przykład na pewno dane user'a są pobierane innym zapytaniem niż posty.. a nawet pewnie inna klasa (choć to phpBB to raczej plik się tym zajmuje.

phpMyAdmin ma listowanie triggerow widokow ale to jest umieszczone w schemacie. Problem jest gorszy bo triggerow wymagane sa specjalne uprawnienia (super) a na to nie kazdy admin pozwala. Ale majac wersje 5.1 mozesz stosowac widoki, funkcje, procedury, jobs.

Zawsze zostaje consola z niej wszystko zrobisz.


W tym przypadku tak.


Twierdzisz ze join jest bardziej wydajni niz podzapytani? Jesli umiejetnie budujesz zapytania to mozesz miec n zagniezdzen i zawsze czas bedzie zadowalajacy. Wazne aby w najnizszym poziomie podselecta byl jak najmniejszy zbior danych. JOIN jest jedna z najbardziej czasochlonna operacja na bazie.

Źle mnie zrozumiałeś. Chodziło mi o to by nie popadać w skrajności.. Zawsze można wyjąć wszystkie potrzebne dane za pomocą jednego select'a ale w rzeczywistości w bardziej złożonych projektach tego nikt nie praktykuje. To tak jakby pisać kod bez funkcji i klas.. też będzie działał szybciej ;-)

Wydaje mi sie ze teraz ty mnie nie zrozumiales. Z tego wywnioskowalem ze piszesz o 1 zapytaniu na jedno rzadanie strony. Mi chodzi o zbiory rekordow.

Przyklad:
Mamy tabele posts, users,

Zapytanie daje id_postu, temat, tresc, imie, nazwisko, gdzie warunkiem bylo np ostatni post usera

Z Twojej wypowiedzi wywnioskowalem ze praktykuje sie wykoanie 2 zapytan. Mozesz to sprostowac?

Nie.. zupełnie o co innego mi chodziło.. może nie potrzebnie dałem skrajny przykład i stąd nie zrozumienie..
Też może zbyt ogólnie potraktowałem pytanie PdM..
Jak najbardziej uważam, że w zapytaniu o konkretne dane kiedy tylko można należy używać jednego selecta.. zresztą chyba nigdy nie zdarzyło mi się inaczej.. też wolę zagnieździć selecta niż dać dwa po sobie, oczywiście mając na uwadze aby wynik zapytania zawierał dane tylko i wyłącznie potrzebne.

[SQL] pobierz, plaintext 
SELECT phpbb_users.*, phpbb_posts.* FROM phpbb_users, phpbb_posts WHERE phpbb_users.user_id = phpbb_posts.poster_id
[SQL] pobierz, plaintext 

Tym zapytaniem wyciągnę informacje o userze oraz informacje o danym poście dla bazy z phpBB (bez treści jeno)

Czy to będzie lepsze, czy zabawa z cache'm, by minimalizować obciążenie bazy danych i te dane, które się tak często nie zmieniają, pobierać z cache'a? Bo jak tak sobie myślę, to arr który odbiorę od bazy dla jednego tylko postu będzie całkiem spory.. Czy to jest optymalne?

Jeśli to MySQL to ma opcje cache'owania sam w sobie i w dodatku domyślnie włączoną, więc nie musisz sobie tym zawracać głowy. Cache'owanie zapytań z poziomu php będzie raczej wolniejsze.

Hmm.... Dajesz mi trochę do myślenia. Tyle, że to będzie oznaczało chyba trochę inne rozplanowanie całej wartstwy 'kontaktu' szablonu z bazą, a raczej bazy z szablonem..

Baza to mysql, za to wersja to jakaś czwóreczka... Czyli widoki i inne bajery odpadają. Pozostaje budowanie ciekawych selectów.. Za triggery, perspektywy, bajery mój ISP (home.pl) każe sobie trochę płacić... Ale wtedy to nie MYSQL a Postgre