Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Jaki sposób na zachowanie wiadomości
Forum PHP.pl > Forum > PHP
Zikerus
Witam, mam taki oto dylemat, mianowicie w bazie chce zapisywac powiadomienia, nastepnie je wyswietlac, ew. modyfikowac (akceptowac, odrzucac, itp.)

Zastanawiam sie czy wiadomosc powinienem tworzyc z poziomu PHP (przy uzyciu kilku wartosci pobranych z bazy) czy tez zapisywac cale powiadomienie w kolumnie typu text. Oczywiście powiadomienia dla kazdego sa jednakowe, zawieraja jedynie zmienione nazwy, daty, type, lacznie do przedstawienia wiadomosci za pomoca kilku wartosci potrzebuje 4 kolumn typu varchar, ktore w duzej mierze zawieraja wartosci liczbowe (zalezy od typu powiadomienia), dla niektorych rodzajow powiadomien niektore kolumny przyjmuja wartosc NULL.

Z gory dziekuje za odpowiedzi, bylbym rowniez wdzieczny za wyjasnienie dlaczego polecacie dane rozwiazanie.
tehaha
to zależy od konkretnej sytuacji, jeżeli te komunikaty są Ci potrzebne np. do historii lub statystyk, to możesz je trzymać i te nieaktualne odhaczać sobie, ale jeżeli nie potrzebujesz ich do niczego to lepiej usunąć. Ewentualnie możesz też użyć crona który np. będzie raz w miesiącu usuwał stare komunikaty
Zikerus
Hmm, chyba nie do konca zrozumiales moje pytanie. Co do wiadomosci to beda one archiwizowane po miesiacu. Jednak mi chodzi o sam sposob zapisu wiadomosci, czy powinienem je przechowywac jako tekst (kazdy komunikat/powiadomienie w kolumnie text) czy z poziomu PHP powinienem laczyc dane z kolumn w tej tabeli ze spreparowanymi juz czesciami komunikatow smile.gif
tehaha
to zależy jak potrzebujesz jeżeli będą krótkie komunikaty to zapisuje jako varchar, jeżeli długie no to text, ale jeżeli pytasz o to czy sama treść komunikatu ma być podzielona na kilka kolumn varchar bo nie mieszczą się w jednej to nie ma to sesnu
Zikerus
Coz, moze wyjasnie to na przykladzie:

komunikat mozna utworzyc gotowy przy dodawaniu go do bazy i tak bedzie

"Bla bla bla bla bla bla bla <argument 1> bla bla bl abl abla bla bla <argument 2> bla bla bla bl abla <argument 3>" i tak dalej - to zapisujemy gotowe, jako calosc, w bazie i potem wyswietlamy

komunikat mozna utworzyc przy pomocy argumentow, dodawanie do bazy:
(<argument 1>, <argument 2>, <argument3>) to z tablicy zapisujemy w odpowiednich kolumnach tabeli (argumenty to przewaznie krotkie slowa badz liczby) i nastepnie mozemy to przy uzyciu php odczytac potem:

"Blablablalbbla".$argument 1 pobrany z tabeli."bla bla blab lab lab la".$argument 2 pobrany z tabeli."blablabla" i tak dalej

Pytanie wiec brzmi: ktory sposob jest wydajniejszy. Dodam, ze powiadomienie to bedzie dodawane i modyfikowane tylko raz (w momencie gdy zostanie przeczytane zalaczona zostaje flaga, ktora o tym informuje), natomiast dodawanych powiadomien bedzie bardzo duzo i beda one przechowywane (po miesiacu archiwizowane). Reasumujac, pierwszy sposob to wiecej miejsca na zapisanie wszystkiego w bazie, mniej zapytan vs drugi sposob gdzie wielkosc bazy powinna przynajmniej byc znaczaco mniejsza, natomiast bedzie wiecej zapytan do bazy (w celu pobrania np nazw odpowiadajacych ID zawartych w argumentach).
tehaha
chyba już rozumiem, chcesz trzymać sobie szablony wyświetlanych wiadomości i teraz zastanawiasz się czy masz w bazie zapisywać całe wygenerowane wiadomości z podstawionymi argumentami czy tylko argumenty do podstawienia przy wyświetlaniu. Ja osobiście trzymam szablony komunikatów w odseparowanym pliku językowym i tylko podstawiam do niego argumenty w momencie kiedy trzeba wyświetlić komunikat i wydaje mi się, że takie rozwiązanie jest praktyczniejsze ponieważ w bazie trzymasz same argumenty z którymi w razie potrzeby da się coś jeszcze zrobić.
Zikerus
Wlasnie o to mi chodzilo. Taki byl tez moj poczatkowy zamysl, dzis naszla mnie jednak chwila zwatpienia, czy moze jednak wydajniejszze bedzie przechowywanie calej wiadomosci. Z drugiej strony kolejnym problemem byloby ewentualne pozniejsze tlumaczenie tego komunikatu, wiec wydaje mi sie, ze faktycznie jest to najtrafniejszy wybor. Dzieki
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.