Well, Orchard is relational data, it's just deconstructed/genericised a certain amount. Think of it like this: instead of having numerous tables with a "description" column, you have a single table that will hold descriptions for all entities,
and any type of entity can join to that table if needed (that table is Common_BodyPartRecord in the above case). You could compose views over the Orchard database that mapped entities to the kind of data model you would more normally expect. But actually,
Orchard's database model is very efficient from a design point of view - there is little to no redundancy in either data or structure. And that's a good thing even from the performance angle, because 1-to-1 joins are cheap (at least, this is the impression
I got from a conversation a while back with a DBA friend).
You might want to look at Orchard's export module and see how the XML data gets exported.
Let me just suggest a different way of modelling the relationship you described above. "CompanyType" can be a content type, rather than a content part; then you can also give it BodyPart to model the description. Now you just need a relationship between
Company and CompanyType - in Mechanics you'd do this by creating a third content type called "CompanyToCompanyType" (I call this a Connector). Why do I go to such lengths to model the relationships? Because this has numerous benefits:
- In-built content editing permissions can control permissions on CompanyToCompanyType, giving you very fine-grained control. Basically you can specify which groups of users are allowed to create, edit and delete that relationship, independent of any permissions
users have over Company or CompanyType.
- In-built versioning and auditing. The relationship stores a Published time (and which user owns it), independent of the published time of Company or CompanyType. Versioning isn't quite supported yet, I mostly implemented it but there are still a couple
of problems, but once this works you will be able to view full historical data about the relationships of an item!
- Extensibility. Additional parts and fields can be added to the connector. Suppose you added BodyPart on CompanyToCompanyType - you could then use it as a notes field. There are much better applications of this, though. For instance you can add my SequencePart
to any connector and that allows you to specify the order of the related items (particular useful for building menus and other scenarios where you want to control the order of a list). You can also add TitlePart to a connector; this allows you to override
the title of an item when it's displayed (again useful in menus, when you sometimes want to override with a shorter title than the item actually has).
- UI composability. You can model relationships entirely within the content types admin UI, and perform most rendering customisations in Placement.info files, without having to write any code.
There are certain other benefits and features I have planned that led me to design things this way, but it works and is extremely flexible.