David and Roman - thankyou *both* for your very helpful suggestions. I don't disagree on sql David - particularly if you are working at the analysis/design level. I *have* done sql work but most of it was 30 years ago when it was just starting to compete with codasyl databases.
I like Roman's suggestion very much because it forces me to grapple with precisely the area you describe David - the relationship between the code and the data in drupal. I'm aiming to do some serious work with drupal particularly in accessibility (I've worked the last ten years in international accessibility technology standards - I edit a couple of them so I have to know my technology onions - drupal is a good vehicle to re-learn the php/sql ropes in a serious system again).
The test/dev/prod idea goes a long way yes, but in exploring code ideas, which is where I'm at/going, its incredibly useful to be able to version the whole thing - code+data - so as to be able to revert to some particular version reliably. So that's my next step - to explore precisely what *is* static and what isn't so I can drag out for some instance of the database some serialised form that is non-variant for that instance and can enable the database to be re-constructed. You have both helped me along that path, thankyou.
If it was easy it wouldn't be fun.
Roman - external configuration changing isn't an issue as I need to version those files too. Hmmmm - could be tricky with some of this in the db tho. - we'll see. I've read the link you posted Roman and the patch and this is the kind of thing I was thinking towards. Again, thankyou to you both, I'll probably come back to you when I got a little further on the code-versus data thing in terms of what's where in the tables.
andy
This is the best strategy by far; either a positive list or list of excluded tables in a using a dump option. Since you're just ramping though, I'd wait to you got a little more experience about what's data and what's not in drupal before you get to worried beyond a backup of the site.
What we typically do is export from production back to test/dev on a periodic basis to make sure that CODE we write works against production database. Version controlling drupal configuration data is pretty heady stuff, requiring intimate knowledge of the data structures used in your site.
I beg to disagree about SQL... it's much more than an API, but a programming language. It isn't well used in drupal, but is quite powerful as a language in its own right. It's set based, so there's a learning curve to use it well. There are things that take tons of work to do in PHP that can be done easily in SQL.
That being said, SQL is easily versioned and most of that in drupal is in .module or .install files already. It's only when the configuration lines get blurred that you have to start worrying about what's code and what's data. That's no different for images and media files on the file system than it is for the data that's in the dbms.
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Roman Zimmermann Sent: Wednesday, July 13, 2011 1:29 PM To: support@drupal.org Subject: Re: [support] WAS Why .. now 3 ways to save the db which is best
It is still possible to use database dumps to do some sort of version control for the database. The "ever changing" data is located only in some tables. Most of them are caches or session tables that can be truncated without further consequences. So you can make a dump of the database that excludes the data (=rows) from certain tables. This dump will be (nearly) constant as long as the configuration doesn't change and no content is added.
"drush sql-dump --ordered-dump" together with a good list of structure-tables would do the trick - with one exception that is mentioned here: http://drupal.org/node/1132238
roman