Are there any plans to move to a cleaner SQL schema for the Cambrian release?

By cleaner, I mean a schema based on more readable examples like DNN.Portals instead of dbo.dnn_Portals, and DNN.Modules instead of dbo.dnn_Modules.

Or are there reasons the Core Team have decided to stay with the existing schema whether for "backward compatibility" or whatever?

Even if the Core Team remains committed to the prior schema, will it provide support in Startkit Templates or whereever else appropriate for those of us who want to move to a database schema with a pattern such as MyCompany.MyTable and MyCompany.MyStoredProcedure?

Thanks

CT

Thanks for reply.

I do understand how DotNetNuke has implemented its naming scheme with "object qualifiers" which was originally designed (as I understand it) prior to the days of SQL Server 2005.

However, I'm not sure I agree with you about "grown up" SQL Servers and your statement about objects prefaced by their owner. Microsoft SQL Server documentation explains that beginning with SQL Server 2005 that Microsoft has separated the concept of ownership from the concept of schema so that they are now distinct and separate. Microsoft also explains the default assumptions they use in transitioning something that used to be an "owner" to what is now a "schema". Different "schemas" can now be owned by different "owners". It does provide for a much cleaner and much more elegant architecture.

So if the Core Team members responsible for SQL database architecture and naming conventions have not examined the improvements that Microsoft has made in moving from older SQL Servers to the newer SQL Server 2005 and higher, I hope they will do so.

Thanks much,

CT 

Thanks for info and the discussion. Filling in history for newcomers is always helpful.

As an aside question, when you use the lingo "DNN site", are you referring to the entire DNN installation? Or one of the DNN portals within the DNN installation?

In any event, I guess the issue I was focusing on was the question of whether DotNetNuke Core will be using or not using the new features beginning with SQL Server 2005 that separate schema from ownership.

Of course, the real underlying issue in my opinion is simply communication of recommended best practices for coding and naming. Where is the set of "best practice" guidelines published that is recommended for DNN developers to follow so that we all can better adhere to a common practice standard?

And where is the appropriate place for discussing these standards? For example, I am a strong advocate of consistency in all senses of the word consistency. So for example, I am not fond of the DotNetNuke use of mixing verbs and nouns when naming controls for a module. Note the use by DotNetNuke of View.ascx and EditModulename.ascx and Settings.ascx which mixes verbs and nouns and some include the module name and some do not. Instead, I would personally favor consistent use of verbs without the module name because the module name is used for the directory. Then you would have the following:

Modulename\View.ascx, Modulename\Edit.ascx, and Modulename\Configure.ascx

or some other verb instead of Configure. Well, presumably, I am free to name my controls within a module however I want, and will continue to do so.

However, again, the real underlying issue is clear communication about best practices for coding and naming conventions. Is there a publicly available (ie, available to members of this website who are not members of the Core Team) document that is maintained current and up-to-date for coding and naming conventions as recommended by the overall DotNetNuke community? Or otherwise, where is the document that explains the requirements for a DotNetNuke module to be "certified"?

Thanks,

CT