Ostatnio dostałem za zadanie stworzenie skryptu relacji live z meczów piłkarskich. W trakcie prac projektowych natrafiłem na kilka problemów, chciałbym, żebyście dzieląc się swoją wiedzą pomogli mi je rozwiązać

1. ACL - w relacji występują typy użytkowników: administrator (mający nieograniczone możliwości zarządzania skryptem), komentator (ten który ma za zadanie jedynie komentować spotkanie z poziomu panelu), opcjonalnie jeszcze edytor statystyk (czyli gole, kartki, zmiany, ale np. nie komentowanie). Dotychczas używałem w swoich projektach biblioteki Zend ACL. Jest ona jednak mocno rozbudowana i wg. mnie zbyt ciężka jak na skrypt, który ma być wydajny i nie pamięciożerny. Pytanie: czy znacie jakieś lżejsze odpowiedniki ZendACL? Nie chodzi o to, że sam nie potrafię znaleźć takiej biblioteki w Googlarce, ale każda reklamuje się, że jest szybka, lekka i łatwa w użyciu. Ale która mówi prawdę?

2. JS, AJAX - podobnie jak wyżej, zawsze używałem JQuery. Wydaje mi się, że do tego projektu jest odpowiedni. Oprócz czatu dla użytkowników, komentarzy dodawanych bez przeładowywania przez komentatorów i tak samo działających zakładek oraz wyświetlanych bez przeładowywania komentarzy, nie planuje żadnych wodotrysków. Czy powiniene znaleźć coś lżejszego? Czy okrajać JQuery? Tylko co z update biblioteki w tym przypadku?

3. Cache. Czy warto cache'ować główną stronę relacji? Tzn. komentarze + statystyki (kartki, zmiany, skład)? Co do komentarzy mam szczególne wątpliwości, zdarza się, że dodaje się kilka komentarzy w ciągu minuty. Czy warto zapisywać statystki - po każdym ich uaktualnieniu - do czystego HTML?

4. Baza danych. Na początku planowałem 'zaoszczędzić' na szybkości, tworząc relację tylko pod MySQL. Później pomyślałem, że to idiotyzm i wykorzystam PDO. Jak duża jest różnica wydajności pomiędzy pisaniem pod konkretny sterownik a PDO? Czy słusznie odrzucam tutaj Doctrine, jako niepotrzebne? Myślę, że nie jest to tak rozbudowany projekt, żeby korzystac w nim z ORM.

Sporo tego napisałem, jeśli gdzieś wyraziłem się bezsensownie, niejasno, przepraszam, poprawię Dziękuję za pomoc.

Aj, prawdę mówiąc, myślałem, że chociaż jedna osoba chętna podzielić się swoim doświadczeniem się znajdzie...

Cache -> my Ci nie powiemy, bo to zależy głównie od ruchu, jaki masz na stronie . Jeśli jesteś pewien, że cache po dodaniu nowego opisu przeładuje się wystarczająco szybko, że zostanie wykorzystany przy sensownej liczbie żądań, to myślę, że gra jest warta świeczki. W przeciwnym razie efekt mógłby być odwrotny od zamierzonego.

Baza danych -> PDO tylko na początku było wolniejsze od zwykłych rozszerzeń. Obecnie, jeśli wierzyć benchmarkom, prędkości są porównywalne, więc myślę, że nie ma tutaj co dyskutować nad wyborem sterownika. PDO rządzi i tyle. Również nic nie przeszkadza, by korzystać z Doctrine'a, a w szczególnych miejscach korzystać z czystych zapytań SQL. Doctrine zbudowany jest na bazie PDO i w każdej chwili można dostać się do pierwotnego obiektu.

Cache warto stosować w każdej sytuacji. Jeszcze otwarta jest kwestia jaki. Plikowy, pamięciowy (memcached) czy może oba na raz.
Doctrine jest wolne, nic nie robiąc potrzebuje 2MB pamięci i do tego nie da się kontrolować w pełni zapytań (wybiera nawet to o co nie prosiliśmy i jeszcze aliasuje).
Jquery - cóż, te 26 kB to nie jest chyba aż tak dużo? Większość trzyma się w tych okolicach. Jak ci się nudzi możesz napisać samemu Od strony klienta dwa rdzenie są raczej standardem, JS jest wykonywany też coraz efektywniej. Nie warto sobie zawracać głowy chyba że byś funkcjonalność OS chciał przepisać.
Po czym oceniłeś ociężałość zend_acl? Tylko nie mów że po ilości kodu.

Po czym oceniałem ciężkość? No bez podlizywania wzorowałem się na Zyxie. Ciężar kodu, owszem, ale także prędkość ładowania, ilość zajmowanej pamięci po utworzeniu wszystkich obiektów (zasobów, ról i samego obiektu ACL). Za dużo tego jak na 'szybką relację'.

Wydajność nie jest najważniejsza na samym początku projektu. Ważne byś pisał prosty i czytelny kod. Optymalizację zostawia się na koniec i na pewno nie polega na wybieraniu "lżejszych" bibliotek Robi się cache odpowiednich podstron, poprawia zapytania do bazy.

No oczywiście. ale czy warto strzelać do muchy z armaty? Czy nie ma mniejszych armat?

Chodzi o używanie oprogramowania, które jest rozwijane, które jest znane, które przyda Ci się jak pójdziesz pracować do jakieś firmy. To jest wg mnie kryterium wyboru, a nie to czy to jest duże czy małe. Tego typu dylematy mają początkujący programiści, sam miałem, ale się już z tego wyleczyłem... chodzi o to by poznawać różnego rodzaju oprogramowanie, im większe tym lepiej, więcej się nauczysz (o ile oczywiście masz jakąś podstawową wiedzę i sobie z tym poradzisz).

Na dzień dzisiejszy budowanie ręczne zapytań dla mnie jest abstrakcją, trzeba używać jakiś obiektów. Jest to fajne, ciekawe, zaawansowane, dające dużo satysfakcji z wiedzy jaką się dzięki temu zdobywa.

Oprogramowanie, metody itd. dobiera się raczej na podstawie wymagań niefunkcjonalnych, bo poznawać biblioteki to można w inny sposób, niż przez zajeżdżanie ważnych projektów - to moim zdaniem z kolei jest przesadzanie w drugą stronę . Po prostu należy zachować umiar. Dobierzesz prostą, ale niegenerującą dużego narzutu bibliotekę, to możesz się nie zmieścić w terminach, budżecie, niezawodności i jakości końcowego kodu. Z kolei na uczelni u mnie robiono niedawno nową stronę wydziału i okazało się, że do stronki mającej góra kilkaset odwiedzin dziennie i serwującej w 99% przypadków zwykłe, statyczne teksty, trzeba zakupić serwer dedykowany, bo ktoś wpadł na pomysł, by robić to w Java EE/JBoss. O niewykorzystywanej funkcjonalności nawet nie wspominam . Nie wiem, ile nauczył się projektant, ale z pewnością uznania za swoje niebywałe osiągnięcie nie zyskał.

Po prostu trzeba myśleć racjonalnie i trzeźwo oraz patrzeć na założenia i wymagania, a nie iść za stereotypami czy źle pojmowaną nadgorliwością. Przykładowo, próbuję się po raz któryś z kolei wziąć za pisanie nowego oskryptowania do mojej strony WWW. Wykorzystam Doctrine, gdyż:

1. Z uwagi na ilość dostępnego czasu, gotowe i sprawdzone rozwiązania mają priorytet.
2. Z uwagi na zakładaną funkcjonalność, Doctrine może być bardzo pomocny => niezawodność.
3. W Doctrine już trochę robiłem, więc biblioteka nie stanowi dla mnie novum; mam wypracowaną pewną metodykę pracy z nią, a być może będzie okazja, by nauczyć się kolejnych rzeczy, czyli powód podany przez sf-a.
4. Strona to głównie statyczne treści, relatywnie niewielka ilość odwiedzin jest powiązana z częstością pojawiania się nowych publikacji, zatem te różnice nie będą grać aż takiego znaczenia, gdyż serwer i tak to udźwignie bez problemu. Ponadto zawsze mam do dyspozycji cache.
5. ... albo mogę krytyczne partie napisać w czystym PDO, jeśli okaże się, że rzeczywiście mi to będzie potrzebne.
6. Doctrine się rozwija, śledzę ten projekt mniej lub bardziej regularnie, ale wiem, że autorzy wcale na wydajność sobie nie leją i z kolejnymi wydaniami starają się optymalizować bibliotekę.

Decyzja to wypadkowa tych analiz, a podałem ją jako przykład.

1) czy ktos testowal php 5.3 i "mysqlnd extension as replacement for libmysql for ext/mysql, mysqli and PDO_mysql. (Andrey, Johannes, Ulf)" ?

2) zyx: jakis link do nowych benchmarkow pdo i mysqli? najnowszy jaki znalazlem to styczen 2008 mysqli i pdo