I have extensive experience with Lotus Domino and CouchDB.
I know enough about MongoDB, that I know its not all that much different as far as design and usage patterns go. This link [1] tells me that basically mongo's data structure is indeed a Key/Value.
The schema you are talking about is not the schema I mean. What I was talking about that for any nontrivial Key/Value based database system it would be prudent to keep a recipe of how to normalize the data to 3rd Normal Form. Keeping this 3rd Normal Form schema around would greatly ease many troubles that arise from using NoSQL databases.
So what were you thinking about when you say "schema" - is it "relational" (normalized) schema or is it just the recipe that tells you what particular fields are for?
"Document-based" is more accurate. One thing that's nice about MongoDB is that you get a little bit more than Map/Reduce as far as querying.
The idea is that when a type is embedded or linked (using the terms from the Schema Design link you gave) there is a record of that.
And the data types for the fields also need to be recorded. It would be nice if attributes for which there exists a type (collection) were correctly specified as attributes of that type rather some other more general type (otherwise you may need to correctly associate those fields later for analysis).
I plan to record my schema something like this (although probably will want to include some other information like field descriptions):
[HTML]
version: 1
default: text
[Hash]
version: 1
default: text
[Post]
version: 1
(id_: ObjectID)
postid: text
title: text
author: {linked} User
authorname: {embedded} User.screenname
comments: {embedded} Comments
[User]
version: 1
(id_: ObjectID)
screenname: text
shash: hash
[Comments]
(id_: ObjectID)
version: 1
text: text
created: date
name: text
[Comments]
(id_: ObjectID)
version: 2
text: html
created: date
name: text
approved: boolean
Also, each record (here I am referring to the actual data collections, not the schema collection) will contain the id and version number of the type (referring to the schema collection). This is for generating screens. As fields are added, changed, or removed, new type versions are recorded.
I know enough about MongoDB, that I know its not all that much different as far as design and usage patterns go. This link [1] tells me that basically mongo's data structure is indeed a Key/Value.
The schema you are talking about is not the schema I mean. What I was talking about that for any nontrivial Key/Value based database system it would be prudent to keep a recipe of how to normalize the data to 3rd Normal Form. Keeping this 3rd Normal Form schema around would greatly ease many troubles that arise from using NoSQL databases.
So what were you thinking about when you say "schema" - is it "relational" (normalized) schema or is it just the recipe that tells you what particular fields are for?
[1]: http://www.mongodb.org/display/DOCS/Schema+Design