On Wed, Jan 21, 2009 at 05:18:57AM +0100, Együd Csaba wrote: > >From: David Fetter [mailto:david@xxxxxxxxxx] > >On Tue, Jan 20, 2009 at 03:03:33PM +0100, Csaba Együd wrote: > >> Hi, > >> I'd like to ask your suggestions about a reliable admin software > >> which is able to compare two dabases and generate a schema > >> synchrinizer script. > > > >There is no such thing, and there is no prospect of there ever > >being such a thing, because the database does not contain enough > >information to create this automatically. The problem exists at > >the organizational level, and needs to be solved there. > > > >> It would be nice to be able to generate data synchronization > >> script for only the selected tables, and other features. > > > >Yes, you should definitely do that and store the scripts to do it > >in your source code management system along with all the rest of > >the deploy and upgrade scripts. They can't be generated > >automatically either. > > David, > I see your points and generally can agree with, but there is a level > which can be automated - I mean a mechanic comparison. That level isn't terribly high, and in my experience, it is not a worthwhile endeavor because it does not solve the actual problem. > Of course the result sync script must be tested before applying in > production environment. These tools can/could save a lot of time. No. What saves time is getting your development and deployment processes to the point where you're not needing to figure out what's happened. Instead, you'll be doing database changes *only* with scripts, which you'll test, etc., etc., rather than trying to reverse engineer your own stuff. Reverse engineering is what you do, and then only in an emergency, to *others'* software, not *yours.* > In my opinion the result, this way or that way, would be the same: a > version migration or sync script to attach to the upgrade package. > I think the difference is that I do not have to maintain a db script > during the development to keep it up to date. I simply concentrate > on the task not the administration. I may be wrong... You're right, in that you're wrong on this. You need to take your development process in hand and then keep it so. > Up to now I've been doing it the manual way but it makes me really > non-effective. What's *really* ineffective is continuing as you've been doing. Cheers, David. -- David Fetter <david@xxxxxxxxxx> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@xxxxxxxxx Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
