[support] WAS Why .. now 3 ways to save the db which is best

[Andy Heath]

On 13/07/2011 19:25, Metzler, David wrote:
> Um... you do understand that this is data, right? It can't be thought of
> like source code.  You will never get exactly the same data twice, even
> if you haven't edited a single thing on your site.

> Every DB export will be different.  There are even session variables in
> the DB, so it's not like you can use it to track changes.   What
> difference does it make which backup methodology you choose as long as
> you've tested the restore?  I assume that's what you're using it for,
> since it really doesn't make sense from the version control perspective.

This is very useful, thankyou David - no I hadn't realised this - the 
point about session variables puts it all in perspective for me.

So if I *did* want to use it from a version control perspective I'd need 
to be able to extract the content in some non-permeable form (i.e. so 
the same content had always the same representation - as it does with 
files in a file system for example) - in fact that gives me an idea - 
with a bit of nifty footwork (e.g. knocking out mysqld for a short 
period) it should be possible to do something here directly with the 
database files in the filesystem. I did do this with a running database 
once (tarred it up and shifted it across machines) and it worked fine. 
:-).  Never did like sql - its only an API after all, it all ends up on 
some filesystem or other.  Hmmmm - wonder if it uses any of the 
timestamp info on the files. Hmmm2 - wonder what the variability across 
the files is. It doesn't make sense to me to put an exported database in 
a version control system because of this point that no two exports will 
be the same even without change in the content but it might make sense 
to put the raw files beneath it in one (with careful control of the 
processes that use the files).

andy