Comments on: The Problem With Database Diffs http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html Database Change Management: The Blog Tue, 07 Feb 2012 08:04:56 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Fabio Pisaruk http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html/comment-page-1#comment-1407 Fabio Pisaruk Mon, 27 Jun 2011 16:48:56 +0000 http://nvoxland.wordpress.com/2007/06/20/the-problem-with-database-diffs/#comment-1407 I agree with you but there are some scenarios where doing a diff would be the only practical way to get the changed information. Let's suppose we were given a system, without its source code, that could be customized using a user interface and the customization information resides in some tables. After some customization done by the user interface we could perform a database diff and see what was changed so that we would be able to apply this change to another database without making use of the interface. Thanks. I agree with you but there are some scenarios where doing a diff would be the only practical way to get the changed information.
Let’s suppose we were given a system, without its source code, that could be customized using a user interface and the customization information resides in some tables. After some customization done by the user interface we could perform a database diff and see what was changed so that we would be able to apply this change to another database without making use of the interface.

Thanks.

]]> By: Boy http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html/comment-page-1#comment-1324 Boy Wed, 01 Dec 2010 13:52:52 +0000 http://nvoxland.wordpress.com/2007/06/20/the-problem-with-database-diffs/#comment-1324 TL;DR: 1. Structural diffing can't detect a rename (would be added as drop and add, potentially losing data for that column / table). 2. Data diffing is impractical due to performance and test data. Makes sense. TL;DR:
1. Structural diffing can’t detect a rename (would be added as drop and add, potentially losing data for that column / table).
2. Data diffing is impractical due to performance and test data.

Makes sense.

]]> By: Jeremy http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html/comment-page-1#comment-1291 Jeremy Mon, 21 Jun 2010 00:08:11 +0000 http://nvoxland.wordpress.com/2007/06/20/the-problem-with-database-diffs/#comment-1291 "but you will loose your valuable data" You'll set it loose into the world? “but you will loose your valuable data”
You’ll set it loose into the world?

]]> By: Nathan Voxland http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html/comment-page-1#comment-1142 Nathan Voxland Thu, 04 Jun 2009 17:50:20 +0000 http://nvoxland.wordpress.com/2007/06/20/the-problem-with-database-diffs/#comment-1142 You are right. Thanks for pointing that out, I fixed the post. You are right. Thanks for pointing that out, I fixed the post.

]]> By: Jeston http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html/comment-page-1#comment-1141 Jeston Thu, 04 Jun 2009 17:09:43 +0000 http://nvoxland.wordpress.com/2007/06/20/the-problem-with-database-diffs/#comment-1141 Did you intend that the last statement instead should have been: "... it should NOT be relied upon as your primary means of tracking database changes." ? Or did I understand something incorrectly? Did you intend that the last statement instead should have been: “… it should NOT be relied upon as your primary means of tracking database changes.” ?
Or did I understand something incorrectly?

]]>