Witam
Post skierowany dla programistów, którzy wiedzą coś na temat pisania skryptów, nie polecam tym, którzy nie wiedzą jak utworzyć plik dla serwera z kodem php.....
Sporo programistów popada w ten sam problem. Poruszam ten temat ponieważ druga część programistów może powiedzieć co i jak.

Pomyślmy logicznie
Jeśli skrypt ma być szybko to ma być mało kodu?
Nie koniecznie, ale zależy gdzie...

Zapytania MySQL vs PHP.
MySQL jest do przetrzymywania danych a nie do stosowania skomplikowanych operacji, ale jeśli stawiamy w danym momencie na obciążenie serwera MySQL bo PHP bardziej było by na to podatne lub nie chce się pisać skomplikowanych algorytmów to nie pozostaje nam nic innego ja polecenie MySQL.
Przykładowym wykorzystaniem większego obciążenia serwera MySQL może być polecenie (kod sql forum - mój kodzik)

[SQL] pobierz, plaintext 
/*
Pobieranie danych ostatniego posta z kategorii
*/
SELECT 
forums_posty.id_user AS POSTY_id_user,
forums_tematy.id AS TEMATY_id,
forums_tematy.tytul AS TEMATY_tytul,
forums_posty.DATA AS POSTY_data,
forums_posty.* , forums_tematy.*
FROM forums_posty
LEFT JOIN forums_tematy ON forums_tematy.id = forums_posty.temat
WHERE forums_tematy.kategoria = '".$kategoria->id."' AND forums_tematy.`Delete`='0'
GROUP BY TEMATY_tytul, forums_posty.temat
ORDER BY POSTY_data DESC
LIMIT 1
[SQL] pobierz, plaintext 

Wskazane jest wybierać takie polecenia jeśli PHP miało by się wykonywać o wiele dłużej.

Cache - nawet te najkrótsze stringi.
Wykorzystanie pamięci podręcznej po stronie użytkownika lub po stronie serwera.
Proste logowanie, być może po wielu ulepszeniach może być bardzo przesadne, nie zabijaj serwera, możesz wykorzystać proste rozwiązania.

I - $_SESSION
II - $_COOKIE
III - Zapis pliku na serwerze

$_SESSION stosowane jest wszędzie tam gdzie nie chcesz zasysać danych setki razy!
Przykładem może być prosty kodzik

[PHP] pobierz, plaintext 
<?
$cache = $_SESSION['JAKIES_COS'];
if(empty($cache)){
$get_sql = ['zapytanie mysql z pobraniem danych'];
$_SESSION['JAKIES_COS'] = $get_sql['JAKIES_POLE'];
}
?>
[PHP] pobierz, plaintext 

$_COOKIE jest zapisywane na twoim komputerze, działa to w dwie strony. Przeglądarka wysyła do serwera dane z ciastek/ciastka, i na odwrót jeśli skrypt otwiera sesje COOKIE - setcookie()

Zapis pliku na serwerze stosowane jest głównie do zapisu sparsowanego szablonu w innym miejscu. Najlepszym przykładem jest system szablonów Smarty. Różne typy zapisu cache, zapis sparsowanego szablonu jak i zapis szablonu z całymi danymi, które są wysyłane do wyświetlenia.
Najwięcej informacji na temat Smarty jest w google.pl
Konkretnie polecam http://funkcje.net/view/4/5768/index.html

Jak pisać by napisać dobrze?
Problem dotyczy programistów którzy piszą ciurkiem.
PHP nie jest stworzone do sklejania HTML z PHP, jednak w wielu znanych systemach nie jest wykorzystywany HTML w kodzie źródłowym aplikacji jeśli nie jest potrzebny
Tworzenie pliku index.php, w którym jest "bajzel" - na początku otwarcie sesji, później tagi HTML>HEAD>BODY, następnie PHP do pobrania podstrony i na zakończenie utworzenie stopki to paranoja
Jak wiadomo system Smarty includuje ze soba PHP z HTML ale nie w taki sposób, że miesza ze sobą oba języki.
Przemielenie najpierw PHP, a później wyświetlenie tego w szablonie, w którym są zmienne, które zostały wcześniej utworzone wraz z zapisaniem w nich danych to POPRAWNY KOD

Skrypty - Własny vs darmowy/kupiony
if(Jeśli znasz dobrze PHP to przeczytaj == TRUE){
Z własnego skryptu masz satysfakcję, że to Ty lub Ty i twoja ekipa go napisała.
Korzystanie z darmowych skryptów takich jak darmowy CMS typu PHP-Fusion może trochę razić po oczach, jeśli pokazujesz TAKIE WIELKIE projekty a twoja strona portfolio jest oparta na PHP-Fusion lub Wordpress to jest coś nie tak...

Jeśli otwierasz jakiś projekt/strone www to:
- zrób zwykły index.html z informacją, że serwer jest w budowie
- postaw jakiś skrypt i ciesz się tym co masz przez jakiś czas jako stronę informacyjną
- jeśli masz wstępny projekt aplikacji wersji BETA na tyle zabezpieczony, żeby mogło się trochę z niego skorzystać postaw i nie udostępniaj podstron, których nie przetestowałeś
- darmowe CMS'y nie jest łatwo ogarnąć jeśli nie przysiądziesz do nich
- frameworki z większą dokumentacją daje więcej funkcjonalności ale wiąże ręce, ponieważ i tak drogi są kręte.
- frameworki z mniejszą dokumentacją daje mniej funkcjonalności ale masz większe pole do powiększenia swojej biblioteki klas
}else{
Nie czytaj
}

1) co to są "skomplikowane operacje"?
No to już widzę, że twoje zapytanie nie jest zoptymalizowane a że nie wspomnę o strukturze tabel.

2) Taa "cache" w sesji i ciasteczkach. Może jeszcze listownie pocztą do adresata?

Listownie również

Ty chyba nie masz pojęcia co to jest cache.

3)

Ehe a potem jeszcze zawija w te sreberka... sprawdź co piszesz. Ja zrozumiałem o co chodzi ale gdybym był laikiem z umiejętnością otworzenia sparsowanego pliku .tpl wiedziałbym, że kłamiesz.

hmm a wolisz już obciązać SQL niż PHP?
przetwarzając 2 tabele, w której jedna będzie podstawą do pobierania innych rekordów z drugiej tabeli? miałbyś sporo pętli a tu masz tylko jedną tabele pobraną z SQL'a
jak nie znasz struktury to się nie czepiaj , podałem TYLKO I WYŁĄCZNIE PRZYKŁAD a nie DLA CIEBIE, ŻEBYŚ GO SOBIE WZIĄŁ

cache - łoł a czytałeś to co jest na początku?
po drugie COOKIE to podtrzymywanie sesji zmiennej SESSION
zapis do pliku ... może sam nie korzystałeś z funkcjonalności Smarty do końca jeśli się czepiasz o kolejność wykonywania kodu ...
chodzi tu przekazanie wyniku z PHP a nie wyswietlenie przez echo całego html'a oO

Durnota. Odkąd to dokumentacja świadczy o możliwościach danego frameworka? Odkąd to framework z obszerniejszą dokumentacją "wiąże ręce"? Cały post brzmi jak wypowiedz 13-latka, który chce zaimponować kolegom. Rozważań na temat MySQL nie skomentuję bo są zabawne

nom stop tez nie chce lizać ...
hmm, tu mi się trochę pomyliło
a co do SQL to naprawdę nie widzę sensu krytykowania, może coś więcej na ten temat a nie "bezsensu" żałosne trochę, bo dziecinne zachowanie także świadczy o Twojej wypowiedzi...

Nie zawsze. Czasem nie ma możliwości użycia joina (każda z tabel na osobnym serwerze), wtedy zostaje wyłącznie PHP. Niestety, jeśli aplikacja ma się rozwijać, trzeba większą część logiki przerzucić na interpreter, a nie na SQL.


Wykorzystując do tego sesję praktycznie nie ma żadnego zysku. Z cache skorzysta tylko jeden użytkownik. Do poczytania: http://eriz.pcinside.pl/weblog/cache-danyc...teoria-211.html


Strzał w stopę, tylko zrazisz ludzi.

Nie wiem, co chciałeś osiągnąć tym tematem...

Czytając ten temat a także inne twoje posty wnioskuję, że naprawdę nie znasz się na rzeczy ale na siłę chcesz udowodnić że jest inaczej. Daruj sobie bo zaczyna robić się nie miła atmosfera i broń boże ktoś pójdzie za twoimi radami np tymi w innych postach.

Nie chcąc mi się odpisywać na większość twoich wypocin odpowiem tylko na jedną.

Po zapytaniu widzę jej istotną część a także to, że masz złe zapytanie. Nie trzeba być ekspertem żeby to zauważyć.
Poza tym po tonie widać że rozmawiam z dzieckiem który nie umie prowadzić "dobrej" konwersacji.

Nie siej herezji
ad1: Twój kod jest prościutki i nie obciążający serwera MySQL. Byś widział zapytania jakie piszą tu niektórzy userzy forum to byś się pochlastał... Jedno zapytanie zajmujące podwójna wysokość ekranu. To jest skomplikowane i obciążające zapytanie, którego sama analiza zajęła by Ci kilka minut by się połapać co się dzieje Inna sprawa, że serwer bazy najczęściej jest o wiele szybszy niż interpreter PHP obsługujący te same dane.
ad2. Wywalanie wszystkiego do cache to głupota. W szczególnych przypadkach przynosi to efekty odwrotne do zamierzonych. Zamiast przyspieszać, zwalnia całość działania aplikacji. Systemy cache'owania należy stosować umiejętnie i zgodnie z odpowiednimi przesłankami projektowymi. Poza tym wrzucenie czegoś do sesji ma swoje następstwa. Przykład? Zmień uprawnienia usera w czasie gdy jest on zalogowany, a są one przechowywane także w jego sesji. Do momentu wylogowania zrobi on co chce, posiadając nadal stare. pobrałeś je bowiem raz przy logowaniu i kupa blada. Musisz dodatkowo pisać kod przeładowujące je po zmianach przez admina lub moda. A co jeśli robiłeś to z poziomu bazy danych "na szybko"? Ta sama kupa Od strony cache poczytaj co dał Ci erix. Na cache i różnych jego systemach zna się on bardzo dobrze i wie co pisze. Możliwe, że w tej dziedzinie jest on jednym z najlepszych na tym forum.
ad3) Pisanie ciurkiem jest złe bo łatwo o problemy z nagłówkami, ale php nie robi różnicy czy piszę tak czy siak. Dobrze napisany ciurkiem kod może być równie wydajny jak uporządkowany. I naprawdę mało istotne jest czy mam w nim znaczniki html czy nie. A Smarty to pomieszanie z poplątaniem, które po prostu to co w klamerkach zamienia zgodnie z parserem swoim na kod PHP. Robi więc to, co krytykujesz: miesza php z html, ale w sposób dla Ciebie niewidoczny. Bo co to za różnica między
<p>{$zmienna}</p>
a
<p><?php echo $zmienna; ?></p>
Żadna...
Równie dobrze zamiast Smarty możesz w tym samym pliku przemielić na samym początku całe PHP i wrzucając wyniki do zmiennych by w drugiej części te zmienne po prostu wyświetlać stosując to co podałem jako 2 sposób powyżej. I co? Jedyna różnica będzie polegać na tym, że szablon tpl smarty będzie już wcześniej wrzucony do tpl_cache już jako binarny do którego podepniemy zmienne Wybrać sobie system cache'owania właściwy i mamy to samo bez kobył w stylu systemu szablonów Smarty czy innych.
ad4)
zrób zwykły index.html z informacją, że serwer jest w budowie - nie skomentuję. wystawiasz sobie "fajną" opinię, jeśli takie coś powisi dłużej niż kilka tygodni... wieczna budowa + bezsens związany z trzymaniem serwera i domeny "bo tak"

postaw jakiś skrypt i ciesz się tym co masz przez jakiś czas jako stronę informacyjną - i tak robi wielu korzystając z Wordpressa czy innych darmówek. Zero lub minimum problemów = więcej czasu na dopracowanie projektu.

jeśli masz wstępny projekt aplikacji wersji BETA na tyle zabezpieczony, żeby mogło się trochę z niego skorzystać postaw i nie udostępniaj podstron, których nie przetestowałeś - system w wielu wypadkach zmienia się mocno w trakcie pisania. Zrobienie 60% może wykazać, że trzeba zmienić coś znacząco i co? Zmienisz coś, co userzy już poznali i przyzwyczaili się?

darmowe CMS'y nie jest łatwo ogarnąć jeśli nie przysiądziesz do nich - trudne? Chyba tylko dla kompletnego amatora. Zaawansowany user ten kod przeleci, poprawi błędy twórców i jeszcze podpatrzy ciekawe rozwiązania jakie mogą mu się we własnym przydać.

frameworki z większą dokumentacją daje więcej funkcjonalności ale wiąże ręce, ponieważ i tak drogi są kręte - <facepalm />
frameworki z mniejszą dokumentacją daje mniej funkcjonalności ale masz większe pole do powiększenia swojej biblioteki klas <facepalm2 />
Dokumentacja nie ma nic do funkcjonalności frameworka i jego przydatności. Przykład? Kohana. Ma niemal śladowe ilości dokumentacji a ludzie robią z nią co chcą bo kod ma bardzo przejrzysty i wcale nie trzeba 10 lat programowania w PHP by ją ogarnąć. Ładnie w miarę usystematyzowane wszystko, sensowna wydajność i wiele możliwości bo posiada dużo funkcjonalności (jak na swoją wielkość), które są na starcie potrzebne, a które można prosto poszerzyć o choćby biblioteki innych frameworków. Możesz wziąć sobie coś z Zenda, podpinasz i korzystasz. Koniec. Zend z kolei ma wyrąbaną w porównaniu do innych dokumentację i co? Ma funkcjonalności od groma, a jedyny narzut ma tak naprawdę w wydajności, bo wcale rąk nie wiąże jak sugerujesz. Trzeba bardziej ogarniać samego Zenda i jego biblioteki by zrobić coś szybko.

Zanim więc zaczniesz pisać tekst, który będą doświadczeni userzy po Tobie poprawiać, przeczytaj kilka razy zanim puścisz go w net. Mnie rozłożyło "skomplikowane zapytanie" z jednym LEFT JOIN Rzadko do takiego trywialnego poziomu schodzę. Jeśli mam poniżej 2 to uważam, że korzystam bardzo wybiórczo z danych w bazie. Do samego generowania artykułów z bazy używam przynajmniej 5 tabel (użytkowników, tagów, treści, kategorii, uprawnień). I wykonanie zajmuje setne ułamki sekundy, a najbardziej obciążające, jadące iloczynami kartezjańskimi (tak musi być), góra pół. Na bazę właśnie najczęściej najlepiej przerzucić część zadań (nie zawsze, ale to już kwestia doświadczenia), bo jest szybsza niż interpreter języka.