The Smoking Gun of Bart's "Smoking Gun" Footage

[PhantomWolf]

Well if you ever feel a desire to learn the basics.....

[JayUtah]

Wow, another person who knows SQL!

I have a degree in computer science. SQL proficiency is a requirement for that credential.

In my experience a SELECT query is never run that counts posts like that as it would be too intensive on the database/processor as every page load would require multiple queries just to bring back a post count.

I agree. That said, the question is between efficiency and correctness. Here the post count appears intended only for display. It doesn't matter if it's slightly wrong, but it does matter if it takes forever to compute because it's invoked for each post every time a page is generated for display.

Abstractly it violates the SPOT design principle: Single Point Of Truth, in which there is exactly one source for any important bit of information. A cardinal number column in the user table is guaranteed to reflect the actual number of posts in the post table only if the system has been, and continues to be, programmed correctly. You have two sources for the number of posts: the counter and the actual number of rows in the post table that match the attribution predicate. Should those disagree, additional effort must be undertaken to determine whether the post-count column is wrong (e.g., due to a programming error) or whether the post table is at fault (e.g., posts failed to insert). That makes understanding the system more difficult and diagnosis of problems more protracted.

However the post count for display is not an important bit of information, so long as no computation in the system requires its value to be correct. If the value is simply extracted for display, then it can have only limited consequences. Therefore it makes sense here to program it as a column in the table.

In other cases such an optimization, improperly maintained, can have drastic consequences. In many production databases an accurate count of records fitting some criteria is a matter of operational correctness, and sometimes compliance with law. One cannot report inaccurate information without consequences. Hence those systems are programmed to count rather than to cache intermediate results that require coordinated correct programming for their accuracy. Thus data-driven, any error is attributed to errors in the data and not errors in the program.

[Joe Durnavich]

If the Posts value means "number of posts made" and not "number of posts on file," then it is correct.

[JayUtah]

Now, Joe -- you're redefining the specifications to match the code.

You're hired.

[Joe Durnavich]

You learn this when your support department is within tomahawk-throwing range of the programming department.

[JayUtah]

...or when negotiating contract acceptance criteria with indecisive customers. People who waffle at the negotiation stage should suddenly find themselves with that burden of proof at delivery.

[Trinitrotoluene]

joedurnavich said:

If the Posts value means "number of posts made" and not "number of posts on file," then it is correct.

I like your thinking!

[Jason]

Too bad it doesn't count "number of times a post has been edited." I find myself correcting spelling mistakes after the fact all the time.

[LunarOrbit]

gavsto2006 said:

If you have access to the full SQL database (I assume this forum is running on an SQL backend) then I may be able to write a convert script to another forums software. If you don't then I'm afraid you are up the creek without a paddle!

This forum software is so ancient that it stores the data in a flat file instead of a SQL database, and since I don't have access to the flat files or the server there is no easy way to transfer the information. It is probably possible to write a script that reads each page and transfers the important information to a database but it's beyond my programming abilities (and possibly not something my web host would allow - certain PHP commands have been disabled for security reasons).

I have considered starting a new forum and then linking to this one for archival purposes, but I'm not sure if it's worth the hassle. I do regret choosing Proboards though.

[reynoldbot]

I don't imagine you had a choice considering you essentially took the helm of this forum after it had died and the original owner abandoned it, right?

[LunarOrbit]

The original forum used more advanced software called phpbb, but it required a web hosting service with a MySQL database. When the previous owner accidentally let the apollohoax.com domain expire the old forum and it's web hosting was lost and I had to find a new (and preferably free) forum provider as soon as possible... and this is what I chose. There weren't as many choices then as there are now though.

[Ginnie]

My two cents...
After viewing many forums on the web, I find this one the easiest one to navigate, and perhaps the biggest compliment I can give is that is easier on the eyes than any other one I've seen.
I don't know if the layout and colours are specified by the board or by you, but the combination of greys, black and even the highlight orange are very pleasant to look at. Even the ads are not that intrusive, they sort of blend in quite nicely considering what they are.
Simple, elegant and smooth. That's what I see.

Good job.

[LunarOrbit]

Thanks Ginnie. I modified the colour scheme to match the old forum the best I could. There are a few problems though, like having black text over black backgrounds in some places, but I couldn't figure out how to correct that. Most of the complaints I have with the software are things that only moderators would be aware of, so I'm sure the antique software doesn't bother other people as much as it bothers me.

[Trinitrotoluene]

admin said:

gavsto2006 said:

If you have access to the full SQL database (I assume this forum is running on an SQL backend) then I may be able to write a convert script to another forums software. If you don't then I'm afraid you are up the creek without a paddle!

This forum software is so ancient that it stores the data in a flat file instead of a SQL database, and since I don't have access to the flat files or the server there is no easy way to transfer the information. It is probably possible to write a script that reads each page and transfers the important information to a database but it's beyond my programming abilities (and possibly not something my web host would allow - certain PHP commands have been disabled for security reasons).

I have considered starting a new forum and then linking to this one for archival purposes, but I'm not sure if it's worth the hassle. I do regret choosing Proboards though.

A flat file? Ouch!

[Joe Durnavich]

Although, depending on the circumstances, flat files (or indexed files) can be an advantage. If there is little need for general-purpose queries but a great need for efficiency, flat files can be the superior alternative. I believe Proboards runs a very large number of forums on its servers. Perhaps a SQL database would consume too many CPU cycles.