6 ms·

It's easy to jump in, and able to provide decent environment for developers. I believe that's similar to early MySQL, you know with only MyISAM tables, where th

by eknkc 14y ago

It's easy to jump in, and able to provide decent environment for developers. I believe that's similar to early MySQL, you know with only MyISAM tables, where there was no transaction support or referential integrity and your data was open to all kinds of corruption issues. It was easy to use, was installed almost everywhere and there were great tools around it. It has grown to be a pretty decent RDBMS. Mongo has the same traction behind it, so it should become a great solution in no time. (Given a decent development process it is. See PHP for a counter example)

lucian1900 14y ago
But why wait, when you can use Postgres now?
- eknkc 14y ago
  I'm not saying that I would not use Postgres now. Actually, I've been running a website on MongoDB for over a year now. I don't remember the reason behind it but it haven't caused any problems so far. The web server handles more than a million page views per day and all data is stored on MongoDB. I'm not perfectly happy with it but it does what it's supposed to. With some gimmicks here and there. If I started from scratch today, I'd probably go with PostgreSQL. Not because MongoDB is "bad" but because it's data model itself causes some problems. For example, if you query some range on an index with upper and lower bounds (like age > 18 && age < 50) it can not use both bounds on the index. That's been driving me crazy on some queries and I had to use hacky indexes. It's not a bug though, it's the query syntax and data model causing these kind of behaviour. There have been similar examples during this last year but not something that would cause "hate" agains it. On the plus side, it makes prototyping stuff so pleasantly easy that you can not have that on PostgreSQL.
  - lucian1900 14y ago
    I consider it a design flaw that queries can only use one index. In fact, many queries can never use any index (I had to write a query optimiser because mongo doesn't bother). Actually some queries do use more than one index (top-level $or), but it's actually more annoying than useful. I find especially during prototyping having a clear data model is great. SQLAlchemy + Postgres, then later on Alembic for migrations is so much more pleasant, predictable and performant.
deleted 14y ago
[deleted]

by eknkc 14y ago

lucian1900 14y ago

But why wait, when you can use Postgres now?

eknkc 14y ago
I'm not saying that I would not use Postgres now. Actually, I've been running a website on MongoDB for over a year now. I don't remember the reason behind it but it haven't caused any problems so far. The web server handles more than a million page views per day and all data is stored on MongoDB. I'm not perfectly happy with it but it does what it's supposed to. With some gimmicks here and there. If I started from scratch today, I'd probably go with PostgreSQL. Not because MongoDB is "bad" but because it's data model itself causes some problems. For example, if you query some range on an index with upper and lower bounds (like age > 18 && age < 50) it can not use both bounds on the index. That's been driving me crazy on some queries and I had to use hacky indexes. It's not a bug though, it's the query syntax and data model causing these kind of behaviour. There have been similar examples during this last year but not something that would cause "hate" agains it. On the plus side, it makes prototyping stuff so pleasantly easy that you can not have that on PostgreSQL.
- lucian1900 14y ago
  I consider it a design flaw that queries can only use one index. In fact, many queries can never use any index (I had to write a query optimiser because mongo doesn't bother). Actually some queries do use more than one index (top-level $or), but it's actually more annoying than useful. I find especially during prototyping having a clear data model is great. SQLAlchemy + Postgres, then later on Alembic for migrations is so much more pleasant, predictable and performant.

deleted 14y ago

[deleted]