Do you version your database?
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
I use something called "SQL Source Control" from Skilled Software Allows you to do the usual source control stuff to Visual Source Safe from SQL Server plus it does lots of clever stuff like keeping the data when you make table changes etc. behind the scenes...and you can add "deployment checkpoints" so you can roll out database version changes to other servers If only the MS-Access to VSS tools were one tenth as good :-( '--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
-
we here source control the sql script for schema construction... it doesn't matter about the datas inside because we are a development center, and the sensible datas are only at the client side.
And you manually create those sql scripts each time you change the database? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
I have been looking for something like this for a while too. There's redgate SQL compare, which can be used to snapshot schemas and data and can be strapped into nant. SQL server 2005 can also do database snapshots, which could be used with a bit of dicipline to version a database and keep the data in a known state for testing. Maybe something could be done with notification services to keep scripts up to date? Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven." - Penn Jillette
-
And you manually create those sql scripts each time you change the database? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
Couldn't you just get a script to run every time a check-in is done to scan the database and check if the schema has changed and if so, generate the necessary SQL and check it in. Same kind of idea as this[^].
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
-
we here source control the sql script for schema construction... it doesn't matter about the datas inside because we are a development center, and the sensible datas are only at the client side.
That's what I do. If there is a significant enough change in the model, however, I'll use treat database migration as a separate project altogether.
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
Paul Watson wrote:
Do you version your database?
No, but I wish I did. I'm in trouble about this... :doh: ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA]
-
That's what I do. If there is a significant enough change in the model, however, I'll use treat database migration as a separate project altogether.
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
I keep my scripts under source-control. It's not ideal having to generate the scripts and check the files in. I've not found a better solution though. Since my stint as a DBA, I've been toying with building an SQL management tool that integrate schema management with documentation and source-control functionality. Getting the free time to work on it, though is the problem. Michael CP Blog [^] Development Blog [^]
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
First I thought "I know I should" - but then. Yes I do! I didn't think of versioning: but the DB access dll contains a resource that is used to generate a new database (normally, setup copies a default DB template, but if this is missing, I take the one from the resource). And of course, this resource is under source control. Lucky me! So this is a one-file-DB (which makes life easier). But I guess for "real" DB engines, you could use a set of SQL scripts. Is there a tool that can analyze a Database, and create a script that recreates the DB from scratch? 'Cause that would be cool...
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
Our organization uses a huge Oracle database, with smaller Sybase databases replicated from it periodically. They are accessed by many different apps, some under heavy development, some rarely touched. We use views for limited versioning, but in truth this is used less than it probably should be. AFAIK, most apps are stuck using whatever version they were introduced at, even if both the app and the views reflected by that version have changed considerably since. Still, i think it could work... :rolleyes:
---- Scripts i've known... CPhog 0.9.9 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.1 - printer-friendly forums
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
Paul Watson wrote:
But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too?
Yes, when we release a project and branch off the code, we dump the DDL out for the DB structure and check that into source control.
Paul Watson wrote:
at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process.
Yes, I agree with this statement ... but then, I'm not releasing code "into the field" or even to QA that this point, so mucking up the data structure is something I can easily fix without concern.
Paul Watson wrote:
With code source control you don't even have to think
Yes, this is becoming more of a problem than a solution these days ... the less we developers have to "think about" a process, the better? IMHO, this can be a problem ... ok, it's a problem for me, especially as I get older, and MY memory starts to return read/write errors (ha ha). I've found that doing some of these "manual" processes, sometimes helps remind me of things I might have otherwise failed to do (e.g., I'm about to dump the DB DDL and I think ... are there any dead columns, tables, procedures that I need to rip out before I dump this puppy). I'd be fearful that having a source control solution that "just did it for me so I didn't have to think about it", would inturn become a problem when I realized I had not optimized the database as well as I should have ... But that's me ...
:..::. Douglas H. Troy ::..
Bad Astronomy |Development Blogging|Viksoe.dk's Site -- modified at 13:52 Thursday 6th April, 2006 -
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
In at least one of products, we keep SQL scripts, source and installshield scripts versioned. The SQL scripts can be used to build a database for Build X of the product, I think. I'm not involved in this product so I'm not 100% sure what can be done with the scripts that are versioned. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
I do it through continuous database integration... http://home.swiftdsl.com.au/~Piquet/blog/index.php/continuous-database-integration/[^] Peter Hancock My blog is here And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
-
I think by now most of us are using some form of source control on our code. It is relatively easy to setup and quite easy to use once you have it going. So when you branch to make version 1.0 and branch again to make version 1.1 and so on while continuing dev on the trunk you know you can always go back and get a version's code. When you break something, you can quickly roll-back. But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too? Up till now I wasn't but the other day it struck me how daft it is to version code but not version the database. Being able to get version 1.0 of my code is next to useless if I cannot get the database structure that existed along with that code. Backing your database up every evening is not the same thing. Generating a database script only everytime you make a code version isn't the same either (otherwise why not through away all code revisions between versions? Same deal with a database structure.) So if you do have some form of "source" control on your database what is it and how does it work? Asking around the most common answer seems to be "Everytime I make a change to my database I generate scripts and check those in." But, especially at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process. Even if you have a script file that does it there is a decent chance you will forget to run it after making some alterations. With code source control you don't even have to think, it picks up changes automatically and then when you are ready you commit. I'd like the same thing but for the database structure. Any solutions? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
Not sure if this is the answer you're looking for, but when we make changes to our database, we store them as .SQL files and put them into version control. Cheers, Vikram.
I don't know and you don't either. Militant Agnostic
-
Couldn't you just get a script to run every time a check-in is done to scan the database and check if the schema has changed and if so, generate the necessary SQL and check it in. Same kind of idea as this[^].
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.
That is a good idea doing it on a commit event. Any idea how to hook into subversion so that it fires off this event on commit? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
-
Paul Watson wrote:
But do you do the same for your database? Can you go back to version 1.0 of your code and get the right database structure too?
Yes, when we release a project and branch off the code, we dump the DDL out for the DB structure and check that into source control.
Paul Watson wrote:
at the begining of a project where the database is in constant flux, that is a manual, slow, inneficient process.
Yes, I agree with this statement ... but then, I'm not releasing code "into the field" or even to QA that this point, so mucking up the data structure is something I can easily fix without concern.
Paul Watson wrote:
With code source control you don't even have to think
Yes, this is becoming more of a problem than a solution these days ... the less we developers have to "think about" a process, the better? IMHO, this can be a problem ... ok, it's a problem for me, especially as I get older, and MY memory starts to return read/write errors (ha ha). I've found that doing some of these "manual" processes, sometimes helps remind me of things I might have otherwise failed to do (e.g., I'm about to dump the DB DDL and I think ... are there any dead columns, tables, procedures that I need to rip out before I dump this puppy). I'd be fearful that having a source control solution that "just did it for me so I didn't have to think about it", would inturn become a problem when I realized I had not optimized the database as well as I should have ... But that's me ...
:..::. Douglas H. Troy ::..
Bad Astronomy |Development Blogging|Viksoe.dk's Site -- modified at 13:52 Thursday 6th April, 2006Douglas Troy wrote:
I've found that doing some of these "manual" processes, sometimes helps remind me of things I might have otherwise failed to do
Well a commit is a manual process and there is as much chance your code isn't optimised, contains dead code etc. as your database. So before a commit you should be thinking about your source and your db. regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
-
That is a good idea doing it on a commit event. Any idea how to hook into subversion so that it fires off this event on commit? regards, Paul Watson Ireland Feed Henry!
eh, stop bugging me about it, give it a couple of days, see what happens.
Paul Watson wrote:
Any idea how to hook into subversion so that it fires off this event on commit?
Wouldn't know, I'm a Perforce man myself :-) The keyword you're looking for is "trigger" e.g. this[^].
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2 [^]: A free RSS/Atom feed reader with support for Code Project.