Matt, We have operations people do that so we use SQL. I use SQL for the development database too though. It makes for more repeatable changes. That way you don't have to worry about making a mistake or forgetting part of the change.
Thanks for your reply. So you just write scripts, and then apply them to your local machine and then apply it to the production server? That makes plenty of sense, I guess that I just need to be better organized. After I make a schema change, I invariably have to map it in hibernate (perhaps redo if I have an epiphany about an enum vs a table), write the pages/actions, perhaps map a new field in upload and export jsps and then remember what the schema changes were, to begin with, when I roll them out to the production server.
Originally posted by Matt Horton: So you just write scripts, and then apply them to your local machine and then apply it to the production server?
Almost. It goes more like: 1) Write script 2) Try it 3) Edit script when things don't work 4) Repeat steps 2 & 3 as needed 5) Release script to CVS 6) All other developers run script on local database 7) Run script in test environment, later environments and then production
That makes plenty of sense, I guess that I just need to be better organized.
Having a lot of developers each with a local database really shows the need for this practice. It's not once that we need to have a record of the state of the database. It's all the time! After you spend a few times trying to figure out why "it works on my machine", the script feels very valuable.
some schema-diff tool would be really useful.
I had to compare schemas once when things got out of synch (between QA and Production.) We just exported the schema and ran diff on it. Since things were pretty similar, this worked fine. There may be a tool; I wouldn't be aware of it.