Phoenix Kiula wrote:
> My post at the bottom.
>
...
>
> No. You have no idea what the design is for. Not forum crap.
>
> What happens when you need to store in a table the activity log?
>
> ACTIVITY_ID
> USER_STAMP (currently user_id or ip for registered and unregistered resp.)
And here it gets wrong. Obviously you would store the session id
or if you have a lot of relations, use a sequence generated
key for session_id (compare with my design in the other post,
in this case session_id would be serial and you'd have a field
session_key text with the index for the cookies in the sessions
table instead)
> The idea of storing IP for users is already being done. So what?
Abandon this idea I'd say. Its based on the wrong asumption IP
addresses map to users in 1:1 relation.
> Everytime they "do" something, you do not store their IP. Why would
> you? Just store their user id. For unregistered ones however, we store
> the IP because there is nothing else. There is no user ID for them.
> What's your logic for getting a user ID for unregistered guys --
> invent one automagically?
>
> Finally, this SQL:
>
>
> WHERE COALESCE(user_id, to_char(access_ip)) = matchstring;
>
>
> Ever tried this crap on a table of 10 million records on a live
> website, where this query is happening at 3000 times per second? No
You have 10 million people active the same time in your site?
> such function schtick will match the raw speed of a simpler indexed
> query. Or did you mean my index should contain the COALESCE already?
>
> Tino, I wasn't talking about sessions. This is not about session IDs.
Well actually this is. You are just naming it differently.
> A session ID is useless the next time a certain IP address "does
> something" on the site. You want a commonality for non-registered
> users across many different sessions. (Apart from the fact that
> session IDs are usually long hashes which take up space in the table
> and in the index)
Yes but only active ones.
btw, given IP is in every request, where is your username coming from?
Apart from basic auth, there is no way of having a userid tied to
the request directly, so how are you doing this?
Tino
