Chris covers this subject in much more detail, but I'll post anyway.

I was looking around Ning (perhaps Ning around?) and noticed an interesting blog entry about the Ning Content Store.

This hosting service provides its community with "data playdough" in the form of content objects which can be read (but not written) across apps. There is no direct management of the data store, although you can browse the data using the RESTish pivots.

The biggest difference between the Content Store and a traditional RDBMS is that in the Content Store, there is no definition of content structure separate from actual content. There are no table schemas that must be set up before rows are inserted. The type and developer attributes that an app chooses to use at runtime are the type and developer attributes that end up in a content object.

Restrictions on content type and structure are not enforced by the content store. That job is left to the app. This allows apps to be much more flexible about the data they manage. Creating an app that allows end-users to define their own fields in addition to those defined by the app developers (such as a flexible calendaring app or a to-do list manager), is unwieldy in a relational database -- in essence, a developer would have to create a mechanism like that provided by the Content Store natively. Queries and data management are simpler, and apps can be both more flexible and more powerful, without making them harder to build.

Source: Ning Dev Docs

I prefer the structured approach to defining application data, but I understand why Ning's developers are prioritizing convenience. Over time, conventions and standards will emerge in the Ning community, and us structured folks can always help.

Playdough and Lego bricks are both great ways to build things.