db.test.find({‘tags’: /jquery/io});

which is a flag to compile this regex once.

Stuff like this works in Perl and I think in Ruby’s regex lib…

MongoDB’s regex lib is javascript right? Really not sure if that works or not in js. or maybe compile it ahead of time using RegExp::compile

You see, to me, it feels like the “gotcha” is in MySql, not MongoDB.

Being able to query by a number as well as by the numbers string representation feels like a strange thing.

In the rigid and strict world of traditional RDBMS, you wouldnt expect the engine to just take either data type (or is it just me??).

As @kk points out, this is specifically a MySql “feature”

That applies only to MySQL, in Postgres and other real databases you would have to use CAST(id AS TEXT)

- you can use a string in place of an integer in a query, and
- case insensitive queries are the default

…in MySQL are complete mis-features. How can one claim that is sane? I would never be caught dead doing something silly like that. Who would actually expect ‘jQuery’ and ‘jquery’ to be the same thing in the database?!?

While it’s true that you select a column type when defining a table schema in a relational database like MySQL, how the values are stored internally does not affect how you can query for that data. With relational SQL databases, all query parameters are effectively strings, even with prepared statements. There is no difference between these two queries in MySQL:

1
2

SELECT * FROM posts WHERE id = 52;
SELECT * FROM posts WHERE id = '52';

They both return the exact same dataset in MySQL. That’s the “gotcha” here. Data types in MongoDB affect how you can build your queries, whereas with relational SQL databases, they only matter if you want to use query functions like aggregates, date formatting, etc.

Often times I’ve seen people install it alongside MySQL or have both a master and slave mongod instance running on the same machine/VM/slice/EC2 instance. You’re going to run into resource bottlenecks eventually with that kind of setup.

This fact is true of any relational database as well, where you have a “defined schema” as opposed to no schema in MongoDB. The only difference is that you’ll most likely run into insertion exceptions if your data doesnt match the type defined in the schema.

The shift here is that for things like MongoDB, your schema is effectively defined in your code rather than in your database.

Your application should know how to store and retrieve data from the database consistently, and if done correctly, will never run into the problem you have described of having keys with different value types.