I recently finished an article that introduced "Nordic", a SQL Server implementation of an object/relational database design in The Architecture Journal written by Paul Nielsen. I have only begun to review the implementation schema and Paul's Nordic presentation. Although his approach is exciting, I have some important questions, concerns, etc. while I attempt to apply what I've learned.
*These are mostly thought-provoking rather than real questions about Nordic's implementation or vision.
First and most importantly, what copyright limitations are placed on "Nordic"? How free am I to develop my own ideas founded on Nordic?
The persistant nags in my head during my review was "What are the disadvantages?" and "Where are the resources from the 'other side'?"
Many companies eventually face major platform-change decisions in the life of their data stores and good architects recognize the need to balance the "today" with "tomorrow". Nordic seems to address these issues relatively well with the exceptions of relying on SQL Server UDFs. However, popular competitors these days have alternatives that would make porting relatively easy. How does Paul see Nordic balancing these needs?
There's a constant debate about how much data validation logic should be placed in the database. The primary being that the more validation you put into standard's compliant SQL, the more platform indepent your data AND business logic. This flexibility can be a great counter-measure for cost-evaluation of product upgrades and transitions. How is Nordic an "enabler" for this need?
How does Nordic currently or plan to manage object versions? Specifically, when the interface to an object changes, will Nordic be flexible enough to provide both versions and possibly even an upgrade path for existing object storage?
Paul has effectively identified that Nordic may not be the best option for OLTP. However, auditing (activity logs) are a requirement for implementations of almost every system flavor. How can/could Nordic handle this?
Is SQL Server 2005's CLR integration as key to the future of Nordic? FYI: Many developers have found XML Serialization too "bloated" (see: the IDE product "#Develop" http://sharpdevelop.net/).
How does Nordic attempt to generically define what are often very language-specific constructs? Will Nordic take the path of a language-specific definition in a common framework (Java) or a common-language definition in a common framework (.NET)?