3 ms·
You can do all that with SQL too. And do you have any very large tables? > joins will kill you when you have very large tables nitpick, but table size doesn't
by Mavvie 6y ago
You can do all that with SQL too. And do you have any very large tables?
> joins will kill you when you have very large tables
nitpick, but table size doesn't directly matter (much). if your queries are very specific and only return a couple rows, then you can have huge tables and join across them without issue. Joins only get particularly painful if you're doing aggregation/reporting queries across large parts of it
- interlocutor 6y agoSQL databases don't support easy schema evolution, sharding and so on.
- SomeCallMeTim 6y agoPostgreSQL directly supports table sharding. https://pgdash.io/blog/postgres-11-sharding.html https://pgdash.io/blog/postgres-11-sharding.html Schema evolution is supported by pretty much every ORM you'd care to use; it's not the job of the SQL database to handle the migration. I'm using Prisma and you literally change the software spec for the schema and say "migrate", and it creates the migration SQL and applies it to the Postgres DB programmatically. That gets you deterministic schema evolution and not the "my schema isn't actually reliable" that NoSQL/no-schema databases rely on. And then you have CockroachDB/YugabyteDB that give you extreme horizontal scalability, with full PostgreSQL compatibility... And bang, the last reason to use MongoDB vanishes.
- HeyImAlex 6y agoI think a missing piece is making materialized views fast since there will always be cases where someone wants to denormalize to get around performance issues, even with well designed indexes.
- revscat 6y agoAnd Mongo is even worse. You can easily change document structures, but now you have inconsistent data over time.
- dwheeler 6y ago> if your queries are very specific and only return a couple rows, then you can have huge tables and join across them without issue. I agree, if you index your tables. Relational databases are very capable; when there's a performance problem, it's often due to simple things like failing to index what should have been indexed. No tool is perfect for all use cases. There are cases where relational databases won't work. But when I try to store data, I first consider storing it in files, and if that is unpleasant, I consider relational databases. These are both relatively simple time-tested solutions, and it's usually good to start with simple & time-tested unless there's a reason it won't work well.
- threeseed 6y agoI can also use Lists, Sets, Maps in my data structure. Doing the same in SQL requires a lot of intermediate tables.