Thanks for the replies. Just to illustrate what I mean about hierarchical schemas, I thought of the idea because I was treating the schemas like object names. Each database I'm running has a discrete and separate business function, but I just found it easier to encapsulate certain tasks that are common to them all in the databases they originated from, which is why I'm using the same basic set of schemas like this. For example, I have one common schema called ConsistencyLogical and another ConsistencyPhysical. I use the first for tables related to logical maintenance of a database, such as the daily output of an SSIS Data Profiling Task, while the other's for tables which kept daily records of physical maintenance tasks like DBCC checks. I just thought it would be easier to refer to them through object syntax, like Consistency.Logical and Consistency.Physical, as a convenience, rather than any real substantive purpose. I reasoned that if I were responsible for maintaining 100 databases, a standard schema structure like this would might be easier to perform certan administration tasks faster, since I would instantly know where to find all the right procedures, functions, tables, views, etc.; it also makes it easier on the eyes to scan through long lists of tables and other objects in Management Studio. For example, if I want to check for any new missing indexes found by last week's SSIS job, I could look for the ConsistencyLogical.MissingIndexes table in any database to instantly find out. I don't want to get accustomed to doing this though if it isn't an acceptable practice. 🙂

I didn't think of the implications for backups - I'll have to take that into account.

Thanks again,

Steve