Prosta rzeczy, ile różnych obliczeń, operacji itp. robicie w bazie, a ile w tym czym programujecie (bo do PHP nie musimy się ograniczać)?
Bo ja dość sporo operacji, jeśli mogę przerzucam na bazę, z prostego powodu zrobi to szybciej, nie tylko że można sobie funkcje pisać w czym się podoba (prawie) ale też że niektóre rzeczy są optymalizowane.
Wiadomo count() itp. rzeczy robi się na bazie, ale czasem można o wiele więcej, np. system trigger'ów które robią odpowiednie akcje zależne, zamiast pisania tego w kodzie aplikacji. Różne obliczenia na danych z bazy, gdzie zwraca się tylko wynik.

Jak to u Was wygląda, bo kiedyś spotkałem się z opinią że lepiej nie używać niczego co oferują bazy, bo przy wdrążeniu na inną bazę robią się schody.

U mnie okoł 1/5 czasu wykonywania całości to baza. Zauważyłem jednak, że im mniej zapytań stosuję tym lepiej wszystko działa. Nie chodzi tylko o ilość ale też o ich złożoność. Moim zdaniem im mniej robi baza tym lepiej bo zawsze możesz postawić 3 maszyny które wykonują kod a tylko jedną która obsługuje bazę. Jeśli masz więcej niż jedną bazę to sprawy mogą sie skąplikować. To jednak czyste teoretyzowanie

Pozdrawiam.

Wystarczy wdrozyc na inny hosting i juz masz problem.
W prywatnej pracy unikam triggerow i funkcji itp.
Czesto mam klienta co ma hosting gdzie nie ma mysql5 i juz bym mial problem.
Nawet jak ma mysql5 to nie ma prawa na zakladanie triggerow i znowu zonk.

W pracy, gdzie mamy wlasne serwery wszystko co sie da idzie na baze.

jakiś czas temu ktoś dawał link jak różne firmy radzą sobie z dużym trafficiem i tak mi sie zapamiętał ebay gdzie była maksyma żeby język robił wszystko, a baza minimum bo łatwiej postawić kilka serwerów które będą wykonywać skrypty/programy niż kolejną bazę ustawiając wszystkie opcje dot. replikacji itp

Myślę, że ~nospor ma sporo racji, bo jeśli piszemy system dedykowany, to możemy dać bazie więcej pracy. Jeśli jest to jednak system, który musi być instalowalny na różnych platformach, to lepiej grzebać w aplikacji. Myślę więc, że na to pytanie jest jedna, znienawidzona przez wielu maksyma: "zależy od okoliczności"

Pozdrawiam.

Jak będziemy mieli takie podejście to nigdy nie znajdziemy odpowiedzi na nasze pytania

Zastanawiam się... Po co właściwie baza miałaby wykonywać cokolwiek poza selectami i updatami? Moim zdaniem jeśli coś mieści się w wydajności 50%:50% (silnik/baza) to zawsze powinniśmy wybierać silnik. Replikowanie się baz danych to śliski temat i na pewno podczas takich operacji coś się może zepsuć częściej niż replikacja silnika.

Swego czasu było na forum dużo tematów o cachowaniu zapytań do bazy. Jak dla mnie to straszna głupota. Jeśli mamy system który tylko 10% czasu poświęca na zapytania to zwiększenie wydajności zapytań o 50% daje nam tylko 5% przyrostu wydajności całkowitej. Dlatego jeśli mamy mało obciążoną bazę to możemy dać jej spokój a nasze wysiłki skierowac w poprawę wydajności silnika np cachując cały render strony. W ten sposób za jednym zamachem cachujemy także zapytania do bazy.

Dla mnie baza danych jak sama nazwa wskazuje to baza z danymi a nie jakies (liczydlo) i uj mnie strzela jak widze wpisy dat z jakims kosmicznym formatowaniem zamiast znaczkow czasu. Nie rozumiem kolesi z mysql ktorzy rozwijaja swoj produkt w tym kierunku chyba im sie nudzi.

Zgodzę się z tym co napisał Black-Bery że cachowanie zapytań do bazy z reguły ma mały sens. Również raczej staram się cachować całe akcje gdy tylko jest to możliwe.
Ogólnie raczej jestem z tych co przerzucają wszystko na kod. Z bazy korzystam raczej na zasadzie odczyt/zapis. Jakoś nie mogę się przekonać do stosowania trigerrów itp (choć wiem, że to błąd) - raczej daje takie rzeczy w modelu. Powód jest prosty - podczas kodowania łatwiej mi jest połapać się, gdy wszystko mam w jednym miejscu. I tak już śledzenie wszystkich wyzwalaczy w modelu jest trudne a co dopiero gdy przerzucimy część kodu na bazę.
Z drugiej strony wyzwlacze w bazie mają tą zaletę, że nie usunie się ich przypadkowo przy refactoringu.

Co do współdzielonych hostingów to zauważam taką tendencję, że bazy zazwyczaj są wąskimi gardłami - przemawia to dodatkowo na korzyść kodu. Baza często nie jest tak dokładnie monitorowana jak same skrypty przez co zdarzają się userzy wykonujący masakryczne zapytania.

Ja się nie zgodzę z nospor i stwierdzam, że należy używać triggerów. Zresztą ja mu się dziwie, że robi projekty na wersji poniżej MySQL5 bo technicznie te serwisy są w tyle za konkurencją. Zresztą na nazwa już nie ma baz poniżej MySQL5.

Natomiast przenoszenie serwisu z jednej bazy na inną jest sprawą dość delikatną. Kiedyś jak byłem młodszy to jeszcze się w to bawiłem, ale aktualnie to klient musi spełnić wymagania sprzętowe, które zostają określone na samym początku zawarcia umowy. Przecież serwer to jest bardzo mała część ceny serwisu więc w ogóle nie ma mowy by dostosowywać się do tego co sobie kupił kiedyś klient.

No dobrze ale pokazałeś że to nie musi być problem w przypadku kiedy serwis nie jest na tyle duży aby trzeba było duplikować sprzętu. A jakie to ma korzyści? Jasne, że jeśli mamy serię zapytań to warto z niego zrobić jedno triggerem ale chyba lepiej nie przesadzać i stosowac to tylko jeśli znacząco ma się przez to poprawić wydajność. SQL i PHP to tak samo języki skryptowe i nie wydaje mi się żeby przepuszczenie pętli przez trigger działało szybciej niż przepuszczenie jej przez PHP. No chyba że robimy pętlę zapytań To wtedy jak najbardziej trigger żeby za każdym razem nie zwracać wyników.

A co w przypadku aplikacji gdzie baza stanowi 90% Akurat mialem okazje glownie z takimi pracowac - jedna co prawda smigala na dedyku w firmie, a terminale staly obok wiec szybkosc spora. Ale Teraz z kolei pracuje przy tworzeniu aplikacji, ktora prawie w kazdej akcji ciagnie z bazy od cholery requestow - w tym momencie (pomimo poteznych serwerow, zarowno bazy jak i www, load-balancera i innych tego typu) wrzucanie rzeczy do cache'a jest nieunikniona koniecznoscia.

no to chyba logiczne ze jak 90% aplikacji to baza to trzeba ja cachowac... mozna to łątwo wywnioskowac z wypowiedzi ~Black-Berry

No właśnie nie do końca, bo trafi Ci się olbrzymi klient korporacyjny, który używa w całej firmie jednego typu bazy, to dla widzimisię nie ustawi innej, bo musi mieć nowe osoby techniczne itp. itd. Więc czasem bywa że mimo dużych projektów, trzeba zmienić bazę na taką co klient chce.

Jak widać pojawia się problem z rzucaniem pewnych operacji na bazę, jeśli jest ona mocno obciążona. (teraz nie mam głowy aby to przemyśleć, zrobię to później)

Dorzucę jeszcze nie poruszoną rzecz w całej tej dyskusji, jeśli z tej bazy nie korzysta tylko stronka, ale też inne aplikacje, czyli mamy zintegrowany system. Bo wtedy jeśli jakieś operacje muszą być wykonane zawsze na bazie, to przy każdym dodaniu/zmianie trzeba przerabiać kod w co najmniej dwóch aplikacji, co będzie kłopotliwe, a jak to się znajdzie na poziomie bazy, to będzie wspólne miejsce i łatwe do utrzymania.
Jeszcze poruszę taką sprawę, że przy logice na poziomie bazy, da się pilnować operacje które są wykonywane bezpośrednio na niej, bez użycia kodu aplikacji.

Faktycznie jeśli sa 2 aplikacje korzystające z jednej bazy to problem. Zastanów się jednak co by było gdybyś napisał tony triggerów i całą logikę biznesową wrzucił na bazę ? (bo tak wypadałoby zrobić w takim wypadku). Niby wygoda jest bo wszystko w 1 miejscu. Jeśli jednak wszystko zacznie zamulać to budzisz się z ręką w nocniku bo jedyne co pozostaje to replikacje bazy.

• zapytania / zapytania + system
• 0.1117s / 0.14639s
• 0.00585s / 0.04339s
• 0.00471s / 0.05692s
• 0.18388s / 0.25378s
• 0.00512s / 0.04048s
• 0.00507s / 0.04623s
• 0.3443s / 0.37961s
• 0.2653s / 0.29963s

To są czasy działania aplikacji na serwerze anzwa.pl. Zauważcie, że czas wykonywania systemu to ok. 0.004s. i jest w miarę stały. Czasy zapytań wariują. Wniosek z tego prosty, że tylko baza zamula. Tak jak już tu było wcześniej pisane. Wydaje mi się że bazy mySQL są mniej zoptymalizowane niż PHP. Gdyby było inaczej to czemu takie wyniki ?

@Black-Berry
Mówisz, jak duża część, o MySQL, ja częściej stosuję PostgreSQL, a to też jest czubek góry, bo przecież mamy inne bardziej zaawansowane bazy danych, o tym trzeba pamiętać, co jest dobre dla małych stron, a co może się przydać w dużych. Czasem taniej wyjdzie rozłożyć bazę danych na wiele serwerów, niż utrzymywać kod w samych aplikacjach.
Do tego czasem to co robią funkcje na bazie, wymagało by wielokrotnych odwołań do bazy, pobierających multum danych, więc nie jestem przekonany że zawsze było by szybciej.

Oczywiście zgadzam się, że warto przerzucać część na bazę. Ja mówię z perspektywy mojego małego CMS'a którego już piszę 3 rok samodzielnie:) W dużych firmach bazami danych zajmują się nie programiści ale goście od bazy danych i to oni pisza triggery. (Mój kolega ze studiów np jest gościem od baz żeby nie być gołosłownym). Wielkie projekty używają baz oracl'a i zajmują się nimi specjaliści. Zwykli programiści zajmują się czym innym.

Patrząc z perspektywy CMS-ów opartych o php i mySQL nie obciążałbym bazy. Jeśli jednak robisz coś innego to czemu by nie. Jednak triggerami powinien się zająć programista baz danych. Nie wydaje mi się żeby jedna osoba mogła znać się na wszystkim.

Nie czasy zapytań, tylko połączenie i oczekiwanie na odpowiedź z bazy. To jest wąskim gardłem. Kiedyś sprawdzałem to empirycznie - nawet na localhoście skrypt php wykonuje się dłużej, jeśli akurat źle trafi z połączeniem. Same zapytania trwają zwykle podobnie. Nie wiem z czego to wynika, ale możecie sobie sami przetestować licząc międzyczasy.

Pozdrawiam

łoooooo!! Nie wydaje się wam że to bardzo dziwne ? Jakiś bład apacha czy coś ? Nie można przecież tak poprostu źle trafić ?

To policz ile się wykonuje mysql_connect()



Oczywiście to jest desktop, nie serwer - na produkcyjnym rozrzut może być mniejszy i czasy też

No to ja już nie wiem o co chodzi. To nie może przecież działać na zasadzie losowości. To komputer a nie reaktor jądrowy.

Podpisuję się pod tym. Baza jest od przechowywania danych - silnik PHP daje większe możliwości, wydajność, elastyczność etc. - moc silnika łatwo zwiększyć dodając serwer - z bazą gorzej. Dlatego uważam, że o bazę trzeba dbać i nie zlecać jej ablativów absolutów. Gdy mamy problem z wydajnością aplikacji to najczęściej dotyczy on tylko jej fragmentu - jak zamulimy bazę to kaplica, bo wszystkie korzystające z niej aplikacje będą mulić, choćby miały super optymalne silniki.

@Sedziwoju - znalazłem dosyć ciekawy artykuł, równie iekawego autora na ten temat.

Domain Logic and SQL

@LBO
Dzięki, na pewno przeczytam.
Choć artykuł już ma 5 i pół roku, ale zawsze coś naświetli.

Te zagadnienia się nie starzeją

na jednym z kursów na jakich był kolega mówiono ze triggery są złym rozwiązaniem, ponoć ich używanie świadczy o braku kontroli programisty nad bazą danych...

Tak na szybko przykład wymyślony, załóżmy że masz logować zmiany w jakiejś tabeli, czyli robić wersjonowanie.
Na trigger'ach piszesz on update i leci kopia do logu. Teraz bez, piszesz coś co podpięte jest pod możliwość edycji i tam to samo robisz, ale jest pewien problem, bo z bazy korzysta parę aplikacji, więc w każdej musisz to zrobić, do tego jeśli ktoś ma bezpośredni dostęp do bazy to może coś zmienić a nikt tego nie zobaczy.
Za dużo możliwych pominięć.
To jakby mówić że klucze obce są złe, bo powinno się samemu pilnować, a trigger'y po prostu dają o wiele większe możliwości.

Ja to bym rozgraniczył problem dla 2 grup:

• jeśli piszesz silnik gdzi eliczy się maksymalna wydajnosć to bez triggerów
• jeśli aplikację to lepiej ich używać żeby było lepiej widać operacje

Rownie dobrze mozna dac kontr przyklad:
Owszem, niech sie dane zapisuje przy modyfikacji, ale nie dla kazdego. np. chce by zmiany robione przez super admina nie przechodzily przez twoje triggery. I klops. Triger na bazie nie wie czy to robi super admin czy nie. A aplikacja wie

Mozna tak gadac bez konca tylko po co? Moze jednak przyjac wniosek, ktory padl juz tu kilkukrotnie:
wszystko zalezy od sytuacji, od serwisu, od tego co nam w danym projekcie potrzebne

@LBO
Tylko ten artykuł ma jeszcze jedną wadę, autor pisze kod w Ruby, a mnie cholera bierze, już bym wolał pseudo kod, przykłady mają być aby pokazywać o czym jest mowa, a nie pokazywać ile sztuczek się umie w danym języku.

@nospor
W ten sposób podchodząc nie ma co dyskutować o czymkolwiek.

I ja obalałem to że nie ma sensu używać triggerów, a nie że zawsze je się powinno używać, a dałeś antytezę tego, do tego zmieniłeś specyfikacje problemu. Można tez założyć że aby dostać się jako admin ma się inne konto w bazie, a to już pozwala trigger'owi działać zgodnie z Twoimi założeniami. Czy... można wymyślać.

Problem właśnie jest kiedy coś można zrobić na bazie, ale czy powinno się.
Tak jak można dawać bardziej złożone zapytania do bazy, lub pobierać surowe dane i przetwarzać w aplikacji.

@Sedziwoj ja jedynie podsumowalem watek

triggery, procedury są dobre. W duzych projektach, nad ktorymi pracuje w pracy, ich uzywam. Wykorzystujemy baze ile sie da.
W malych projektach co robie prywatnie unikam trigerow i innych takich cudow, bo przyspoza mi wiecej problemow niz pozytku. Wole dana rzecz zrobic w aplikacji.
Dlatego pisze, ze to zalezy od sytuacji. Pytanie w tym temacie jest bardzo ogolne i kazdy bedzie mial swoje zdanie.
Jakby sprecyzowac sytuacje, to mozna by pogadac

Nie każda dyskusja prowadzi do konkretnej odpowiedzi. Akurat ta, która się tu toczy ma jedyne możliwe rozstrzygnięcie: To zależy.
A jak ktoś ma wątpliwości i koniecznie chce znaleźć odpowiedź inną to piszcie

Tak czy inaczej to jest to kolejny wątek o poszukiwaniu jedynej słusznej rozdzielczości

Ech, chyba zbytnio przyjęliście sobie "to zależy". Wątek jest ogólny, ale przecież nikt nie mówi że nie można dawać przykładów bardziej szczegółowych. Chociażby już dwukrotnie podany przeze mnie przykład bazy z której korzysta wiele różnych aplikacji. Do tego mówienie, że u klientów się nie da zawsze zrobić jak "powinno", tylko trzeba to zaznaczyć, ale przez to nie urywać dyskusji.
Choć w sumie nospor już napisał co o tym sądzi, mimo negatywnego podejścia do dalszej dyskusji.

Moim zdaniem jest ważne, że niektóre operacje na poziomie bazy danych są optymalizowane przez silnik, więc koszt wykonania ich tam, jest czasem wielokrotnie niższy, niż jakby miała to zrobić aplikacja.

Ja mogę dodać jeszcze, że ostatnio po przeczytaniu Twojego wątku doszedłem do wniosku, że lepiej zrobić sesję na plikach żeby nie obiążać bazy. Skończyło się tragicznie Pliki tak zmulały, że musiałem na drugi dzień przepisać na wersję z mySQL i od tego czasu śmiga.

Możesz rozwinąć, bo czuję się oskarżony o coś czego nie zrobiłem?

Wnioski były tylko moje (jak już napisałem wcześniej - bardzo błędne). W żadnym wypadku nie twierdzę że zasugerowałeś mi robienie sesji na plikach. Poprostu zacząłem się zastanawiać co byłoby bardziej wydajne. W pierwszej chwili pomyślałem, że wydajniejsze muszą być pliki co okazało się błędnym założeniem.

Wiem, że to wątek bardziej o triggerach więc może gadam bez sensu ale chce zaznaczyć że nie zawsze aplikacja zrobi coś szybciej i lepiej niż baza. Zaryzykowałbym nawet stwierdzenie że jest wręcz przeciwnie ale nie chce teoretyzować bez testów. Jedno jest pewne. Sesja na plikach działa wolniej niż na bazie MySQL bo sprawdziłem w praktyce.

Nie możesz tak mówić - wszystko zależy od konfiguracji i obciążenia poszczególnych elementów. Gdy np. baza zamula to sesja na bazie będzie kiepskim wyjściem. Już o tym pisałem, ale powtórzę, że zdarzyło mi się "przepisać" aplikację na OO z użyciem frameworka. Na localu nowa wersja chodziła wolniej od starej (zdaje się że ponad 2-krotnie) (wiadomo więcej kodu, framework itd), ale na serwerze (współdzielonym) okazało się, że nowa wersja chodzi ponad 2 razy szybciej od starej (na tym samym koncie) - okazało się, że akurat na tym hostingu muliła baza, a nowa wersja miała lepiej skonstruowane zapytania.
W Twoim przypadku mogło być zupełnie odwrotnie - tj. trafiłeś na serwer gdzie baza była nieużywana (albo robiłeś testy na localu) a problem stanowiło dużo operacji na plikach/kiepski dysk twardy itp. Ogólnie praktyka to rzecz względna. W przypadku aplikacji php w ogóle trudno mówić o wydajności jeśli nie stoi ona na dedyku - w innych przypadkach dużo zależy od twoich "sąsiadów".

No ale wracając do triggerów... Trudno mi wyobrazić sobie, że mogłyby one być czymś złym. Jeśli mamy np. metodę dodającą wpis do jakiegoś drzewa to powiedzmy że dzieje się to poprzez 20 zapytań. Jeśli jednak napiszemy sobie triggera który wykona to jednym zapytanie to chyba będzie szybciej. Jak już tutaj ktoś pisał wczesniej najgorsze są czasy oczekiwań. Więc im mniej zapytań tym lepiej. Nie chodzi o ich złożoność ale o ilość.

@Black-Berry:
Jeśli do danej operacji potrzeba wykonania 20 zapytań to użycie triggerów nie wyeliminuje pozostałych 19 jak sugerujesz. Zostaną one i tak wykonane ale zostaną uruchomione bezpośrednio po stronie bazy danych. Aplikacja kliencka odpali jedynie zapytanie, które spowoduje uruchomienie triggera. To tak dla ścisłości.

Ale wracając do głównego tematu wątku. W pracy aktualnie staramy się pisać wszystko z użyciem PostgreSQL. Jak wiadomo daje on dużo większe możliwości niż MySQL (triggery w MySQL są po prostu tragiczne...). Staramy się jak najwięcej pracy zrzucić właśnie na bazę danych. Przykładowo: drzewo kategorii z produktami. Podczas aktualizacji powiązań produkt <-> kategoria automatycznie aktualizowana jest liczba produktów w danej kategorii oraz kategoriach nadrzędnych. Zdecydowanie ułatwia to sprawę szczególnie iż do pracy używamy Symfony. Zastosowanie takiej funkcjonalności bez triggerów komplikowałoby pracę o tyle, iż należałoby (w tym przypadku) modyfikować pliki backendu o "ręczne" wywoływanie koniecznych korekt w bazie.

Rozumiem. Dlatego pisałem że lepiej uruchomić jedno zapytanie po stronie aplikacji bo najbardziej mulą połączenia. A w takiej sytuacji połaczeń będzie nie 20 tylko 1.

Jedyne wnioski jakie ja wyciągam, że użycie triggerów po części wiąże aplikacje z konkretną bazą - tak samo jest z procedurami.
Osobiście mi się to nie podoba, gdyż lubię mieć pełną logikę biznesową w całości po stronie programistycznej.

Mówiąc prościej używałbym Ich gdybym był zmuszony :
1. Pisać aplikację pod już istniejącą bazę.
2. Zapytania wykonywane przez triggery byłyby dla aplikacji transparentne.

Pozdrawiam, Alan

?
To ja nie wiem jaką masz definicję transparentne...

Cała sprawa rozbija się o parę spraw:
- przenośność aplikacji, wiadomo im więcej korzystamy z specyficznych rzeczy tym trudniej
- tym że baza potrafi niektóre rzeczy zoptymalizować, tak jak na poziomie kodu się nie da, bo może Wam się wydaje, że mowa tylko o trigger'ach czy procedurach, ale chodzi też o sortowanie, filtrowanie itd. przecież też da się to zrobić w kodzie, ale jakoś nikt tego nie robi (tylko początkujący), więc może macie apatię do pewnych rzeczy.
- czasami baza jest i tak przeciążona, więc czy zawsze jest to na korzyść pod względem wydajności
- sytuacje kiedy z bazy korzysta wiele aplikacji, jeśli czegoś się nie zrobi na poziomie bazy, trzeba uwzględnić wszędzie.
- nawet przy bezpośrednich operacjach na bazie, jest utrzymywany pewien porządek.
bo chyba o to się cała sprawa rozbija. (wiadomo, że dużo zależy od przypadku, ale można omówić poszczególne i co w nich lepiej wychodzi)

Takie których może nie być w samej aplikacji, dodatek, na bazie którego można ewentualnie zbudować coś innego (statystyki, logi).

edit:

Jest jeszcze jedna rzecz, która skłoniłaby mnie do triggerów. Bezowocna walka z wydajnością, która zmusiłaby mnie nawet do tego, żeby zamiast 2 zapytań wysyłać jedno

A ja powiem że ostatnio `przejechałem` się na trigerach bo okazało się że na serwerze roboczym był mysql 4.x.x i trzeba było przepisać kilka modeli. Aktualnie już nie wykorzystuje trigerów wole zrobić wszystko po stronie php na transakcji.

@wlamywacz:
Jeżeli podchodzisz do roboty "no to jadziem!" to nie dziw się, że potem masz problemy. Najpierw należało wybadać grunt, na którym będziesz stawiał aplikację. Takim podejściem skreślasz triggery w śmieszny sposób. A co jeśli by się okazało, że na serwerze nie ma bazy danych? Pisałbyś, że wolisz robić wszystko na plikach bo nie wszędzie jest baza danych? To co piszesz jest głupie *.

* bez urazy

Nie zgodze się. Co jeśli ktoś (np ja) nastawia się na masówkę ? Wtedy lepiej nie stosować triggerów żeby nie ograniczać sobie klientów.

Różne jaja są. Często bywa tak, że jakaś firma ma stary serwer i chce CMS'a na tym postawić. Jeśli się jej proponuje nowy hosting to robi się kwas. Część starych programó mają na mysql4 i teraz jesli kupią nowy to muszą stare updatować albo opłacać 2 serwery.

No tak tylko zauważ że jedną aplikację robiłem dla kilku klientów. Poza tym ja ustaliłem wymagania dla aplikacji nie on. To jest jak z gramy np. najnowsza gra nie pójdzie Ci na starym sprzęcie.

Aaa i nie było mowy o updacie softu gdyż inne aplikacji by się `sypnęły`

Mając takie podejście to najlepiej w ogóle olać bazę danych, korzystać ze starszych wersji PHP. To, że aplikacja ma być nastawiona na masówkę nie oznacza, że musi być zacofana. Zgodzę się, że nie można stosować jakiś egzotycznych rozszerzeń - to fakt. Ale nie zgodzę się, że powinno się odejść od rozwiązań, które pomogą aplikacji być ciut wyżej pod kątem jakości i zaawansowania kodu.


To coś kiepsko ustaliłeś skoro "okazało się że na serwerze roboczym był mysql 4.x.x".


Strzeliłeś sobie (wam) samobója. Gry mają charakter typowo masowy, a jakoś nie widzę aby producenci wypuszczali gry, które pójdą na kompach sprzed kilku lat. Wszyscy raczej podążają za najnowszymi rozwiązaniami. Pociąga to za sobą oczywiście wzrost wymagań systemowych, ale niewątpliwą zaletą jest (w przypadku gier) poprawa jakości wyświetlanej grafiki.

Kilku klientów to jest masówka jak dla mnie. Jeśli piszesz o grach jako poprawa grafiki to w tej aplikacji ma się to do jej serwisowania i rozbudowy. Tworząc nową akcje etc. operującej na tej tabeli nie musisz za każdym razem uwzględniać tego że zmiany tutaj wywołają skutek gdzieś indziej, ten problem rozwiązuje triger i tyle.

P.S. Skoro piszesz o rozwoju że prawie wszyscy, to po cholerę ja mam się cofać ? `Sorry nie używam flesza, lepiej zrobię kombinację norweską na iframe bo ktoś jest tak leniwy że nie chce mu się zainstalować flesza`. I jeszcze, wymagania były podane przed rozpoczęciem pracy więc mnie to rybka.

No ale co jeśli większość firm w polsce ma jeszcze mysql'a w wersji 4.0; Co z tego że napisze cos na triggerach jeśli będę musiał co 2 aplikację dostosowywać do potrzeb mysql4 zeby coś zarobic. Wiem że może czasem da się znaleźć lepszego klienta ale nie zawsze jest różowo.

No widzisz, trzeba rozgraniczyć sprawę na 2 osobne podejścia: pisanie PRO oraz pisanie typowo dla kasy bez względu na jakość. Jeśli chodzi o pierwsze to w zasadzie wypowiedziałem swoje zdanie wcześniej. Natomiast jeśli chodzi o drugie - w sumie się zgodzę. Chcąc sprzedać swój produkt należy się dostosować do rynku. Nie oznacza to jednak, że to czego wymaga rynek jest dobre. Z drugiej jednak strony jest to nadal świadome wytwarzanie produktu gorszej jakości.


PS: @wlamywacz - ja już nie rozumiem twojego stanowiska... po której stronie jesteś?