Earlier quoted context omitted.
I am under no confusion. SQL ORMs all suffer from the same problems (which is forced by the underlying SQL model) that MongoDB does not. And your whole "use the right tool for the right job" goes without saying. It's others who seem to be obsessed with this "SQL is perfect for everything" delusion.
I'm under the impression that Mongo is merely hiding away some complexities, instead of truly resolving them.
Announcing MoSQL
111–118 of 118 posts
Re: Announcing MoSQL
#112Re: Announcing MoSQL
#113Earlier quoted context omitted.
To pick one, we like the fact that MongoDB lets you change your schema and add new fields to your documents without having to worry about migrations or keeping track of schema versions, or any of that. You could build something like that on top of SQL, but it's nice to have a tool where you don't have.
Serious question to you or anyone else who uses schemaless databases. Why is the ability to change schemas on the fly a good thing? Having worked at two companies that did, it was nothing but a recipe for disaster in large groups. Code that was dependent on expecting an integer or a string and not a collection would constantly break because a developer in some other group decided to store a collection instead of a th…
In the situations you describe, and when using most NoSQL databases, there's still a schema. It's just stored in the minds of developers, in documentation that's correct and up-to-date, in documentation that is incorrect and outdated, throughout application code, and numerous other places.
Then there's the sensible approach taken by most relational database systems, where the schema is centralized, it is described with some degree of rigor, and it can be more safely modified and managed.
Re: Announcing MoSQL
#114Earlier quoted context omitted.
I'm under the impression that Mongo is merely hiding away some complexities, instead of truly resolving them.
Can you be more specific about what you mean by that?
Re: Announcing MoSQL
#115Earlier quoted context omitted.
I'm under the impression that Mongo is merely hiding away some complexities, instead of truly resolving them.
Can you be more specific about what you mean by that?
Re: Announcing MoSQL
#116Earlier quoted context omitted.
I've had to deal with a lot of NoSQL advocates whose experience with SQL or relational databases doesn't extend beyond MySQL. Of course, it's understandable why they have a bad impression of SQL; they've only ever used one of the most inept implementations around. Those who are willing to try one of the more mature and sensible relational database systems usually see quite quickly the value that such systems provide.
Beyond a few terabytes of data, Postgres is just as worthless as MySQL, and every other non-experimental SQL option comes with a "call us" price tag. If there are production-ready options for biggish data other than NoSQL or high priced commercial analytics dbs, please share...
Also, your comment is rather ambiguous, I certainly hope you're not calling Postgresql experimental, because that would be laughable; and there are several examples of multi-terabyte databases using it.
Re: Announcing MoSQL
#117Earlier quoted context omitted.
Is there any way in those expressions to parse JSON and perform arbitrary calculations - i.e. like CouchDB views?
Sure, you can write server side procedures in f.ex. javascript that do arbitrary things with the json.
http://www.postgresql.org/docs/9.2/interactive/external-pl.h...
However, the PostgreSQL documentation doesn't mention JavaScript support anywhere. Are you sure there exists mature PL/JavaScript binding for PostgreSQL? If so, their docs should be updated.
[1] There's also "pgSQL", but that's a special-purpose language you won't find outside the database world. I don't recommend learning it unless you have strange requirements that make PL/pgSQL a perfect fit. For normale usage, use PL/Python or PL/Perl. In simple cases, use SQL directly.
Re: Announcing MoSQL
#118Earlier quoted context omitted.
Sure, you can write server side procedures in f.ex. javascript that do arbitrary things with the json.
To be fair, one should note that "only" the languages C, Python, Perl and Tcl [1] are officially supported by PostgreSQL. Also, there are 3rd-party bindings for other languages such as Java, PHP, R, Ruby, Scheme, sh: http://www.postgresql.org/docs/9.2/interactive/external-pl.h... However, the PostgreSQL documentation doesn't mention JavaScript support anywhere. Are you sure there exists mature PL/JavaScript binding f…
I can't vouch for any particular maturity level but seems to have active users and it's been around a few years already.