Reply to thread

Message

<blockquote data-quote="Rodrigo Istalindir" data-source="post: 2815810" data-attributes="member: 2810">As with most things, it's not that simple.&nbsp; A database application has to be written to 'package' each transaction the proper way, so that if it gets replayed, all the tables it touches are restored to a consistent state.&nbsp; For example, if I make a post here, it has to add the post record in one table, update my post count in the user table, add a record to the subscribed threads table for me, etc.&nbsp; From a system standpoint, it's better to lose all the data in a transaction then to have random bits saved without knowing what or where, so the consistency functionality is crucial.It can be very trick to do properly, especially for a system that's designed to be end-user customizeable and (essentialy) non-mission-critical.&nbsp; There can also be a non-negligible performance hit if a lot of tables are involved.MySQL not only would have to support transactions (and it does), but vBulletin would have to take advantage of that, the system would need sufficient space to handle it, etc.&nbsp; As I posted in another thread, I work with clients that have full-time DBAs making good bucks to manage systems less intensive than ENworld, and they have big budgets and support personnel to do on-site backups, etc.&nbsp; The loss sucks, but given the nature of the beast, not 100% preventable.&nbsp; For a system that isn't tracking large amounts of critical data (or upon which a company's fortunes depend), you make compromises where you can.&nbsp; In any event, even if it had been fully logged, I can't imagine there would have been sufficient space on the system to replay every transaction since last December.&nbsp; The transactions are only supposed to protect you during temporary glitches, or at most between frequent and regular backups.</blockquote>

[QUOTE="Rodrigo Istalindir, post: 2815810, member: 2810"] As with most things, it's not that simple. A database application has to be written to 'package' each transaction the proper way, so that if it gets replayed, all the tables it touches are restored to a consistent state. For example, if I make a post here, it has to add the post record in one table, update my post count in the user table, add a record to the subscribed threads table for me, etc. From a system standpoint, it's better to lose all the data in a transaction then to have random bits saved without knowing what or where, so the consistency functionality is crucial. It can be very trick to do properly, especially for a system that's designed to be end-user customizeable and (essentialy) non-mission-critical. There can also be a non-negligible performance hit if a lot of tables are involved. MySQL not only would have to support transactions (and it does), but vBulletin would have to take advantage of that, the system would need sufficient space to handle it, etc. As I posted in another thread, I work with clients that have full-time DBAs making good bucks to manage systems less intensive than ENworld, and they have big budgets and support personnel to do on-site backups, etc. The loss sucks, but given the nature of the beast, not 100% preventable. For a system that isn't tracking large amounts of critical data (or upon which a company's fortunes depend), you make compromises where you can. In any event, even if it had been fully logged, I can't imagine there would have been sufficient space on the system to replay every transaction since last December. The transactions are only supposed to protect you during temporary glitches, or at most between frequent and regular backups. [/QUOTE]

Verification