Witam, mam następujący problem:
chcę zbudować własny mechanizm sesji. Głównym założeniem jest bezpieczeństwo aplikacji WWW. Zamierzam sprawdzać, czy przypadkiem 2 osoby jednocześnie nie są zalogowane na serwerze . Jednak, to nie jest problem, jak na razie . Teraz mam problem z zaplanowaniem klasy, tj. zastanawiam się, czy lepiej jest stworzyć klasę obsługującą tylko mój CMS (sesje obejmowały by tylko potrzebne dane CMS'a), czy też zbudować "uniwersalny" system sesji, obsługujący nieskończoną liczbę danych, które mogły by w sobie zawierać.
Na razie jestem bardziej przychylny rozwiązaniu drugiemu, myślę nawet, że w Bazie Danych wystarczyła by tylko jedna kolumna przechowywująca "sprasowane zmienne".
Schemat Bazy Danych :

Zastanawiam się także nad typem danych SQL , jakim będzie vars (sprawsowana tablica) miałem zamiar dać VARCHAR (64), jednakże może być nie wystarczające na większą ilość danych.
Może zamiast tablicy przechowywać w SQL zrobić to na cookies? Choć może komuś cookies nie obsługiwać. Zresztą to jest niebezpieczne :\

2 rozwiazanie lepsze:)

Odnosnie pol to id_sesji, data, czas_wygasniecia, sesje
pole sesja oczywiscie jakis ogromny typ bo jesli w sesji bedzie duzo danych to moze sie sypac. Tak na prawde sesja w bazie danych to zserializowana tablica.

Jeśli tablica duża to można przepuuścić przez gzcompress()" title="Zobacz w manualu PHP" target="_manual

na zmienne sesyjne radze dac pole TEXT wzglednie VARCHAR(255).

nie dalej jak wczoraj glowilem sie kilka godzin dlaczego mi pada obsluga sesji w aplikacji, po czym odkrylem ze prostu prostu dalem za male pole (VARCHAR 128) na dane sesyjne i byly obcinane w wyniku czego robil sie niezly kogel mogel (wczesniej nie przechowywalem duzo wartosci i nie wystapowal problem) dlatego ostatecznie zdecydowalem sie na TEXT.

@sopel: po analizie, spłaszczeniu kilku tblic doszedłem do tego samego wniosku

Rozniez mam text dla sesji i jakos aplikacja juz prawie rok dziala i jeszcze sie nic nie wywalilo.

moj wlasny przypadek opisany 2 posty powyzej byl typowym przykladem krotkowzrocznosci. gdy jakis czas temu powstawal moj handler obslugi sesji nie przechowywalem duzo danych sesyjnych (i nie przypuszczalem ze kiedys bede - tak to jest z rzeczami ktora maja byc uniwersalne), wiec poskąpiłem na przestrzeni w bazie. byl tez inny powod, jako typu tabeli uzylem HEAP/MEMORY (ktory nie obsluguje TEXT). wszystko dla lepszej wydajnosci, dlatego ciagle zastanawiam sie czy tabela sesyjna z zalozonym indeksem na sessionid wydaje sie byc wystaraczajaco szybka, czy tez MEMORY z VARCHAR(255) bylby znacznie lepszy.

a moze ktos powiedziec jak mniej wiecej powinien wygladac algorytm dzialania takiego systemu sesji?

@AxZx masz gotowa funkcje ktora wywoluje Ci wlasne funkcje do zapisu, odczytu, usuwania. Nastepnie umieszczasz zwykle zapytania. Nic w tym skomplikowanego nie ma.

na wortalu jest artykul jak zrobic wlasny handler sesji na bazie

stworzyłem już klasę, jednak wydaje mi się strasznie wolna, czas jaki się generuje to: 0.012-0.015 s. (zaincludowałm tylko sterownik bazy danych no i obsługę autologowania. Czy to nie za długo? :|

Zrob testy z roznymi wielkosciamy sesji i wtedy sprawdz jak sie maja czasy.

mówisz o testowaniu tylko i wyłącznie mojej klasy, czy np. porównaniu jej do session_register ?