4 ms·

I sincerely still prefer mongodb syntax because: - Fits well with a programming language; {a: data.x} is better than 'WHERE A="' + data.x + '"' (sanitize?) or

by ttty 12y ago

I sincerely still prefer mongodb syntax because: - Fits well with a programming language; {a: data.x} is better than 'WHERE A="' + data.x + '"' (sanitize?) or similar which are harder to read. SQL queries are good for direct input, mongodb queries styles are better to be used with a programming language;

aethertap 12y ago
Your comment made me realize why I prefer to work in ORMs instead of raw SQL, even though I'm frequently frustrated by their limitations - it all comes down to composability. The mongodb syntax looks like it supports composing statements much more readily than SQL. It makes me wonder if there's been any serious work done making a query language that's fully as general as SQL, but is designed to be safely and easily composable so that you can build queries up from parts. Anyone know of such a thing? The mongodb approach of query-as-data-structure is as close as I've seen.
- masklinn 12y ago
  > The mongodb syntax looks like it supports composing statements much more readily than SQL. It makes me wonder if there's been any serious work done making a query language that's fully as general as SQL, but is designed to be safely and easily composable so that you can build queries up from parts. Haven't you noticed that it's exactly what the Sequel snippet does? It's also what SQLAlchemy's Expression Language does. It's a reification of SQL queries in the host language, so it can/should give pretty much all the tools of SQL.
  - TylerE 12y ago
    In some ways it does, but also remember it's a MUCH less rich query language. It's a lot easier to make a simple api mapping when you don't have such exotic things as "joins".
  - aethertap 12y ago
    The ORMs I've used have always tried to map tables to classes (or whatever similar language structure is available). That works well almost all the time, but I get tripped up when the queries get to be more complex or specialized to a particular use. I haven't used SQLAlchemy's expression language, but glancing over it now it looks like it might be just what I was looking for (at least for python), so thanks for the pointer.
chc 12y ago
That is not how you do parameterized queries. With any civilized database library, it would be something along the lines of `"WHERE a = ? AND b = ?", data.x, data.y`, so that the parameters are like function parameters.
- ttty 12y ago
  I've said similar because of this, so your comment is included in my statement. That doesn't change much
TylerE 12y ago
If you're building queries in ANY language by concatenating strings you're doing it wrong. In a sane language that query might look something like cursor.execute("select field from tbl where long_obtuse_column_name=:foo and status != :status", foo=query, status='open') All parameters are properly escaped by the api of course, so even if foo is "'; drop table audit; " you don't have any problems.
- hackhat 12y ago
  I've said similar because of this, so your comment is included in my statement.
aikah 12y ago
If you really care about your data and you don't think a database should just be a bag where you put stuff but something that can be trusted , and efficient when it comes to storing data then you wouldn't be using MongoDB.
EpicEng 12y ago
Your users don't give two craps about the syntax. The technology choice is one of application requirements. If you chose Mongo over e.g. a SQL DB because you like your code to look pretty then I have to admit that I wouldn't trust your software at all.
- ttty 12y ago
  >Your users don't give two craps about the syntax. Of course not, but your developers yes. Use a complex syntax and more bugs will appear. Do you care about bugs? No, but your users will. > If you chose Mongo over e.g. a SQL DB because you like your code to look pretty then I have to admit that I wouldn't trust your software at all. This is not my only reason.

by ttty 12y ago

aethertap 12y ago

Your comment made me realize why I prefer to work in ORMs instead of raw SQL, even though I'm frequently frustrated by their limitations - it all comes down to composability. The mongodb syntax looks like it supports composing statements much more readily than SQL. It makes me wonder if there's been any serious work done making a query language that's fully as general as SQL, but is designed to be safely and easily composable so that you can build queries up from parts. Anyone know of such a thing? The mongodb approach of query-as-data-structure is as close as I've seen.

masklinn 12y ago
> The mongodb syntax looks like it supports composing statements much more readily than SQL. It makes me wonder if there's been any serious work done making a query language that's fully as general as SQL, but is designed to be safely and easily composable so that you can build queries up from parts. Haven't you noticed that it's exactly what the Sequel snippet does? It's also what SQLAlchemy's Expression Language does. It's a reification of SQL queries in the host language, so it can/should give pretty much all the tools of SQL.
- TylerE 12y ago
  In some ways it does, but also remember it's a MUCH less rich query language. It's a lot easier to make a simple api mapping when you don't have such exotic things as "joins".
- aethertap 12y ago
  The ORMs I've used have always tried to map tables to classes (or whatever similar language structure is available). That works well almost all the time, but I get tripped up when the queries get to be more complex or specialized to a particular use. I haven't used SQLAlchemy's expression language, but glancing over it now it looks like it might be just what I was looking for (at least for python), so thanks for the pointer.

chc 12y ago

That is not how you do parameterized queries. With any civilized database library, it would be something along the lines of `"WHERE a = ? AND b = ?", data.x, data.y`, so that the parameters are like function parameters.

ttty 12y ago
I've said similar because of this, so your comment is included in my statement. That doesn't change much

TylerE 12y ago

If you're building queries in ANY language by concatenating strings you're doing it wrong. In a sane language that query might look something like cursor.execute("select field from tbl where long_obtuse_column_name=:foo and status != :status", foo=query, status='open') All parameters are properly escaped by the api of course, so even if foo is "'; drop table audit; " you don't have any problems.

hackhat 12y ago
I've said similar because of this, so your comment is included in my statement.

aikah 12y ago

If you really care about your data and you don't think a database should just be a bag where you put stuff but something that can be trusted , and efficient when it comes to storing data then you wouldn't be using MongoDB.

EpicEng 12y ago

Your users don't give two craps about the syntax. The technology choice is one of application requirements. If you chose Mongo over e.g. a SQL DB because you like your code to look pretty then I have to admit that I wouldn't trust your software at all.

ttty 12y ago
>Your users don't give two craps about the syntax. Of course not, but your developers yes. Use a complex syntax and more bugs will appear. Do you care about bugs? No, but your users will. > If you chose Mongo over e.g. a SQL DB because you like your code to look pretty then I have to admit that I wouldn't trust your software at all. This is not my only reason.