Best practice for database version

I was always curious about how other people implement the database versioning in their software development process. Today I tumbled across the following article about best practice in database versioning.

The way I am doing it is quite strange forward and involves 2 steps.

1. Create base-line database.
2. Create and maintain a single change script file which will be checked  into source control.
   

Apparently it works well for us. The difference between the method mentioned in the article and my approach are (A) whether we create multiple files to maintain the changes in the source control (B)whether to create a separated table to maintain the current schema version. Everything else works the same way, including branching and merging.

Point A has no semantic difference.

For point B, it is not necessary because when you apply the script which has a version number in the source control (I am using SubVersion which will generate a unique repository-wide incremental number each time you make change(s) to the source repository and our build number is tied to this number), and therefore you know what is the database schema version after the script applies. If customer reports a problem with build 213, I know exactly what the database schema should be and all the source code that associated with this build.