Witam, mam pytanko,
jak będzie lepiej zapisywać logi (np. jakaś nieudana operacja usera, próba włamu itp) do pliku? (tak robiłem do tej pory) czy może lepiej będzie przerobić skrypt, utworzyć nową tabelę w bazie (jedno z pól to niestety będzie TEXT bo w VARCHAR 255 może nie wszystko się zmieścić) i do niej ładować wszystko? -Wyczytałem, że do bazy lepiej jest zapisywać logi z tym, że jak ktoś się włamie do bazy i padnie wszystko to logi też a w pliku by zostały.. Jakie jest Wasze zdanie na ten temat?

Pytanie, po co zaśmiecać bazę?
Jak pliki/logi produkują Ci się na potęgę, to chyba czas coś z tym zrobić a nie przenosić ich na kolejny poziom powstawania.
Poza tym pliki mają tą przewagę że nigdy nie padną i zawsze są dostępne.

Dzięki pozostawię zatem tak jak było
Pozdrawiam

Ja wolę mieć w bazie
P.S. VARCHAR może mieć nawet 5000

Logi w bazie przydają się, jak np. masz aplikację rozsianą po kilku serwerach, lub są na tyle specyficzne, że chcesz z nich układać różnego rodzaju raporty.

Majcon wolisz bo. ? Skoro już wyraższ swoją opinie to ją sprecyzuj.

Do zapisywania błędów itp także polecam pliki. Oczywiście odpowiednio szyfrowane nazwy plików lub zabezpieczone hasłem.
Jeśli zapisujesz w bazie logi, z ktorych później wyciągał będziesz jakieś dane lub określone rekordy/fragmenty to baza.

Tak z ciekawości po co szyfrowanie/zabezpieczanie hasłem? Przecież jeśli ktoś ma dostęp do logów to i do kodu, który to generuje, a więc i od razu może to zdekodować..

Pozostanę przy swoich logach zapisywanych do pliku. Choć nie korzystając z bazy tylko z plików będę miał duży problem z wyświetleniem ich w panelu admina (tak żeby je paginować). Jest to w ogóle możliwe, żeby wyświetlić np. 100 logów na stronę z pliku? Zna ktoś patent na paginację wartości wyświetlanych z pliku?

p.s.- co do VARCHAR(5000) przyznam się szczerze, że żyłem w świadomości, że max VARCHAR to 255. W związku z tym moje pytanie przy okazji czy stosowanie tak wielkiego VARCHAR jest optymalne?

przykładowo jeśli mam tabelę komentarzy (ograniczenie 1000 znaków jeden kom.) ale pole w tabeli typu TEXT -to VARCHAR 1000 będzie lepszym rozwiązaniem od TEXT?

1. W MySQL VARCHAR może już od jakiegoś czasu przechowywać do 65 tys. znaków.
2. Jeżeli nie wiesz czym różni się VARCHAR od TEXT i jakie są konsekwencje tych różnic, powinieneś korzystać z TEXT do składowania dłuższych tekstów.
3. Składowanie logów w bazie jest dobrym pomysłem, przy czym niekoniecznie powiedziałbym, że MySQL (czy ogólnie RDBMS-y) są najlepszym wyborem*. Szczególnie, jeżeli chcesz wykonywać na nich jakiekolwiek operacje, a chcesz.

* Jeżeli masz dostęp, Cassandra sprawdza się całkiem fajnie.

Nie zawsze osoba mająca dostęp do logów ma dostęp do kodu źródłowego. Ale powiedzmy teraz że jakimś cudem ktoś dowiedział się o ścieżce do logów. Od tąd nawet po stracie admina będzie mał dostęp. Gdy zakodujemy nazwy plików osoba nie wie jakim sposobem kodowaliśmy i sprawiłoby jej trudność znalezienie jakiegokolwiek pliku. Jakiś czas temu zdażyła mi się podobna sytuacja z mojej głupoty.

Do autora: Pewnie ze jest możliwość. Poszukaj w necie a na 100% znajdziesz. ;p
Co do pytań o bazę - nie wiem. Nie zajmuję się optymalizacją MySQL.

Ok chyba już wszystko wiem co chciałem wiedzieć na ten temat. Dzięki za odpowiedzi wszystkim

a i już wiem w tym momencie, że jednak przerobię skrypt tak, żeby nie zapisywać do plików tylko do bazy, ponieważ bez problemu będę mógł to później wyświetlać paginując itd.

Crozin.. true. Ogólnie logi to moim zdaniem idealne miejsce do zastosowania baz typu NoSQL - brak relacyjności tychże danych i możliwość choćby shardowania w celu wstępnego "skatalogowania" danych przy jednoczesnym zwiększeniu wydajności logów - to są zalety warte przemyślenia

@Ważniak: Bez żartów... Od kiedy logi trzyma się w strukturze z dostępem publicznym? Takie dane znajdują się poza rootem serwisu www... Najczęściej 1 lub 2 poziomy wyżej w hierarchii, tak więc dostęp do nich jest jedynie z poziomu ftp lub ssh Każdy kto robi inaczej jest po prostu samobójcą. Jeśli hosting nas do takiej sytuacji zmusza, a są takie w Polsce, gdzie root nie przewiduje katalogu private lub wyższego poziomu, zakładamy katalog z prawami dostępu odpowiednio zmodyfikowanymi lub darujemy sobie taki hosting. Wybacz, ale kodowanie logów mija się z celem, jeśli wiesz jak zabezpieczyć dostęp na poziomie serwerowym. Pomyśl... Co jest prostsze i wydajniejsze? Szyfrowanie i deszyfrowanie danych, które jest dość obciążającą zasoby (procesor) operacją i zważywszy na sytuacje, w przypadku włączenia trybu debug po prostu je pożre, czy prosty htaccess z 700 na katalog?

Szczeże mowiąc nigdy nie zagłębiałem się w trzymanie danych w plakach. Trzymałem je tam dośč dawno, ale przeniosłem je do MySQL bo praktycznie kazda operacja = log. Wcześniej robilem tak jak pisałem i było okej. W kazdym razie wielkie dzięki za poprawienie. Przynajmniej nikt nie wyjdzie z tego tematu w błędzie, a i ja dowiedziałem się czegoś nowego

Właśnie dlatego trzymanie danych w bazie nie jest dobrym pomysłem jeśli przewidujesz częste logowanie. Każdy insert do bazy to zazwyczaj konieczność modyfikacji indeksu. Czasem kilku indeksów. Jeśli teraz tych operacji jest wiele, dostajesz spowalniacza, ponieważ każdy ruch na stronie, to oprócz normalnych operacji w bazie MySQL także operacje logujące, które wprowadzają jakiś narzut czasowy. Pliki to opóźnienie sprowadzają do minimum, ponieważ w zasadzie idą niezależnie od bazy. W ten sposób operacje na stronie sobie, a logowanie jest od nich zupełnie niezależne i nie ma problemu by miało jakieś opóźnienie. Operacje tam w razie mega obciążenia mogą nawet się zakolejkować, bez widocznych narzutów gdziekolwiek. Bazy NoSQL z kolei możesz dodatkowo poshardować określonymi warunkami, przez co wstępnie stworzysz kolekcje danych według określonych kryteriów, a by było wesoło, możesz owe kolekcje docelowe umieścić na różnych maszynach fizycznych. Dzięki temu możesz przykładowo wydzielić sobie logi pod kątem statusów odpowiedzi serwera. Inne dla 3xx, inne dla 5xx Temat dla części osób to magia, ale wbrew pozorom jest to dość proste i przyjemne oraz pozwala zapanować nad ogromem informacji. Oczywiście to ze statusami tylko przykład zastosowania. Sam temat shardingu ( i nie tylko ) nabiera znaczenia przy loadbalancingu danych. Ale to już zupełnie inna bajka i ma związek głównie z optymalizacją dostępu do danych, co akurat nie jest sednem omawianego zagadnienia.

adamantd - Ty serio z tym stronicowaniem? pomyśl, jak działa taki mechanizm? Masz tablicę i pokazujesz od klucza X do klucza Y. Plik w formie tablicy (jedna linia) zwraca file a gotowce znajdziesz pod "php pagination array".

@!*!:
zdecydowałem się na przerobienie skryptu, i będę zapisywał logi do bazy, rzeczywiście nie będzie potrzeby stronicowania, będę wyświetlał linki do poszczególnych dni w formie listy, po kliknięciu na link np dnia dzisiejszego wyświetlą się wszystkie logi od a do z z dnia dzisiejszego. -stronicowanie przydałoby mi się w sumie chyba tylko jakbym miał ze 3000 logów dziennie a nie przewiduję nawet kilkudziesięciu na dzień

A to źle Cie zrozumiałem, myślałem że chcesz stronicowa zawartość logu, a nie plików (choć to też jest możliwe, glob, directoryIterator). Ale to jak już uważasz.

Dobrze mnie zrozumiałeś, ponieważ wcześniej miałem taki właśnie zamiar, ale jak będę zapisywał logi do bazy to z niczym nie będzie problemu, nawet gdyby mi się zachciało stronicowania -mam swoją klasę paginującą. Gdybym kiedyś chciał paginować logi z pliku to byłby jakiś koszmar

Oj tam problem... Ja logi do pliku waliłem z atrybutem "nadpisz, jeśli nie ma stwórz" i nazwą wskazującą na dany dzień ( w formacie yyyy-mm-dd.log ). Problem podziału na dni żaden, a wyświetlenie tego równie banalne. Jeśli zdecydujemy się na bazę noSQL dostajemy wydajność zazwyczaj o kilka rzędów wielkości większą niż MySQL i o możliwościach filtrowania podobnych do baz relacyjnych, czyli niedostępnych normalnie dla plików tekstowych Co prawda zawsze pozostaje grep czy awk, ale to już jednak dla części osób pewnie rzecz problematyczna. Tak czy inaczej jest możliwe korzystanie z plików tekstowych do logów i nie jest to żaden problem. Dla chcącego - nic trudnego

Chyba dopisz bo jakbyś tak nadpisywał ten plik co każdy log to nie byłoby chyba dobrze

Sorki... Mój błąd Faktycznie "dopisz, jeśli nie ma stwórz"... Za duży zapieprz przez ostatnie dni mam.

Albo jeżeli jest możliwość to zainstalować http://graylog2.org/ - leci po UDP i mamy problem z głowy