Wypowiedzi
-
MaySay (http://www.maysay.com)- 16.11.2011, 16:35
-
Witaj
Po pierwsze zapisywanie czegokolwiek do bazy w formie CSV (comma separated values czyli właśnie "po przecinkach") jest tragedią jeśli COKOLWIEK chcesz z tytmi danymi robić. Np wyobraź sobie, ze chcesz znaleźć wszystkie wpisy z wybraną konkretną opcją... W twojej wersji się tego zrobić po prostu NIE DA (no dobra, można robić LIKE na stringach, ale to nie zawsze będzie poprawnie działać). Miałem nieprzyjemność pracować z taką bazą danych i to jest kosmos.
Zatem od początku. Upraszczam i korzystam z Twojego kodu, choć generalnie nie jest najpiękniejszy.
Baza danych:
tb_rezerwacje:
id: int
ilosc_pasazerow: int
tb_rezerwacje_opcje:
id: int auto_increment PRIMARY KEY
id_tb_rezerwacje: int
id_tb_opcje_wyposazenia: int
Kod w szablonie:
while($rek = mysql_fetch_array($wynik))
{
echo "</br>";
echo $rek['nazwa']. '<input type=checkbox name="opcje[]" value="'.$rek['nazwa'].'">';
echo $rek['cena'].".00 PLN";
}
}
czyli to samo
Kod do wstawiania:
<?php
$id = intval(trim($_GET['id'])); //Co ty, samobójca? Użytkownik nadpisze i SQL injection masz jak w banku
...
$ins = @mysql_query("UPDATE tb_rezerwacje SET ilosc_pasazerow='$ilosc_pasazerow' WHERE id='$id' ");
// ID dodanego rekordu
$id = mysql_insert_id();
//Czyścimy stare opcje
if ($id)
{
mysql_query("DELETE FROM tb_rezerwacje_opcje WHERE id_tb_opcje_wyposazenia=".$id);
foreach ($_POST['opcje'] as $opcja)
{
mysql_query("INSERT INTO tb_rezerwacje_opcje(id_tb_rezerwacje, id_tb_opcje_wyposazenia) VALUES(".$id.", ".intval($opcja).")");
}
}
Mniej więcej coś takiego. Na sucho pisane, to i błędy moga się znaleźć oczywiście ale jakby co to poprawię :)
BTW - oczywiście zakładam, że instrukcje echo w kodzie służą TYLKO do debugu aplikacji i później je usuniesz. W produkcyjnej powinieneś rozdzielić wyświetlanie od przetwarzania - na przykład zapisując komunikaty o błędzie w jakiejś zmiennej i po wykonaniu wszystkiego je wyświetlając. Ioczywiście opakowując cały ten kod w jakąś funkcję albo lepiej klasę.Tomasz Struczyński edytował(a) ten post dnia 17.12.10 o godzinie 10:08
-
@ja: Te "hooki" to tak naprawdę wspomniane przez Damiana filtry i zdarzenia. Wordpress jest systemem opartym na zdarzeniach w dużym stopniu :)
@Damian, dzięki za odnośniki, ciekawe arty. Choć raczej do zastosowania przy pisaniu systemu od poczatku, a nie zawsze przy podpinaniu się do cudzego systemu. Tu trzeba brać pod uwagę istniejące rozwiązania. Ale przyjemne wsparcie teoretyczne w rodzimym języku.
@Oskar mimo wszytko "zacząłem". Taki OT, przepraszam :)Tomasz Struczyński edytował(a) ten post dnia 15.09.10 o godzinie 15:06
-
To się dorzucę odrobinę:
Po pierwsze - jak przedmówcy oparłbym to o mechanizm Wordpressa. Nie jest on doskonały - np nie ma w nim mechanizmu ustawiania zależności między wtyczkami, ale da się to "obejść". Dyskusje w bugtrackerze wordpressa odrzuciły taki mechanizm, ktoś zasugerował w zamian "gracefull degradation" - to znaczy wtyczka działa na tyle na ile może - jak nie ma jakiejś funkcjonalności to jej nie włącza. W Twoim przypadku - jeśli nie ma głównego modułu to nie włącza praktycznie nic.
Druga sprawa to to jak taką wtyczkę napisać. Tu kolejny powód dla którego proponuję mechanizm natywny. Wordpress ma całkiem rozbudowany system obsługi zdarzeń, który najłatwiej jest wykorzystać korzystając z wtyczki. Co więcej, pozwala na dodawanie własnych zdarzeń.
Twój główny moduł zarejestuje w systemie (tj w praktyce będzie wywoływał) X zdarzeń (hooks). W tym momencie widze m.in zdarzenie samej płatności, wyświetlenia strony konfiguracji (żeby zebrać konfiguracje płatności w jednym miejscu - choć każda wtyczka może oczywiście dodać własny wpis w menu), hook do generowania listy dostępnych płatności, nie wiem , co tam jeszcze. Wtyczki płatności "podepną się" pod te hooki wykonując swój kod. Komunikacja pomiędzy nimi i głównym modułem bedzie się odbywała wyłącznie przez hooki wordpressa
Więcej o hookach
http://codex.wordpress.org/Plugin_API
Przykładowy schemat operacji.
Użytkownik wchodzi na stronę płatności. Moduł główny wywołuje na liście płatności funkcję apply_filters($sposobyPłatnosci). Pluginy wcześniej zarejestrowały swoje funkcje dla tego filtru i teraz moduł dostaje tablicę z dostępnymi płatnościami.
Klient wybiera jedną z płatności i wysyła formularz. Moduł główny wywołuje akcję (do_action) 'platnosc' z parametrem typu płatności. Moduł konkretnej płatności przejmuje sterowanie, wyświetlając odpowiednio kolejne strony.
Pod koniec wywołuje akcję zarejestrowaną przez moduł główny - payment_accepted albo payment_rejected. Moduł główny juz wie, co ma z tym zrobić....
Punkt drugi jest nieco "śliski", ładniej byłoby napisać to z użyciem klasy. Może być tak, że apply_filters($sposobyPłatnosci) zwraca ci tablicę klas implementujących interfejs płatności. I używasz metod tych klas do wyswietlenia listy płatności ( niech np mają w sobie __toString()) i do wywołania płatności w punkcie 2 ($klasaPlatnosci->pay()).
Wykorzystanie wtyczek wordpressa przyda Ci się jesli bedziesz musiał w module płatności wyświetlić własne strony w interfejsie WP. A czasem bedziesz musiał - różne płatności mają różny workflow. Łatwiej jest to oprogramować podpinając się standardowo do systemu WordPressa, niż 'z d**y' :).
Generalnie wtyczki WP są pisane często w bardzo "śmieciowy" sposób - WP nie narzuca konkretnego stylu. Mozna jednak je pisać ładnie i obiektowo, a wtedy masz szansę uzyskać w miarę czytelny i łatwy do późniejszych zmian kod.
To takie przemyślenia "na szybko", nie ręczę za ich stuprocenotwą poprawność :)Tomasz Struczyński edytował(a) ten post dnia 15.09.10 o godzinie 14:05
-
Przemek Szalko:
Ograniczenie 100 wywołań jednej funkcji w PHP nie istnieje, może być wprowadzone w rozszerzeniach do PHP, np. instalując xdebug automatycznie dodaje takie ograniczenie. W xdebug jest to oczywiście konfigurowalne.Przemek Szalko edytował(a) ten post dnia 05.09.10 o godzinie 11:43
@Tomasz Jędrzejewski, mógłbyś się, o ile to możliwe, odnieść jakoś do tego?
BTW, ciekawa dyskusja (pomijając wycieczki osobiste). Wcześniej nie słyszałem raczej o OPT, może czs się zainteresować?...
-
Mam wrażenie, że w dużym stopniu nie chodziło Ci o framework, a o IDE.
Jeśli chodzi o IDE, to do dużych projektów i Eclipse i NetBeans są jednakowo dobre (albo jednakowo złe, jak kto woli). I oba dadzą się skonfigurować do pracy z PHP. Czyli bedziesz miał podpowiadanie składni, kolorowanie i całą resztę.
Jest kilka innych IDE do PHPa i tak naprawdę użyć możesz wszystkiego. Pomiędzy Eclipse i notatnikiem jest dużo wolnego miejsca, trafiają tam i Notepad++ (świetny do "szybkich" edycji kodu, podpinam go jako zamiennik notatnika; koloruje składnię) i JEdit (dawno nie korzystałem, kiedyś był bardzo dobrym darmowym edytorem tekstu z mnóstwem wtyczek) i wiele innych. Poza NetBeans i Eclipse są również płatne środowiska: IntelliJ Idea, Zend... Ale i eclipse i NetBeans wystarczają do sporych projektów więc wybierz które chcesz. Osobiście pracuję głównie w Eclipse, ale jeśli chodzi o frameworki to NetBeans ma faktycznie wsparcie dla Symfony więc...
Jesli chodzi o Frameworki natomiast zdecydowanie polecam Symfony. Co do szybkości działania - nie jest oczywiście demonem, ale ma bardzo rozbudowane mechanizmy cache'owania więc w produkcyjnych zastosowaniach jest jak najbardziej wystarczająca. Zaufały jej bardzo duże firmy: Yahoo (Yahoo Bookmarks), Dailymotion... więc wydajność chyba nie jest najgorsza.
Symfony ma bardzo rozbudowaną dokumentację i zestaw tutoriali. Naprawdę znaleźć można odpowiedzi na większość problemów. Istnieje również forum i wiki. Ważne jest również wsparcie techniczne, bardzo jasno określone (widać że kierują się do klientów biznesowych). Obecna wersja "długofalowa" będzie wspierana przez najbliższe trzy lata, poza tym wydawane są nowe wersje z rocznym wsparciem (pewnie za 3 lata bedzie kolejna wersja z długim wsparciem).
Ma też wiele rzeczy "wbudowane", a raczej dostarczone. Klasa obsługi maili (SwiftMailer), obsługa formularzy, ORM (Doctrine) i wiele innych. Oczywiście, jeśli potrzeba, podmiana lub dodanie własnych nie stanowi problemu.
Pewnym minusem jest fakt, że jako framework jest dość skomplikowane w pierwszym kontakcie. Jest bardzo usystematyzowane co do miejsc w których powinny się znaleźć różne rzeczy. Natomiast dla mnie, i po pewnym czasie użytkowania, jest to duża zaleta - po prostu wiadomo gdzie czego szukać, nawet przy cudzych projektach. Poza tym, jeśli się "przerobi" tutorial z ich strony, nie powinno być większych problemów.
Co do ZENDa, dla mnie to ciągle bardziej zbiór klas niż Framework z prawdziwego zdarzenia - choć to moja prywatna opinia. Niewątpliwie łatwy do nauczenia, ale nie ułatwia aż tak wiele. BTW, do Symfony da się "podpiąć" klasy ZENDa, jeśli będą potrzebne (jest w nim sporo użytecznych fragmentów kodu).
UPDATE: Oczywiście jest pod PHP5. I kolejny plus - w wersjach wyraźnie piszą o minimalnej wymaganej wersji PHP. W chwili obecnej jest to 5.2.4. Pod nią framework będzie działał na 100%.
Kolejna ważna sprawa, udostępnione są również narzędzia wspomagające migrację do kolejnych wersji i tutoriale do takich migracji. Przy niewielkich projektach migracja jest naprawdę łatwa, zajmuje nawet kilka-kilkanaście minut (oczywiście wszystko zależy od napisanego kodu).Tomasz Struczyński edytował(a) ten post dnia 23.03.10 o godzinie 11:12
-
Piotrek Rybałtowski:
Tomasz Struczyński:
Co więcej - niedługo doczeka się być może IDE (NetBeans od wersji 6.8 ma mieć natywne wsparcie) - coś, czego tak naprawdę nie ma żaden framework PHP.
Tomku, jedna uwaga - http://www.zend.com/en/products/studio/features :)
Kiedyś próbowałem nawet z tego korzystać, ale się srogo zawiodłem. Cóż, to było dawno, może się poprawili :)
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Opinie i oceny stron www/grafik
-
@Rafał - A tu masz rację.
Jeszcze a propos frameworków - wspomniałem w poprzednim poście, ale powtórzę oddzielnie i uzasadnię. Jeśli szukasz ciekawego frameworka i masz trochę czasu, polecam Symfony (http://www.symfony-project.org).
Dlaczego? Po pierwsze jest jednym z niewielu naprawdę obiektowych frameworków. Realizuje w pełni wspomniany wcześniej schemat MVC - a jest to schemat zalecany dla serwisów internetowych. I jest BARDZO bogaty w dodatki.
Coś za coś. Może być nieco za trudny dla początkującego. Narzuca dość sztywne ramy projektowania aplikacji - choć to dla mnie akurat plus. Wymaga czasu, aby się go nauczyć.
W teorii jest też dość ciężki - ale na szczęście praktyka może być inna. Da sie zaimplementować naprawdę zaawansowane mechanizmy cache'owania, dzięki którym działa naprawdę szybko.
Czemu jest trudny dla początkującego? Po pierwsze, z powodów wymienionych powyżej. To nie jest prosty PHP, gdze napiszesz jakiś plik, wrzucisz go do jakiegoś katalogu i odpali ci stronkę. Struktura katalogów i plików w nich jest dość ściśle ustalona. Co więcej - praktycznie nie piszesz plików bezpośrednio dostępnych z sieci! Większość jest wczytywana przez nawet nie jeden, ale całą serię kontrolerów.
Po drugie, aby sprawnie się w nim poruszać trzeba opanować kilka schematów architektonicznych. Wspomniane wcześniej MVC to jedno, poza tym ORM, czyli dostęp do bazy za pomocą obiektów (prawie w ogóle nie pisze się 'czystego' SQLa, kwerendy są obiektami itd).
Z drugiej strony Symfony ma naprawdę dobrą dokumentację, której opanowanie przy okazji podszkoli ogólnie w programowaniu i dobrych praktykach.
Generalnie, bardzo mocno polecam. Nadaje się do projektów różnych rozmiarów - używa go np Yahoo Bookmarks (http://digg.com/software/Yahoo_Bookmarks_uses_Symfony_.... Co więcej - niedługo doczeka się być może IDE (NetBeans od wersji 6.8 ma mieć natywne wsparcie) - coś, czego tak naprawdę nie ma żaden framework PHP.
-
Rafał Nowak:
Tomasz Struczyński:
Long story short jak ja to widzę - generalnie komponenty na stronach można podzielić na dwa rodzaje - jak to chyba zresztą zrobiłeś. Na widgety (snippety, bloki, moduły, jak zwał tak zwał), czyli coś będącego elementem strony i na same strony, czyli to, co całość wyświetla. I, moim zdaniem, o ile tych pierwszych na stronie może być ile chcąc, to drugi powinien być jeden.
Albo podejść do tego od strony MVC. Wtedy pojedyncze strony to Widoki (u Ciebie strony), które generują dane używając Modeli (u Ciebie: widgetów). Kontroler wtedy wybiera na podstawie URLa jaki widok wyświetlić, a w widoku już wszystko sam definiujesz.
Mój schemat wcale nie negował MVC. Tyle, że u mnie i strona i widget to pełne komponenty w modelu MVC, tj i widok i model. Nigdzie nie jest powiedziane, że strona nie może być składana z wielu modeli, patrz choćby Swing (o ile nazwę pamiętam).
Główny kontroler powinien być jeden, ale np zdarzenie 'wyświetl lewy pasek' może indukować uruchomienie komponentu Menu. Albo kontroler strony może potrzebować komponentu galerii.
Ostatnio pisząc coś w Symfony (to apropos frameworków, jeden z najciekawszych wg mnie) miałem coś takiego. Strony renderowałem standardowo, używając jednego modułu. Ale prócz tego, layout wołał menu, które postanowiłem zrobić nie widokiem (tam partialem), ale z użyciem komponentu, będącego pełnym zestawem MVC. Dzięki temu mogłem go ponownie użyć w innych modułach.
-
Long story short jak ja to widzę - generalnie komponenty na stronach można podzielić na dwa rodzaje - jak to chyba zresztą zrobiłeś. Na widgety (snippety, bloki, moduły, jak zwał tak zwał), czyli coś będącego elementem strony i na same strony, czyli to, co całość wyświetla. I, moim zdaniem, o ile tych pierwszych na stronie może być ile chcąc, to drugi powinien być jeden.
Za to pojedyńcza wtyczka mogłaby dawać i funkcjonalność strony i widgetu. Np galeria, ze stroną galerii i widgetem galerii do osadzania na innych stronach, np newsów.
Jak dla mnie zawsze da się wyróżnić główną funkcję danego URLa, wyświetlenie strony, wysłanie maila itd. Nie ma więc potrzeby ładownia na podstawie URLa kilku komponentów. Za to może być tak, że komponent główny załaduje inny - np strona ma dołączoną galerię, więc ładuje blok galerii. I można to zrobić albo brutalnie, tj z komponentu wywołać funkcję ładującą, a można nie wprost, przez wspomniane przeze mnie wcześniej obserwatory.
Ładowanie strony miałoby wtedy dłuższy przebieg. Najpierw kontroler iterowałby po wszystkich wtyczkach (np dodatkowy plik konf dla każdej), a one zgłaszałyby, jakich zdarzeń słuchają. Potem ładowany byłby główny kontroler i ewentualne moduły.
To oczywiście pisane na szybko i z głowy, dużo trzeba by przemyśleć i sprecyzować. Ale ogólny schemat tak widzę.
-
-
Dorzucając swoje trzy grosze - warto przemyśleć, czy będą Ci potrzebne moduły rozszerzające inne moduły - i generalnie połączenia między modułami. Np biblioteka multimediów jako rozszerzenie modułu stron itd.
Jeśli tak - metod jest wiele, ale polecam zastosowane np w Symfony Hooki. Oczywiście, tu wiele zależy od programisty modułu bazowego (czy i gdzie dorzuci takowe), ale przy dobrze napisanym frameworku/zestawie bazowym nie jest to aż takie ważne.
Generalnie polega to na tym, że moduły mogą obserwować zdarzenia w systemie. Zdarzenia mogą być wywoływane przez aplikację albo inne moduły, są identyfikowane np przez stringi z nazwami etc.
Np w module edycji strony masz przed zapisem coś w stylu System::RaiseEvent('preInsert'). Wcześniej (podczas rejestracji modułów) inny moduł zgłosił np coś w stylu System::ListenTo('OtherModule::preInsert', callback). I teraz w miejscu raiseEvent bazowy framework włazi do tego callbacka.
-
-
Nauka nauką. Ale wnosząc po treści Twojego problemu dobrze Ci radzę:
Nie obraź się, ale jeszcze przez spory czas jak będziesz chciał napisać coś dla np Swojej firmy, lepiej zleć to fachowcom. Taka strona może być po prostu niebezpieczna dla Twojego biznesu.
A wracając do nauki:
Schemat uruchamiania strony w PHP (i KAŻDYM języku do WWW, także .NET, Perl, Ruby i wszelkim innym CGI):
1. Klient (czyli użytkownik) wysyła ze swojego domowego komputera żądanie "wyświetl stronę X" (może być fragment strony)
2. Serwer znajduje kod strony.
3. Jeśli jest to program (np PHP, Perl), jest on w TYM MOMENCIE wykonywany. Kod PHP wytwarza HTMLa
4. Tenże HTML jest wysyłany do klienta.
Strona u klienta może być dynamiczna. Ale ta dynamika nie ma nic wspólnego z PHP. To inny język programowania, najczęściej JavaScript. Wykonywany jest "wewnątrz" przeglądarki klienta. Do ewentualnej komunikacji z serwerem WWW używa schematu przedstawionego powyżej ("wyświetl fragment strony XY").
W Twoim przypadku można użyć kilku metod:
1. W ogóle nie angażować serwera w generowanie hasła. Tylko javascript i zdarzenie onclick
2. Zdarzenie onclick wywołuje zapytanie AJAXem (czyli "wyświetl fragment strony Y"), a strona Y generuje Ci hasło na serwerze. Tym hasłem wypełniasz textboxa
3. Zrezygnować z dynamiki, przycisk po prostu wysyła formularz i przeładowuje całą stronę. Zakładam, że nie o to Ci chodzi :)
Jakiejkolwiek metody użyjesz, pamiętaj o weryfikacji tego hasła jeśli chcesz go używać.
Jeszcze jedno - jeśli chcesz używać AJAXa, lepiej nie pisz tego w czystym JavaScript. Jest to możliwe, ale będzie różnie działało na różnych przeglądarkach. Lepiej wykorzystać biblioteki - ja polecam MooTools (http://mootools.net/ ), lub zestaw Prototype/Scriptaculous (http://script.aculo.us/ )
Pozdrawiam i życzę owocnej nauki.Tomasz Struczyński edytował(a) ten post dnia 15.01.09 o godzinie 10:48
-
Bartłomiej S.:
Jakub Sołowiej:
A moim zdaniem to zły pomysł. Jak już coś dodawać, to drugą tabelę, w której będą przechowywane kategorie lub grupy.
Tak mam zrobione.
No jak tak masz zrobione to podaj więcej struktury bazy. Bo nie widzę w tej tablei którą dałeś zadnego powiązania z kategoriami...
-
Po samej książce nie wyobrażam sobie napisania niczego.
Nie wiem, czemu tak podkreślasz "nie www". Jak znasz podstawy języka to chyba tylko WWW (i dokumentacja :)).
Jak się chcesz PHP nauczyć, to nie czytaj za dużo książek (tyle, żeby poznać składnię), tylko pisz. I http://php.net - dokumentacja funkcji :)
Z jednym zastrzeżeniem: powinieneś znać mniej więcej standardy programowania. Tj jeśli w czymś programowałeś, to nie ma problemu. Jak nie, a nie chcesz tworzyć potworków, to przynajmniej trochę poczytaj o OOP (Object Oriented Programming), wzorcach i reszcie śmiecia.
Tyle, że (przynajmniej z moich doświadczeń) stosowania tych rzeczy musisz się i tak nauczyć w praktyce. Że zacytuję prawa Murphy'ego "Żaden plan bitwy nie przetrwa kontaktu z wrogiem.". To samo tyczy się teorii z książek.
-->
Reasumując:
1. Jesli już w czymś programowałeś to możesz sobie poczytać podstawy składni w PHP i dokumentację na http://php.net i zabrać się za pisanie. Potem polecam - jak reszta - frameworki (np Symfony, choć jest trochę trudniejszy do nauczenia).
2. Jeśli jesteś "zielony" to czytaj książkę (przyda się), ale przede wszystkim - pisz, pisz, pisz... O przykłady kodu nie proś, bo one się z książki nie biorą tylko z głowy. Jeden po takiej książce napisze Hello World, inny - CMSa.
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Opinie i oceny stron www/grafik
-
Zacznijmy od początku. Dla mnie są trzy potencjalne wąskie gardła:
1. Dodawanie plików
2. Pobieranie plików
3. Zapytania do bazy o ww pliki
Zacznę od końca, czyli 3. Baza jest wykorzystywana i przy dodawaniu plików i przy ich pobieraniu. Ale zdecyowanie więcej ma być pobierań, niż dodawania.
Przy dobrej konstrukcji bazy, dowolny plik może byc reprezentowany przez liczbę (ID rekordu). A liczby są naprawdę dobrze indeksowane, więc zapytanie w stylu "SELECT server,path FROM locations WHERE file_id=42667" nie zajmie wiele czasu.
Przy obciążeniu bazy (nie sądzę na początku), powtórzę to, co w poprzednim poście - bazy mają wbudowane mechanizmy rozkładu obciążenia i ze swojej natury są skalowalne. Sprzętowo :P
2. Prostota - z tym się zgodzę - najważniejsza. W wersji najbardziej brutalnej kod to kilka linii: pobierz ścieżkę i serwery z bazy (patrz poprzedni punkt), pobierz z systemu obciążenie serwerów, wyślij użytkownikowi plik (lub adres pliku do redirecta) z najmniej obciążonego serwera. Mocy obliczeniowej nie potrzeba aż tak wiele. Wymagany do napisania jest mechanizmm sprawdzania obciążenia - wykorzystałbym istniejące w systemach mechanizmy (o ile wiem, Unix ma takie łatwo dostępne).
1. W bazie jest trzymana aktualna quota użytkownika Przy wysłaniu forma sprawdzane jest, czy wysyłany plik jej nie przekracza. PO udanym dodaniu pliku (move_uploaded_file i tak dalej) dodawany jest wpis do bazy i zwiększane wykorzystanie przestrzeni.
Gdzie przesunąć plik - na podstawie informacji o wolnym miejscu na dyskach (z systemu plików raczej branej).
Replikację pliku na serwerach zrobiłbym w jakimś Cronie, nie musi być od razu na wszystkich przecież, szczególnie, jesli akurat są obciążone odczytami. Po upl plik byłby dodawany do kolejki replikacji, po replikacji usuwany z niej.
Raz na jakiś czas praeprowadzana byłaby kontrola spójności bazy i kontrola 'śmieci' na dyskach. To już mogłoby działać w zależności od serwera, tez jakiś cron.
Wersja pierwotna to jeden serwer. Znaczy bez replikacji. Przy rozwoju serwisu zmieniałbym warunki replikacji i kopiowaniu plików przy uploadzie (na początku bez replikacji i kopiowanie w zależności od obciążenia; w zależności od potrzeb replikacja).
Przy zbyt dużym obciążeniu uploadu zainwestowałbym w rozwiązania na poziomie sprzętu lub systemu operacyjnego (serwer DNS kierujący na odpowiedni komputer w zależności od obciążenia, tak na przykład). Na pewno NIE robiłbym niczego po stronie klienta - flash nie flash, zdekompilować się da. Wybór serwera z poziomu formularza uploadu, choćby ukryty (w Firebugu pola ukryte wyglądają najładniej) jest furtką do "kombinowania". To musi być transparentne dla użytkownika.
Przy większym obciążeniu uploadu (tj rozdziale uploadu na kilka serwerów) całość procesu wrzuciłbym w transakcję. W najgorszym przypadku (wszystko pieprznęło, mechanizmy awaryjne też), zostaniemy wtedy ze śmieciami na dysku (usuniętymi później przez Crona).
Eto wsio, jak na razie...
Edit i PS: A przy popularności, przy której będzie trzeba rozważać load balncery, to albo będzie Cię na takie stać, albo i tak zbankrutujesz w przewidywalnej przyszłości. Łącza internetowe o dużej szybkości drogie są...Tomasz Struczyński edytował(a) ten post dnia 27.11.08 o godzinie 11:52
-
Kamil Lewandowski:
Mówiąc, że rapidshare korzysta z innych technologii niż PHP, myślałem, że to było oczywiste iż ten język na ich potrzeby okazał się raczej niewystarczający. Chomik zresztą widać korzysta z ASP. Nie widziałem jeszcze skryptów w php które wysyłałyby mi pliki np 200MB. Co prawda można ustawić max limit pliku uploadowanego i zwiększyć czas wykonywania skryptu, ale to raczej nie o to chodzi.
Na moje phpapem taki system nie pójdzie. Chybaże ma być to jakiś ograniczony serwis. W tym przypadku user wysyła plik, skrypt zlicza jego wielkość i dodaje do bazy. Przy kolejnej wysyłce sumujesz wartości rozmiarów plików i sprawdzasz czy przekroczona została maksymalna wartość.
Ale przepraszam, jaki ciąg logiczny doprowadził do konkluzji, że ktoś korzysta z jednej technologii, ponieważ inne nie dają mu potrzebnych możliwości? Chomik korzysta z ASP - akurat przypadkiem wiem, bo jest to dzieło kolegi z roku mojego współpracownika - ponieważ zaczęło się jako praca zaliczeniowa na uczelni. Co do Rapida nie mam pojęcia, dlaczego akurat CGI (i co to za CGI, bo tam może być wszystko, od C po Pythona :P). Ale nie wiem, czemu nie dałoby się tego napisać w dowolnym języku. Szczególnie, że tak na oko wydajnościowo jest to raczej problem sprzętowy, niż programowy (przy dużej ilości zapisów i odczytów najpierw zatka się połączenie internetowe, potem dyski, a na końcu procesor :))
Jesli chodzi o moje pomysły:
1. Oczywiście, że zapisywać informacje o quocie w bazie danych! Po pierwsze, bazy (wszystkie!) mają WBUDOWANE mechanizmy tworzenia klastrów i rozkładu obciążenia. Po drugie, systemy plików NIE SĄ przystosowane do dużej ilości odczytów np z tego samego pliku na raz. Po to ludzie wymyślili bazy danych i to jest głównym założeniem przy ich tworzeniu - szybkość dostępu do informacji. Jakby baza danych na plikach była dobrym pomysłem, to by inne nie powstały i nie rozwijały się w takim stopniu.
2. FTP a po kiego grzyba? Jak bedzie kilka komputerów, to w jednej serwerowni raczej, a wtedy łatwiej podpiąć ich udziały jako dyski - w jakiejś formie NFS choćby - a nie bawić się FTP. FTP miałby jakikolwiek sens, gdyby komputery stały w różnych miejscach świata, ale wtedy mówimy o skali serwisu o rzędy wielkości wyższej (zresztą przesyłanie plików pomiedzy lokacjami na świecie nie miałoby raczej sensu w ujęciu masowym).
A przy NFS - kopiowanie sprowadzałoby się do wyboru właściwej ścieżki na dysku, a resztę załatwiłyby całkiem sprawne mechanizmy systemu operacyjnego.
3. Jak już tak bazujecie na RapidShare... Z moich doświadczeń wygląda, że oni mają kilka kopii danego pliku w różnych klastrach (prawdopodobnie połączonych siecią wewnętrzną, żeby kopiowanie nie zabierało łącza internetowego). Jakoś nie wierzę, że nie trzymają danych o tym, co i jak (i gdzie) w bazie danych...
Dobra, to była krytyka :) NAstepny post będzie konstruktywny, to znaczy moje pomysły co i jak.
- 1
- 2
- 3
- 4
- 5
- Następna »
