[php] Śledzenie kroków odowiedzającego stronę. Opcje

[kukix]

Witam.

Szykuje mechanizm, kóry będzie śledził kroki odwiedzającego stronę.

Tabele myślałem, żeby zrobić taką:

[SQL] pobierz, plaintext 
CREATE TABLE IF NOT EXISTS `statystyki` (
  `session_id` varchar(255) COLLATE utf8_polish_ci NOT NULL,
  `user_id` int(11) NOT NULL,
  `user_ip` varchar(25) COLLATE utf8_polish_ci NOT NULL,
  `odwiedzono_szczegoly` varchar(255) COLLATE utf8_polish_ci NOT NULL,
  `time` datetime NOT NULL,
  `wejscie_ze_strony` varchar(255) COLLATE utf8_polish_ci NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;
[SQL] pobierz, plaintext 

Pomysł jest taki, żeby po wywołanu każdej strony dodawać wpis do tabeli i tam za każdym razem "id sesj"i, "czas wywołania", "id usera" (jeżeli się zalogował), jeżeli wykryje $_SERVER['HTTP_REFERER'] to również "wejscie_ze_strony" + odwiedzana podstrona.

Mam wątpliwości w jaki sposób dodawać nowe wpisy tak, żeby dwa jednakowe wpisy nie były obok siebie co może wystąpić po odświeżeniu strony.


Czy ktoś ma jakieś sugestie jak taki mechanizm wykonac? Jakieś pomysły?


Ten post edytował kukix 31.05.2013, 15:03:19

[Sephirus]

@kukix

Myślałem, jednak tak, żeby każde działanie zapisac w osobnym wpisie w tabeli. Czy nie będzie to wygodniejsze i wydajniejsze?

Zgadzam się z Tobą - będzie to też jest niezły pomysł. Co prawda myślałem, że potrzebujesz czegoś jedynie do aktualnego stanu - nie historycznego. Co do samej wydajności to trzeba by to było sprawdzić. Bo jeśli zrobisz to na InnoDB to biorąc pod uwagę fakt, że rekordów w wersji #1 byłoby znacznie mniej niż w wersji #2 to jak dodasz do tego indeksy to te inserty pod koniec tych 30 dni już wcale szybsze nie będą (IMG:style_emoticons/default/smile.gif) Jeszcze jednym minusem jest fakt taki:

Czy chcesz wyświetlać tą aktywność na stronie userom? Czy ma być dostępna tylko w panelu adm. - bo jeśli chcesz to pokazywać odwiedzającym - to musisz robić selecty na ciąglę insertowanej bazie, po dacie itp i z wydajnością to będzie na bakier (IMG:style_emoticons/default/tongue.gif)

Po tym co napisałeś wziąłbym obie metody i "zniszczył" normalizację bazy danych tworząc dwie tabele. Jedną do działań w trybie "rzeczywistym" na update'ach itp opartą o InnoDb (czyszczoną co jakiś czas z rekordów starszych niż powiedzmy 1h (nikt tyle na stronie nie wysiedzi) i drugą do zapisu historycznego - czyli z Twojej metody. Uzyskasz w ten sposób szybką, małą tabelkę do działań bieżących, która ma całkiem szybki zapis/edycję i super szybki odczyt o raz drugą tabelę, którą możesz użyć w panelu adm. aby prześledzić całą ścieżkę. Tabelę drugą możesz zapełniać poprzez wyzwalacz (trigger) tak by nie wysyłać dwóch zapytań do bazy (chyba to najlepsza opcja). Drugą tabelę oprzyj na MyISAM - dużo zapisów (szybsze) - rzadkie odczyty.

Wydaje mi sie, że to rozwiązuje temat i z datą i z czasem i z tym varcharem (IMG:style_emoticons/default/smile.gif)

@gitbejbe

Za mocno kombinujecie - nigdy nie róbcie takich praktyk jak tu opisałeś - w ogóle nie używajcie pola typu TEXT tam gdzie liczy się wydajność (IMG:style_emoticons/default/smile.gif)

[kukix]

@kukix

Zgadzam się z Tobą - będzie to też jest niezły pomysł. Co prawda myślałem, że potrzebujesz czegoś jedynie do aktualnego stanu - nie historycznego. Co do samej wydajności to trzeba by to było sprawdzić. Bo jeśli zrobisz to na InnoDB to biorąc pod uwagę fakt, że rekordów w wersji #1 byłoby znacznie mniej niż w wersji #2 to jak dodasz do tego indeksy to te inserty pod koniec tych 30 dni już wcale szybsze nie będą (IMG:style_emoticons/default/smile.gif) Jeszcze jednym minusem jest fakt taki:

Te ostatnie 30 dni będą w sumie cały czas wystepowały gdy skrypt będzie działal jużdłużej niż 30 dni.
Można jednak zrobić inaczej. Dodać druga identyczną tabele do któej kopiować wszystkie dane np o godzinie 24:00. Wtedy dane moze trzymac i pol roku i baza na której zapisuje skrypt nei bedzie zawalona.

Czy chcesz wyświetlać tą aktywność na stronie userom? Czy ma być dostępna tylko w panelu adm. - bo jeśli chcesz to pokazywać odwiedzającym - to musisz robić selecty na ciąglę insertowanej bazie, po dacie itp i z wydajnością to będzie na bakier (IMG:style_emoticons/default/tongue.gif)

Po tym co napisałeś wziąłbym obie metody i "zniszczył" normalizację bazy danych tworząc dwie tabele. Jedną do działań w trybie "rzeczywistym" na update'ach itp opartą o InnoDb (czyszczoną co jakiś czas z rekordów starszych niż powiedzmy 1h (nikt tyle na stronie nie wysiedzi) i drugą do zapisu historycznego - czyli z Twojej metody. Uzyskasz w ten sposób szybką, małą tabelkę do działań bieżących, która ma całkiem szybki zapis/edycję i super szybki odczyt o raz drugą tabelę, którą możesz użyć w panelu adm. aby prześledzić całą ścieżkę. Tabelę drugą możesz zapełniać poprzez wyzwalacz (trigger) tak by nie wysyłać dwóch zapytań do bazy (chyba to najlepsza opcja). Drugą tabelę oprzyj na MyISAM - dużo zapisów (szybsze) - rzadkie odczyty.

Wydaje mi sie, że to rozwiązuje temat i z datą i z czasem i z tym varcharem (IMG:style_emoticons/default/smile.gif)

@gitbejbe

Troszke za dużo kombinacji z tym update i dodatkowo insertem. Dane nie będą pokazywane odwiedzającym, tyko i wyłącznie w administracji.

Za mocno kombinujecie - nigdy nie róbcie takich praktyk jak tu opisałeś - w ogóle nie używajcie pola typu TEXT tam gdzie liczy się wydajność (IMG:style_emoticons/default/smile.gif)

To miałem też na myśli, TEXT nie mozna w takich miejscach stosowac, jednak pole VARCHAR może sięszybko skończyć.