Zikerus
31.01.2011, 19:42:25
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
31.01.2011, 20:11:44
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
31.01.2011, 20:34:07
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
tehaha
31.01.2011, 21:16:51
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
31.01.2011, 21:30:21
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
31.01.2011, 21:50:29
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
31.01.2011, 22:11:15
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.