Witam , pytanie jest proste, proszę o odpowiedzi na temat jak pisać programy tzn.

Podaję przykłady:

1. Dla rozwijalnego menu lepiej pisać dane w bazie mysql czy w plikach txt?
2. Lepiej pisać każdą stronę odzielnie tzn wyslij wiadomosc --> wyslano wiadomosc czy jeden plik gdzie action="ten plik" i w tym pliku if post { zapisz do bazy}
3. lepiej pisac na każdej stronie ten sam kod php czy zrobić plik w którym raz napiszę kod i potem tylko include?
4. Dla milionowych rekordów powtarzających się lepiej zapisywać do bazy czy do txt?

Te pytania są dla doświadczonych programistów bardzo proste i oczywiste, ale zadaję je dlatego, że czasami zastanawiam się czy warto zrobić tak lub w inny sposób.

Hey ;]

1. W każdym wypadku baza jest bardziej optymalnym pomysłem.
2. Moim zdaniem zależy to od wielkości projektu, ale dobrym nawykiem jest oddzielanie mniejszych skryptów, które mogą pracować same, np. wysyłanie maila lub dodawanie komentarza. Przynajmniej ja tak uważam.
3. Kto lubi pisać 100x to samo? Najlepiej jest starać się pisać kod tak, aby można było go później ponownie użyć.
4. Milionowe rekordy.. wszyscy mówią, że bazy danych są bardziej wydajne, a więc chyba należy im wierzyć.

Nie jestem niesamowicie doświadczony, ale takie odpowiedzi wynikają z mojego programistycznego doświadczenia.

Pozdrawiam,
mmica

Nie, nie w każdym.

Przechowywanie np. cache w bazie to super pomysł...

Co do punktu 3 KISS

Punkt 4 - miliardów od razu...

Takie "luźne" pytania, to masz takie odpowiedzi.

@fifi209
Chyba DRY a nie KISS

DRY też ;p

Pisząc o KISS miałem na myśli, aby zbędnie nie komplikować sobie życia.

Link dla Twórcy tematu

Żadne dane nie powinny się powtarzać. Musisz tak zaprojektować bazę, żeby tych powtórzeń było jak najmniej.

ad1. Zależy od menu. Jeśli masz je w miarę stałe (kategorie i podkategorie modyfikujesz niezwykle rzadko), to lepiej ująć je albo od razu w kodzie widoku, albo jako plik, gdzie masz strukturę tego menu zapisaną (tablica, xml). Na pewno jest to optymalniejsze niż robić dodatkowe zapytanie do bazy. Tak więc mmica "baza zawsze lepsza" to złe podejście. Wiele razy lepiej coś pchnąć do pliku, do którego dostęp jest przecież szybszy, ewentualnie wrzucić to do cache'u.

ad2. Strony dzielisz tak, by były one odpowiedzialne za określone fragmenty/elementy. Dla nich tworzysz odpowiednie widoki i tyle. W przypadku jaki rzuciłeś można całość rozwiązać zależnie od tego co masz pokazać po wciśnięciu wyślij. Jeśli nadal formularz, ale uzupełniony i przygotowany do ewentualnych poprawek, to lepiej trzymać się nadal tego samego i jedynie od zawartości $POST uzależniać dodatkowe elementy wyświetlane. Jeśli masz przekierowanie na już istniejące strony to tam musisz ująć jak poradzić sobie z komunikatami. Ale możesz też mieć stronę dedykowana dla komunikatów. Co programista to może mieć inny pomysł na to. I dlatego programowanie to na swój sposób sztuka. Niektórzy chałturzą byle zrobić, inni to rzemieślnicy, którym powierzyłbyś pracę bo wiesz, że są solidni, a jeszcze inni to artyści, których niekoniecznie musisz rozumieć, bo mają swoją wizję i to oni najczęściej wyznaczają kierunki rozwoju

ad3. Jeśli coś się zaczyna Ci powtarzać, znaczy że nie przewidziałeś tego i powinieneś coś uprościć lub przebudować tak, by przestało się powtarzać. Jak już wspomniano -> Don't Repeat Yourself. Jak? Rozłóż stronę na "widoki pierwsze". Wydziel pewien niezmienny szablon i w niego wkładaj pomniejsze jako cegiełki. W ten sposób unikniesz powtarzania wciąż tego samego.

ad4. Wiąże się z ad3. Jeśli dane się powtarzają to znaczy, że prawdopodobnie źle zaprojektowałeś bazę. Nie tyczy tego tylko jedna sytuacja - gdy świadomie dublujesz dane by zwiększyć wydajność. Ale do tego trzeba wiedzieć kiedy takie coś powinno się stosować i mieć świadomość, że dane te wymagają synchronizacji - muszą być w obu miejscach bowiem identyczne!

Super to może i nie, ale jak najbardziej daje radę.
Przechowywanie powielonych danych nic nie kosztuje - no jedynie minimalnie więcej zachodu przy aktualizacji danych. Za to "zbyt idealna" (w kontekście normalizacji danych) baza danych w wielu przypadkach może po prostu działać zbyt wolno.

Jak wyobrażasz sobie takie cache? Pobierasz newsy, generujesz html i zapisujesz do bazy? ;p Jakieś nieporozumienie.

Tak... pobieram dane, których wygenerowanie jest kosztowne i zapisuję je sobie w odpowiadającej mi formie. Zwróć uwagę na to, że baza danych daje wielokrotnie większe możliwości operowania na takich danych. Począwszy od możliwości przechowywania znacznie większych ilości metadanych, poprzez lepszy dostęp do danych skończywszy na możliwościach robienia czegoś więcej niż "prostym" pobraniu wg klucza i czasu aktualizacji.

Swoją drogą przechowywanie niektórych danych (cache) gdzie indziej niż w bazie danych kompletnie mija się z celem.

fifi209 W przypadku o którym piszesz jest to bezsensu, ale jeśli masz stronę produktu w sklepie internetowym, gdzie możesz mieć 15 zapytać do bazy to cache całego html'a ma już sens.

15 zapytań do bazy? Z 1 produktu? imo (z małych bo nie wiele wiem) powinno się wyciągać tyle ile się da w jak najmniejszej ilości zapytań, taka strona produktu w sklepie to 1, 2 zapytania maks.



Co do tematu - chyba wszystko już napisali mądrzejsi ale co do punktu 1szego moim zdaniem jeżeli menu nie jest niesamowicie jak dynamiczne - ale dynamiczne JEST, to można napisać skrypcik, który tworzy nasze menu np. jako xml albo inaczej oddzielone jakimiś terminatorami - strona już sobie poukłada nasze "pół dynamiczne" menu szybciej niż miałaby ciągle pytać bazę o pozwolenie :/ i wskazówki. No i skrypt odpowiedzialny za tworzenie menu musi być jakoś cyklicznie odpalany. (Np. Jest sklep internetowy, który wyświetla kategorie z przynajmniej jednym dostępnym produktem. Gdy klient wykupi ten produkt, to skrypt powinien zostać wywołany i wyczyścić "pustą" kategorię).