Witam serdecznie.

Najwyższa pora abym po latach pisania bazgroł w php wziął się za solidny projekt.
A więc robię projekt dużego serwisu z nadziejami na wiele odwiedzin. Przestudiowałem wszystkie książki o PHP + SQL z miejskiej biblioteki o optymalizacji etc. jednak chcę też poznać wasze zdanie czego mam się wystrzegać i o czym pamiętać.

Projekt następujący:

1.Portal
-1.1 Serwis cz1.
-1.2 Serwis cz2.
-1.3 Forum
-1.4 Relacje live spotkań(na razie stream z osobnego serwera)

Planuję utworzyć co najmniej 4 bazy mysql:
- users (w całości poświęcona przechowywaniu danych użytkowników)
- tresci (artykuły, notki, komentarze etc.)
- forum (posty, tematy)
- backup (wszo raz w tygodniu na osobną bazę)

Oczywiście relacje zachodzą pomiędzy bazami - a tak naprawdę najwięcej pomiędzy users i pozostałymi dwiema. Czy to dobry pomysł tak to rozdzielić?
Planuję wykupić też jakiś serwer na home.pl - Business Server albo Business Server PRO - tam istnieje coś takiego jak tworzenie serwisów - kożystać z tego czy walić po prostu podkatalogi i przekierowania?
Proszę was o wszelkie rady

Pozdrawiam.

Komplikujesz sobie życie tym rozdzieleniem baz danych. Co to ma Ci niby dać?

Co do hostingu, od home.pl uciekaj, masówka nic nie warta. Szukasz dedyka, VPS czy zwykłego shareda?

Rozdzielenie baz nie ma sensu, możesz jedynie używać innych baz jeśli nie zachodzą między nimi relacje, w innym wypadku nie ma sensu. Backup najlepiej robić do plików SQL, zamiast na bazę backupową - jak MySQL Ci padnie to całe - i co wtedy? Co do serwera, w zależności od potrzeb. Stawiałbym od VPSów, ale jeśli budżet wynosi ok. 200zł brutto/miesiąc to polecam Kimsufi 16G z gamy OVH, wystarczy podstawowa wiedza nt. konfiguracji takiego serwera, a hardware jest bardzo dobry i uciągnei nawet wiele takich wymagających serwerów.

Ja polecam backup bazy danych jako replikację na inną maszynę.

Super za szybką odpowiedź!
A co do samego oskryptowania. Mam już porobione klasy wczytywania zapisu do mysql, rejestracji logowania (logowanie oparte o sesje)...

Wtrące do JavaScript - proszę upewnijcie mnie że javascript jest językiem wykonywalnym po stronie komputera odwiedzającego?

Ps. muszę mieć coś na start - na home, mogę mieć to za groszę (dosłownie), potem przenoszę się na dedyk - myślę że postawię tam nginx z kilkoma małymi shoutcastami

Backup raz na tydzień to za mało jak na duży serwis, do tego kopia na tej samej maszynie to tak naprawdę brak kopii.
Rozdzielenie danych na osobne bazy danych ma sens jedynie gdy każda baza stanowi spójną całość. To jest niewykonalne gdy będziesz miał użytkowników w jednej bazie, a posty i innej. Czyli to jest złe rozwiązanie
Jeżeli ma to być duży serwis musi mieć mechanizm w stylu "archiwizuj poprzedni rok" zrzucający starsze dane do archiwum, ale potrafiący z nich korzystać. W przeciwnym wypadku rozmiar bazy będzie się zwiększał bez końca zmniejszjąc wydajność i powodując problemy z rozmiarem backupu.

Odnośnie hostingu.....
Ja głęboko odradzę nazwa.pl

Btw. na dedyku polecam skonfigurowanie rsync i dodanie do crona własnego komputera/druiego serwera codziennej synchronizacji. Do tego jakiś skrypt do rotacji backupami i ich kwestia załatwiona.

Utwierdzam: JavaScript to język wykonywany po stronie klienta.

Czyli co masz na myśli?

Baza backup miała być na osobnym serwerze. Myślałem o niej nie w formie spakowanej, aby w razie czegoś od razu podpiąć. Home niby gwarantuje backup, jak dedyka postawie to na pewno będzie. To ma być coś +.

Home.pl to tragedia - to jest po prostu zwykła masówka, na której postawić coś poważniejszego to pomyłka. Weź sobie od razu może VPS, nawet OpenVZ Ci wystarczy. Postawić nginxa + php + php-fpm to parę minut (ale kompiluj sobie ze źródeł).


Backup bazy rób sobie np. co 6 h, ale najlepiej na inny serwer i wysyłaj scp. W razie problemów, przywrócisz w ciągu minuty.

generalnie tak, w szczególności - nie (node.js)
piszę dla porządku, może ktoś nie słyszał a będzie zainteresowany