4 ms·

Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t

by mruts 8y ago

Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.

geezerjay 8y ago
> Why not just use a SQL db that handles json and stick everything in a couple columns? Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.
- ddebernardy 8y ago
  Nothing on paper, if you get the schema more or less correctly the first time. The problem is when you need to do a schema change that affects terabytes of data down the road.
  - ants_a 8y ago
    That is going to be a problem regardless of technology. With an enforced schema you will at least know that all of the existing data matches the schema. Without it you have to hope that you had zero bugs while collecting the terabytes of data.
    - scarface74 8y ago
      With almost any language, you can enforce schema via the “ORM”. Yes I know it’s not really an ORM but you get the point.
    - ddebernardy 8y ago
      Yeah, but it's a different type of problem. If you've a schema, you sometimes need to rewrite an entire table as part of a migration, and that can mean heavy engineering if you want to avoid downtime or disabling writes during the migration. There are 1:1 relationships between tables in the wild that wouldn't have passed a sniff test as part of an early schema design review, but then got created regardless to avoid a lengthy table rewrite. If you've no schema proper, by contrast, you can manage multiple variations of what the data might look like in code. Not that such a thing is simple; it's definitely not, for the reason you raised. But it's simpler to deploy and migrate, or certainly might appear to be so to someone who isn't comfortable with SQL. Also, there's a class of apps where having a schema doesn't add much value and NoSQL actually makes sense. Think storing and mining logs, scraped data, ML training sets, etc. -- apps where it doesn't matter much however a big pile of data gets stored, so long as you can shovel through it in parallel or store it very fast.
- scarface74 8y ago
  You just answered your own question. If I’m only working with objects, why wouldn’t I just store everything as objects? And most ORMs suck outside of LINQ based ones since they aren’t a part of the language.
lmm 8y ago
"Support" for schemaless json columns tends to be quite limited. Maybe your database supports it, but do the drivers for that database in all the languages you might use support them? Will all that SQL tooling that you're so happy about handle the constructs that are needed to query into those JSON columns?
myrryr 8y ago
Because you still have to write a layer between your web app and the database at the prototyping stage? I can't just make calls from Html + JS to Postgres. But I can with MongoDB
- taffer 8y ago
  Or you can use something like Postgrest: http://postgrest.org http://postgrest.org
  - jacques_chester 8y ago
    Or Hasura GraphQL Engine: https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine
scarface74 8y ago
In that case, I would loose the tooling around Mongo for supporting JSON docs - especially the C# Mongo LINQ driver.
sonnyblarney 8y ago
The ability to query, index etc. I believe is much more limited than regular Mongo, but you can correct me if I'm wrong. Also, it feels like a cludge. RDBMS to me is to expensive in the churn and I've run into some deadly query scenarios. As a non-storage expert I would just love one of those 2000's era 'object databases' to start with. We used to use them a lot in networking because they suited well to topology. I'm not sure they're much of a thing anymore however as I suggest JSON DB's are pretty close to it so there's no need for it. But they fit developer's mentality really well.

by mruts 8y ago

geezerjay 8y ago

> Why not just use a SQL db that handles json and stick everything in a couple columns? Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.

ddebernardy 8y ago
Nothing on paper, if you get the schema more or less correctly the first time. The problem is when you need to do a schema change that affects terabytes of data down the road.
- ants_a 8y ago
  That is going to be a problem regardless of technology. With an enforced schema you will at least know that all of the existing data matches the schema. Without it you have to hope that you had zero bugs while collecting the terabytes of data.
  - scarface74 8y ago
    With almost any language, you can enforce schema via the “ORM”. Yes I know it’s not really an ORM but you get the point.
  - ddebernardy 8y ago
    Yeah, but it's a different type of problem. If you've a schema, you sometimes need to rewrite an entire table as part of a migration, and that can mean heavy engineering if you want to avoid downtime or disabling writes during the migration. There are 1:1 relationships between tables in the wild that wouldn't have passed a sniff test as part of an early schema design review, but then got created regardless to avoid a lengthy table rewrite. If you've no schema proper, by contrast, you can manage multiple variations of what the data might look like in code. Not that such a thing is simple; it's definitely not, for the reason you raised. But it's simpler to deploy and migrate, or certainly might appear to be so to someone who isn't comfortable with SQL. Also, there's a class of apps where having a schema doesn't add much value and NoSQL actually makes sense. Think storing and mining logs, scraped data, ML training sets, etc. -- apps where it doesn't matter much however a big pile of data gets stored, so long as you can shovel through it in parallel or store it very fast.
scarface74 8y ago
You just answered your own question. If I’m only working with objects, why wouldn’t I just store everything as objects? And most ORMs suck outside of LINQ based ones since they aren’t a part of the language.

lmm 8y ago

"Support" for schemaless json columns tends to be quite limited. Maybe your database supports it, but do the drivers for that database in all the languages you might use support them? Will all that SQL tooling that you're so happy about handle the constructs that are needed to query into those JSON columns?

myrryr 8y ago

Because you still have to write a layer between your web app and the database at the prototyping stage? I can't just make calls from Html + JS to Postgres. But I can with MongoDB

taffer 8y ago
Or you can use something like Postgrest: http://postgrest.org http://postgrest.org
- jacques_chester 8y ago
  Or Hasura GraphQL Engine: https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine

scarface74 8y ago

In that case, I would loose the tooling around Mongo for supporting JSON docs - especially the C# Mongo LINQ driver.

sonnyblarney 8y ago

The ability to query, index etc. I believe is much more limited than regular Mongo, but you can correct me if I'm wrong. Also, it feels like a cludge. RDBMS to me is to expensive in the churn and I've run into some deadly query scenarios. As a non-storage expert I would just love one of those 2000's era 'object databases' to start with. We used to use them a lot in networking because they suited well to topology. I'm not sure they're much of a thing anymore however as I suggest JSON DB's are pretty close to it so there's no need for it. But they fit developer's mentality really well.