Conversations

I've just had a quick check. I have 15 pages full. Most of those are 'imported PMs', probably from previous migrations of software. I've never really thought about it before.

 

Me neither. I'm going to go through an "leave" conversations in the hope that will help the system reclaim some space. "Every little helps"

 

sadly they remain in system currently as do all deleted posts, they simply move to a "non indexed" part of the database so don't slow down queries

 

Its often faster that way. A real delete is quite a heavy operation in database terms. The general consensus these days is that disk space is cheap, but performance is more expensive, so you tune for performance rather than space.

Its quite common to have an offline batch process to cull all the old stuff from the database overnight when its quiet, and the resulting performance hit is not likely to affect anyone.

 

I suspect the XenForo will have to address that at some point. Probably they will provide a DELETE option for the Participants at that time, but Leaving a conversation (now) is going to save having to sort that out later I would guess.

Might be worth raising a Wish List item with them Richard (or voting on an existing one - I suspect other's will already have asked )

 

Hmmm ... I'm not really a subscriber to that view

DELETE in this case is probably just the LINK between Person and Conversation. Then when the Conversation no longer has any Participants the Conversation would need to be deleted too; and that is probably a Header record and a bunch of Child message records (maybe LOTs of them!)

Deleting a solitary record (the LINK for example) is going to leave a hole in the index (and where the data record was - but reuse of that is down to the core database itself, and whatever its garbage collection stuff does).

But adding records is going to add to the Index, and cause page splits as a consequence.

So either way some housekeeping rebuilding / re-optimising of the indexes is going to be needed I reckon?

So deleting as-you-go is going to fragment the index, but it will need some optimisation housekeeping on a regular basis anyway because of Inserts, I think.

OTOH deleting them later means that the programming logic is split into two places, and more to go wrong IME (particularly during software maintenance when someone changing one part doesn't realise that there is an associated & related process that needs tinkering with as well)

Forum software runs 24/7, and although we may consider that most users are UK based, and thus "traffic" is light at 3am, I expect that there are other users where 24/7 means that there is no obvious maintenance window. Little & Often would be kinder in that scenario.

Thus I tend to favour delete meaning "now" ...

Also, forum owners are paying for their disk space ... so it would a "kindness" to purge stale data (hence I'm somewhat surprised that Conversations are stored indefinitely, but XenForo is new so it may just be they haven't got to that as yet). Of course a background task which ran "daily" would keep the disk space under control, it doesn't have to be "now" to fulfil that objective.

Sorry ... mouth wandering again ...

 

That's why we build a Data Access Layer. Any higher level program says 'delete whatever', and the DAL takes care of the detail. One DAL, many programs, still only one place to change what happens in the DB

 

The DAL has the "Just Flag it as deleted for now" and "schedule the actual delete, including cascading child record deletes" all in one place [from a program maintenance perspective, so to speak]?

(Not something I've come across, so would be interested if the solution is along those lines).

Increased abstraction brings a need to throw horsepower at the problem IME. I may just be old fashioned, but the upshot of that seems to me to be that a plateau, which cannot be surpassed without major reworking, can become an "unanticipated" future problem, whereas engineering out the abstraction can provide much more output for the same power, and thus much more scalability before running out of road (and less sudden degradation as the limit is approached)

Huge sweeping generalisations though, and horses-for-courses definitely applies!

Tendency these days seems to be to build using heavily abstracted building blocks. Fast, and cheap, to build. Proper understanding of what is going on under the hood is often lacking, or completely missing, and thus very expensive-to-diagnose problems arise - unexpectedly.

We favour writing our own code-generating routines that will build the applications the way we would have written them manually, in earlier times. Code generation means that our productivity is high, and solutions are robust because there is minimal human-written code, and as a consequence unexpected outcomes are rare. Of course another consequence is that we can only produce solutions in a narrow sphere - which is fine, we are very effective within that marketplace - half the cost, twice the robustness [reword as you think fit for a marketing campaign!!]

 

have i started something

 

What makes you thing that