BBCode Implementation - Storage

[Alexander Morou]

Hello,

I just had a general question about forum design.

These days space is cheap, so the question really centers around whether it makes sense to store the post in its original bbcoded form and process it each request, or to store it in dual format, bbcode and processed form.

If stored in both forms, the generation of the page is dirt cheap, iterate the posts and you're done, the question becomes whether it makes sense to do so.

Insight welcome.

 

[DeM0nFiRe]

If you have the space, go for it. If you are trying to make something for general use, I would still avoid it as there are still places that allow limited space for the SQL database (Assuming you are using SQL).

Also, there's a caveat. You should only do it if it's actually faster. There's always an overhead to make a connection to a database. Also, it depends on how you store it. In the interest of keeping the database clean and easy to understand, you would want to keep the pre-converted posts in a seperate cache database. However, this means that you have to get your data from both tables at once, because you have to have some way of making sure that the preconverted post is actually up to date (has the post been edited?). You can, of course, do that by simply checking the timestamp, but you know, you will want to run the benchmarks to see if it really is faster.

While I haven't run any benchmarks, my guess would be that it wouldn't really make a huge different either way. Unless it's like a really really long post, I don't think it would take very long to make the conversion. Essentially, you are going to have to get more information from the database to save time processing a relatively small input, and I don't think that's going to make a huge impact.

As a side note, if you really want to speed things up on the server end, you won't do BBCode processing on the server period. If you are so concerned with the time it takes to process the BBCode, explore doing it in the browser. Requiring JavaScript will limit your potential audience somewhat, but most modern browsers will have it (You might run into issue with some mobile browsers). Unless you have some proprietary BBCode system you don't want people to see, doing it this way should give you a much higher performance boost in terms of server processing time.

 

[Alexander Morou]

Well I'm probably going to go with option #3: parse the text and encode it in binary so it can be converted either direction, from parsed DOM-> BBCode or DOM->HTML.

 

[DeM0nFiRe]

lol, sounds to me like you almost don't want BBCode period. You could use something like CKEditor and restrict the tags allowed. The downside is doing something like spoilers isn't as easy. It requires you to add like a plugin to CKEditor which I haven't done. However, if all you want to do is basic styling of posts, a WYSIWYG editor would let you just write, store and display data as HTML.

 

[Alexander Morou]

No I just want a practical solution to bbcode without having to worry about the issues with direct HTML encoding.

 

[DeM0nFiRe]

Alright, well, like I said you should do some benchmarks to find out if it's actually even faster. I am pretty sure that the most time intensive aspects of doing this sort of thing is the connection with the client and the trips to hard drive/database, neither of which you are changing.

 

[Alexander Morou]

I'm willing to bet that a database management system developed over a period of time will be faster than anything I could hack together. I'm not going to reinvent something that I've been regularly impressed by, in the realm of speed on large data volumes, given that I'm almost damn certain anything I could do would pale in comparison given that the very point of index lookup tables are constructed for the sole purpose of cross referencing data elements with one another to yield logarithmic time regardless of the number of elements within the table.