I recently started at a company, and I discovered that they don't do any version control for their sprocs/schema scripts, etc. This was a bit shocking to me, since at my last company we had everything, including the database scripts, in Subversion. The DBA here tells me that have a file for every database object in Subversion would just be too painful to do.

Obviously this is not true, since my last company did it relatively painlessly (for the schema, we did have one file for creating the schema for each module, but we had a file for each sproc/view, as well as data scripts for test data). We then had NAnt scripts that would take care of building/populating the database for us.

The last company's was a product with many customers on many different versions with customizations/extensions, etc., so it was necessary. This company can get away with it just fine, since it's an internal web application. But, just because you can get away with something does not mean that it's a good idea.

I'm no DBA, though, and their DBA has been a pretty smart guy otherwise from what I've seen. So, am I crazy? Is version control for database objects not a common practice everywhere? Why would you not do it?

I cannot imagine not using version control on database objects in any situation where they are going to be developed, tested and deployed on different environments. Typically a new version of the system will include changes to database objects and code that need to be in sync. If you aren't using version control then this will all have to be done manually e.g. keeping a spreadsheet of database changes since the previous version. This may just about be workable for the smallest of projects that is only deployed internally.