Welcome Guest, Not a member yet? Register   Sign In
A relatively quick survey.
#1

[eluser]TheFuzzy0ne[/eluser]
Hi everyone.

As a lot of you know, I'm in the process of building a forum which I hope to release to the public. Perhaps the biggest problem I've had to date it figuring out how to make it easily extendible, and also really simple to integrate into your current setup.

The main part is figuring out how to deal with having a site that already has an existing database table for users. I was looking for some suggestions. How would you do it?

What I'd like to do is store the user's thread/post count, and I am debating whether or not to use the user_settings table to store this, or whether new fields should be added to the existing one, or whether the post/thread counts should have their own table.

Feedback and comments welcome as always.
#2

[eluser]Dam1an[/eluser]
You're creating a forum? How did I miss that? Tongue

One option would be to keep it normalized and do the count in real time, but thats not what you're asking, I I'll assume you've decided you're definatly storing the post/thread count

From the 'make it as easy for the user' point of view, I would go with a seperate table, which would have user_id (both PK and FK), thread_count and post_count.
Maing users manipulate their current tables will potentially put off a lot of users (also, as unlikely as it is, what if they already have those columns in the user table, or whatever names you choose)
#3

[eluser]TheFuzzy0ne[/eluser]
[quote author="Dam1an" date="1243290702"]You're creating a forum? How did I miss that? Tongue[/quote]

I'm terribly sorry, I must have forgotten to tell you about it.

[quote author="Dam1an" date="1243290702"]One option would be to keep it normalized and do the count in real time, but thats not what you're asking, I I'll assume you've decided you're definatly storing the post/thread count[/quote]

Indeed, I'm putting performance over normalization, just like most of the other major forums out there. PHPBB3, at least, has tools in place for resynchronising the thread/post counts manually, which I think should be more than adequate.

The post count is not something I'd consider to be critical data, and I have no doubts that PHPBB has put a lot more though into it than I have, so if it's good enough for them, it's good enough for me. Also, it means I can get the thread and post count for forums, topics, and users in a single query. I'm quite sure I'd need two or more if I counted it on each request. Plus, a COUNT query with a WHERE clause will no doubt be more resource intensive than a single call to a single row. There's no work to be done as such, just a simple search and read. Hopefully this makes sense.

As much as I'd love a 5NF database, I think in this case it's going to make things more difficult - especially when it comes to adding something like a topic, as multiple inserts are needed to different tables, which goes against the normalisation principles. I'm going to be realistic and just aim for 3NF, since it's a more realistic goal.

[quote author="Dam1an" date="1243290702"]From the 'make it as easy for the user' point of view, I would go with a seperate table, which would have user_id (both PK and FK), thread_count and post_count.
Maing users manipulate their current tables will potentially put off a lot of users (also, as unlikely as it is, what if they already have those columns in the user table, or whatever names you choose)[/quote]

I agree. Perhaps it should have it's own user table, which will essentially replicate the necessary data from the original users table? I'm just thinking that it's one less join. This could also allow users in the existing table to sign up for a forum account with a different name to their username. I'm unsure why this would be necessary, but I've been on quite a few Web sites where I've had to pick a nickname for the forum that's not the same as my username.

The forum will most likely grab the users information from the forum by the user ID that's stored in the cookie, but that would mean the cookie has to be encrypted.
#4

[eluser]Dam1an[/eluser]
What you could do, is use the existing users table for authentication, and then use your own table which has
user_id
alias
post_count
thread_count

That way you no longer need to do the join, and they can have a differant username on the forum if they want (very useful if the site does authentication by email... as you don't want your email on show)
#5

[eluser]TheFuzzy0ne[/eluser]
The trouble then, is how does one integrate the forum on an existing site. It should be quite simple, but how to you get all of your existing users to pick a new username? Should that be left in the hands of the developer who's integrating the site, or is there something I can do to ease the process?
#6

[eluser]Dam1an[/eluser]
What you could do is:
User signs in to the forum using whatever credentials they use for the main site (or if they're already logged in, you get the user_id from the session)
Do a lookup for that user_id in forum_users, if there's no result, they're a first time, so let them choose a differant username (default to their current one) and create the row
Carry on as normal...
#7

[eluser]TheFuzzy0ne[/eluser]
Isn't that being a bit presumptuous, though, as cookie encryption may not be enabled, thus it's easy to imitate another user by modifying the cookie. That might indeed be the only option, but I just need to be sure that there's not a more elegant way to do it.
#8

[eluser]Dam1an[/eluser]
But if its a high security site, they're encrypt the cookie and match it against the database Tongue
You could always make them login again to confirm its them

face it, whatever approach you take, there will be problems
#9

[eluser]TheFuzzy0ne[/eluser]
I think you may be right. I think I need to select several common approaches, and combine them all. I'm going to have to give this some more thought tonight.
#10

[eluser]garymardell[/eluser]
I vote an api system that can retrieve the user status on the site, ie logged in and also set it for the site by a post call. All the methods should be signed with a secret (like a password) and using an api key (like a username). I had suggested this in another thread and think that having one with other functions like creating a user on the forum, then the ability to limit registration on the forum to the site etc. But the main part would be the user login/profile api.




Theme © iAndrew 2016 - Forum software by © MyBB