Database Logs structuur

Hoe maak ik een efficiënte en een duidelijke database structuur voor logs.

Dus de logs worden bijgehouden als een user iets doet op een pagina, dus op welke pagina en al dat soort dingen. Hoe doen jullie dit?? Want naar mijn mening is de mijne niet heel duidelijk en efficiënt

Mijn Structuur:
id, ip, date, pagina, gelukt, wat

Vraag: Wat voor structuur gebruiken jullie?

ps: Ik heb voor het inloggen een aparte tabel.

Alvast bedankt!

Ik sla bij elke pagevieuw de GET waardes, de POST waardes, de volledige URL, de datum, het IP en de gebruiker op. Database loopt snel vol maar als je ze LIVE ophaalt enz kan je gwn je bezoekers bespieden. Ik ben stout

JA dat snap ik wel. Maar waarom zou ik alles ophalen als dit niet nodig is? Aangezien het meeste toch wel in de db komt. Bij berichten etc,

Freestyle schreef:

JA dat snap ik wel. Maar waarom zou ik alles ophalen als dit niet nodig is? Aangezien het meeste toch wel in de db komt. Bij berichten etc,

Ik bedoel laatste 20 ofzo. Is onnodig maar leuk. Zo heb ik meerdere logs die meer gedetaieerd zijn voor bepaalde dingen, maar dit is de algemene.

Ik zou doen:
id, ip, user_id, date, referrer_url, current_url

En anders als je graag wat/doen erbij wilt kunnen die er ook nog bij Maar als je ze goed opslaat en beetje indexen maakt dan kun je miljarden opslaan

Vriendje schreef:

Ik sla bij elke pagevieuw de GET waardes, de POST waardes, de volledige URL, de datum, het IP en de gebruiker op. Database loopt snel vol maar als je ze LIVE ophaalt enz kan je gwn je bezoekers bespieden. Ik ben stout

Op echt elke pagina die GET en POST waardes?

Thommiee schreef:

Eerdere citaten tonen

Vriendje schreef:

Ik sla bij elke pagevieuw de GET waardes, de POST waardes, de volledige URL, de datum, het IP en de gebruiker op. Database loopt snel vol maar als je ze LIVE ophaalt enz kan je gwn je bezoekers bespieden. Ik ben stout

Op echt elke pagina die GET en POST waardes?

GET wel, POST ook maar er zijn uotzonderingen op paginas als inloggen en registreren.

Jenner schreef:

Ik zou doen:
id, ip, user_id, date, referrer_url, current_url

En anders als je graag wat/doen erbij wilt kunnen die er ook nog bij Maar als je ze goed opslaat en beetje indexen maakt dan kun je miljarden opslaan

Zoiets bedoel ik bedankt!

Alleen Wat is de referrer_url precies?? Want niet elke actie word door gestuurd.

Freestyle schreef:

Eerdere citaten tonen

Jenner schreef:

Ik zou doen:

id, ip, user_id, date, referrer_url, current_url

En anders als je graag wat/doen erbij wilt kunnen die er ook nog bij Maar als je ze goed opslaat en beetje indexen maakt dan kun je miljarden opslaan
Zoiets bedoel ik bedankt!

Alleen Wat is de referrer_url precies?? Want niet elke actie word door gestuurd.

De URL waarvan de pagina afkomstig is.

http://php.net/manual/en/reserved.variables.server.php:

Quote:
HTTP_REFERER

The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.
------------------------------------------------------
Het adres van de pagina (indien aanwezig), die de user agent verwezen naar de huidige pagina. Dit wordt ingesteld door de user agent. Niet alle user agents zal dit, en sommige bieden de mogelijkheid om HTTP_REFERER te wijzigen als een functie. Kortom, het is niet echt te vertrouwen.

Gebruik: $_SERVER[HTTP_REFERER]

Als je $_POST in je database gooit dan heeft de beveiliging in je gebruikerstabel 0,0% effect Niet doen dus. Het maakt ook inbreuk op je privicy rechten.

Jenner schreef:

Als je $_POST in je database gooit dan heeft de beveiliging in je gebruikerstabel 0,0% effect Niet doen dus. Het maakt ook inbreuk op je privicy rechten.

Ik doe dat niet

Freestyle schreef:

Eerdere citaten tonen

Jenner schreef:

Als je $_POST in je database gooit dan heeft de beveiliging in je gebruikerstabel 0,0% effect Niet doen dus. Het maakt ook inbreuk op je privicy rechten.

Ik doe dat niet

Jij niet, maar Vriendje wel Alleen GET variabele opslaan, maar die staan al in de url

Jenner schreef:

Eerdere citaten tonen

Freestyle schreef:

Eerdere citaten tonen

Jenner schreef:

Als je $_POST in je database gooit dan heeft de beveiliging in je gebruikerstabel 0,0% effect Niet doen dus. Het maakt ook inbreuk op je privicy rechten.

Ik doe dat niet

Jij niet, maar Vriendje wel Alleen GET variabele opslaan, maar die staan al in de url

Alsof je het niet filtert..

Poraft schreef:

Eerdere citaten tonen

Jenner schreef:

Eerdere citaten tonen

Freestyle schreef:

Eerdere citaten tonen

Jenner schreef:

Als je $_POST in je database gooit dan heeft de beveiliging in je gebruikerstabel 0,0% effect Niet doen dus. Het maakt ook inbreuk op je privicy rechten.

Ik doe dat niet

Jij niet, maar Vriendje wel Alleen GET variabele opslaan, maar die staan al in de url

Alsof je het niet filtert..

Kan zomaar dat ie dat niet doet. Maar het is ook redelijk nutteloos, want je kunt er geen statistieken uithalen of andere nuttige dingen.

Ik heb ook een logging-systeem.

Deze logt alle acties in de Admin (die wordt voornamelijk gebruikt voor de het beheer).
Deze logt, de aangeroepen modules, de bijbehorende acties de CRUD actie (Create, Read, Update, Delete), het ID van het item die bewerkt wordt, de userID, IP en dae datum en tijd.

En vanavond wil ik die dump wel even posten.