[Amorya]

I have a site that I am currently rewriting in PHP and MySQL. It has it's own regestration and usernames system. I need forums for it, that can get the usernames from my own table, letting me specify what the table and field names where each item (username, password, etc) is stored. I don't object to modifying PHP code, but it needs to be simple enough to do - I'm not up to rewriting the whole registration section of something like vBulletin.

Amorya

[Simon Mundy]

Try WWW Threads - it's a PHP-driven tool and I think it has a high degree of customisation. I shouldn't think integration with your database should be too difficult

[Amorya]

OK, thanks, I'll take a look. Out of interest, how does that compare feature-wise to vBulletin or UBB?

Amorya

[torifile]

phpBB is pretty good. I haven't looked at the code all that closely, but it seems that the database reading shouldn't be difficult at all. Just changing a couple of lines probably. Let us know.

[shmerek]

Are all types of BB whether they are php or cgi resource hogs or does it just depend on the amount of traffic?

[Millennium]

Originally posted by shmerek:
<STRONG>Are all types of BB whether they are php or cgi resource hogs or does it just depend on the amount of traffic?</STRONG>

It depends on the amount of traffic. But it can also depend on other factors.

A badly written program, PHP or CGI, will be a resource hog regardless. But the other major factor is whether or not it is database-based or file-based. The reason for this is that opening and closing files takes up a fair bit of overhead; not much for one file, but it adds up if you have lots of users. Databases don't have this overhead, because the files were already read in when the database was first loaded, and they just stay open that way (the database, not you, reads the files; you then just ask the database what it found). This is a big advantage for two reasons. First, it helps the site scale better when there are a lot of users. But even better, it takes a huge chunk of the overhead out of searching. This is why vBulletin's searches, for example, are better than UBB's.

It should be noted that, last I checked, UBB does not use a database; it works using plain HTML files. This is not, in and of itself, a good or bad thing, but it does mean that UBB will not scale as well.

[shmerek]

Originally posted by Millennium:
<STRONG>
It depends on the amount of traffic. But it can also depend on other factors.

A badly written program, PHP or CGI, will be a resource hog regardless. But the other major factor is whether or not it is database-based or file-based. The reason for this is that opening and closing files takes up a fair bit of overhead; not much for one file, but it adds up if you have lots of users. Databases don't have this overhead, because the files were already read in when the database was first loaded, and they just stay open that way (the database, not you, reads the files; you then just ask the database what it found). This is a big advantage for two reasons. First, it helps the site scale better when there are a lot of users. But even better, it takes a huge chunk of the overhead out of searching. This is why vBulletin's searches, for example, are better than UBB's.

It should be noted that, last I checked, UBB does not use a database; it works using plain HTML files. This is not, in and of itself, a good or bad thing, but it does mean that UBB will not scale as well.</STRONG>

Do you think macnn should eventually move to a php based forum?

[Millennium]

Originally posted by shmerek:
<STRONG>
Do you think macnn should eventually move to a php based forum?</STRONG>

I think it's more important to move to something database-based, no matter what language, just because of the performance issues. But yeah, I guess I'd like to see us move to a PHP-based forum, just because of performance concerns (UBB can't use mod_perl for some reason, and invoking perl caries small but significant overhead).

[tinrib]

Originally posted by Millennium:
<STRONG>It should be noted that, last I checked, UBB does not use a database; it works using plain HTML files.</STRONG>

jesus. really? this site is not run off a database? well that might explain the ridiculously long search times. Google can search a gazillion web pages in less than a second...

[Michael A. Peters]

cgi-bin also is a performance hit, php as an apache module is much better.

[mugwump]

The best php message board will be from these people: IB Forums

It'll be free, have numerous options including a mySQL database, and is lightning fast.

It won't be released for another month, but it's worth the wait. These are the people that deveolped Ikonboard, the free and powerful cgi message board, but they have left Ikonboard now to create this PHP board.

[Millennium]

Originally posted by tinrib:
<STRONG>

jesus. really? this site is not run off a database? well that might explain the ridiculously long search times. Google can search a gazillion web pages in less than a second...</STRONG>

Partly.

The thing is, there are really three types of Web boards out of there; the difference is in the backend.

At the lowest end, you have the multi-file boards. These store each message (and sometimes each user) in a separate file. These tend to be easy to program and easy to archive, and they'll be just fine for small boards. They can even do much bigger boards, if you have powerful enough hardware.

A step up, you have flat-file boards. These only use one file to store multiple pieces of data. This can cut down on overhead when you have to open many small files. But a large file will not only slow the database down for all operations, it'll do this for each access. This is a major problem if you have a lot of users. So while it's good for small to midrange boards, it still won't scale to the high-end stuff, because the files will become too large.

Finally, there are the relational-database boards. I've explained already how the file-opening overhead is eliminated with these. The programming can also be somewhat simplified, because search tools will be written into the database, and they're specifically tuned to be as fast as possible. However, now the database itself will generate its own types of overhead (though not nearly as much as multi-file or flat-file), and they tend to be more difficult to set up and maintain. Plus, if your hosting provider doesn't use that type of database, you're sunk. You either have to reconfigure (or maybe even rewrite) the script, or find another host.

I'm working on a board script now that uses a hybrid approach. User data will be flat-file, and the topics and threads will also be indexed in a flat file. But the messages themselves will be split into a multi-file layout (one per thread). The idea is to use flat-file indexing to speed things up, but avoid the file-size problems by using multi-file for the actual storage. At some point I may switch to a relational database for the backend (thus getting rid of the flat-file and multi-files completely), but that's not going to be for a while yet. I need to be able to work without a database for now, and the site it's for won't be large. I wouldn't use it for something like this site, though.

[typoon]

What about phpbb? It was easy to setup and it's also free