4 ms·

I disagree with the idea that MongoDB has struck the right balance. I have seen production issues from manual editing of data which resulted in a floating point

I disagree with the idea that MongoDB has struck the right balance. I have seen production issues from manual editing of data which resulted in a floating point instead of an Integer. I really wish MongoDB had support for a strong schema in the DB besides indexes (in addition to existing support for schema-less). I only actually want schema-less at most 20% of the time, but I am stuck with it for everything outside of indexes.

spamizbad 13y ago
Completely agree. I'd love it if you could provide collections a baseline set of document validation rules- rules that only apply to fields you explicitly mention. I guess what I want is a schema-ish database, where I can say "these 5 fields are required and must conform to these rules. Anything else is fair game."
- jasonmccay 13y ago
  I really like the term "schema-ish" and I think that most people probably want something like this. They will inevitably still have a defined structure for their data, but they need that extra bit of flexibility to keep the overall data structure simplistic and sensible.
- tokenizerrr 13y ago
  I recall reading about how MongoDB saves all the key names with each record, since there is no schema. This results in quite a lot of disk space going to waste. It seems like this could be a solution to that problem as well, I like it.
  - jasonmccay 13y ago
    The guys at Tokutek are solving that problem with MongoDB. Pretty interesting stuff ... you should check it out.
- vyrotek 13y ago
  I've been looking some something similar to what you've described. I recently discovered PostgreSQL has a 'hstore' feature which seems to support this. You seem to be able to make a normal table and then specify one column to act like a key/value dictionary. These values can even be included in queries. http://www.postgresql.org/docs/9.0/static/hstore.html http://www.postgresql.org/docs/9.0/static/hstore.html
  - antsaasma 13y ago
    PostgreSQL also has JSON support. You might want to check out Christphe Pettus's presentation on this subject: http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-database/ http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-da...
- tracker1 13y ago
  It is pretty trivial to create an API/Repository in front of a non-sql based database that can use JSON-Schema for validation of data structures. In fact, it's probably better if you do this. For that matter, if you use NodeJS, then said API and the backend structure are fairly trivial. I used NodeJS to create an API for queries against MongoDB, and it allowed for me to normalize and check data in said queries against the data. It also allowed me to do programmatic elimination of sensitive portions of data from the front end without much effort at all. It seems what you really should be creating is an API that your application uses. I'm a proponent of the Data Storage Layer being as dumb as possible. If it weren't for the built in indexing, and common access structures, I'd be more inclined to roll my own. I do think that MongoDB does a nice job of striking a balance between say Couch and MySQL (I intentionally use MySQL here instead of PostgreSQL or MS-SQL). I also think that RethinkDB within a year or so will likely be a better option for many of those thinking about MongoDB.

spamizbad 13y ago

Completely agree. I'd love it if you could provide collections a baseline set of document validation rules- rules that only apply to fields you explicitly mention. I guess what I want is a schema-ish database, where I can say "these 5 fields are required and must conform to these rules. Anything else is fair game."

jasonmccay 13y ago
I really like the term "schema-ish" and I think that most people probably want something like this. They will inevitably still have a defined structure for their data, but they need that extra bit of flexibility to keep the overall data structure simplistic and sensible.
tokenizerrr 13y ago
I recall reading about how MongoDB saves all the key names with each record, since there is no schema. This results in quite a lot of disk space going to waste. It seems like this could be a solution to that problem as well, I like it.
- jasonmccay 13y ago
  The guys at Tokutek are solving that problem with MongoDB. Pretty interesting stuff ... you should check it out.
vyrotek 13y ago
I've been looking some something similar to what you've described. I recently discovered PostgreSQL has a 'hstore' feature which seems to support this. You seem to be able to make a normal table and then specify one column to act like a key/value dictionary. These values can even be included in queries. http://www.postgresql.org/docs/9.0/static/hstore.html http://www.postgresql.org/docs/9.0/static/hstore.html
- antsaasma 13y ago
  PostgreSQL also has JSON support. You might want to check out Christphe Pettus's presentation on this subject: http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-database/ http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-da...
tracker1 13y ago
It is pretty trivial to create an API/Repository in front of a non-sql based database that can use JSON-Schema for validation of data structures. In fact, it's probably better if you do this. For that matter, if you use NodeJS, then said API and the backend structure are fairly trivial. I used NodeJS to create an API for queries against MongoDB, and it allowed for me to normalize and check data in said queries against the data. It also allowed me to do programmatic elimination of sensitive portions of data from the front end without much effort at all. It seems what you really should be creating is an API that your application uses. I'm a proponent of the Data Storage Layer being as dumb as possible. If it weren't for the built in indexing, and common access structures, I'd be more inclined to roll my own. I do think that MongoDB does a nice job of striking a balance between say Couch and MySQL (I intentionally use MySQL here instead of PostgreSQL or MS-SQL). I also think that RethinkDB within a year or so will likely be a better option for many of those thinking about MongoDB.