For those of you that have seen my comments on the DotNetNuke forums, my book, or the forum here on this site, you more than likely have noted the consistent notes that I recommend avoiding the "ObjectQualifier" setting within DotNetNuke at all costs. Most of the time I have simply put, I don't use it and recommend that you don't either, but have not given a very detailed explanation as to why I'm not a fan. Below I will share with you what the ObjectQualifier is, why it was created, and why I don't recommend using it.
What is the Object Qualifier
The Object Qualifier is a configuration setting within the DataProvider section of the web.config available in DotNetNuke that allows you to set an optional qualifier that will be prefixed to any and all SQLServer objects that are created as part of the DotNetNuke and module installation process. Module developers support the usage of this option by including "" at the beginning of the creation of all scripts that are executed as extensions are installed.
Why it was Created
The DotNetNuke object qualifier, as to the information that I have been provided, was created for those that wanted to get the "most value" from hosting plans that offered limited support for SQLServer databases. The Object Qualifier was introduced to allow you to effectively install multiple DotNetNuke installations within the same physical database.
Why I Do Not Use It
There are a number of reasons that I do not use an ObjectQualifier within my installations.
Data Recovery Model of Shared Databases
The first and primary reason that I do not use an ObjectQualifier is that more than anything I don't want to share a database across multiple sites anyway. We already recommend that people don't use Multi-Portal installations due to performance, data recovery, and other reasons, why would we want to mix two entirely separate data models into the same database.
Backups and restores will affect both sites, and the overall recovery model is just plain wrong.
Databases are Cheap
Current hosting plans are easy to come by that have multiple SQLServer databases, one per domain, which allows for a fully separate DotNetNuke installation for each domain. This is the recommended best practice anyway and avoids any issues with a shared data model
No Guarantee that Third-Party Supports It
Although as I mentioned the Object Qualifier is something made available to third party extension developers, you have no guarantee that they fully support the usage of an Object Qualifier. If using an Object Qualifier with a third-party module that doesn't support it can result in very un-expected site performance as well as errors and even worse site outages depending on the nature of the problem.
Cannot Easily Change Your Mind
Lastly, once you decide to go with an Object Qualifier, you are pretty much stuck with it. Although theoretically possible to disable it, it is not a trivial task and results in a lot of effort as all tables, functions, and stored procedures must be renamed as well as items internal to individual stored procedures. There is not a clean/clear process to reverse should you have issues with it in the future.
Conclusion
I hope this serves as a bit of an overview as to why I don't recommend the use of Object Qualifier and why I am always recommending against it! Feel free to share comments below.