Actually the idea itself is not that bad - but depends on the application. Ever wondered what is the
model
database is all about? Well, Microsoft is using an unique view about the database server. Many RDBMS use the database as top level concept related to an application. Microsoft has an ever higher level: the instance. An instance of an SQL Server is intended to be dedicated to an application. The
model database[
^] is the template for newly created databases. So practically, if you create a good template and dedicate the instance to the application, you can follow your current concept, and simply use SMO to
enumerate databases[
^].
But I have to emphasize, that this is a very special way to do it, based on Microsoft's own vision. In SQL server it is nothing bad in distributing your data between databases (catalogs) of the same server instance, they work transparently. It is better using this approach than allowing some tables to grow beyond a usability limits - even indexing has it's limitations.
If you take this path, I suggest you create a separate database for the data that is not year-related, like partner data and so on.
An other approach, you can use to partition your year related tables, take a look here:
http://databases.about.com/od/sqlserver/a/partitioning.htm[
^].
Choosing the best approach necessitates deeper knowledge about the application architecture, data model and business logic.