3 ms·

Structure is important, that's where NoSQL fails from the get go. We should stop investing so much time into NoSQL and look more into combining SQL and Graphs

emodendroket 4y ago
That seems a little like saying there's no reason for anyone to use a language without GC. Sure, for most applications it is fine.
- trashtester 4y ago
  That's a good analogy. SQL RDBMS's, just like Java and other languages with GC have huge utility in a multitude of enterprise software situations. These probably make up the majority of software systems and lines of code out there. Then there are a few domains that NEED other solutions. In terms of CPU cycles these may be consuming more resources. These are operating systems, game engines, ML libraries, search engines, social media platforms and huge webshops like Amazon. But to store all data in Spark or MongoDB just because that's what <insert Cargo Cult idol> is doing makes about as much sense at programming everything in C/C++.
winrid 4y ago
You can use NoSQL with a schema and have strict enforcement. What the NoSQL db does is make storing objects easy with less boilerplate or abstraction.
- 9dev 4y ago
  How is NoSQL with schema validation and strict enforcement anything but SQL with extra steps?
  - dgb23 4y ago
    The schema restrictions you can express in SQL are both insufficient and not flexible enough even for relatively trivial things, except you are either fine with storing and retrieving things in a completely different shape than you actually need, or if you are fine with constantly migrating your schema. That's not a sufficient argument against adopting SQL for something, but other solutions are certainly _not_ just SQL with extra steps. Not everything maps nicely onto flat tables with predefined slots.
hugofirth 4y ago
You may be interested in https://www.gqlstandards.org/ https://www.gqlstandards.org/ and https://www.iso.org/standard/79473.html https://www.iso.org/standard/79473.html TL;DR the ISO standards committees behind SQL are working on bring graph query languages and SQL databases closer together. Obviously there is work to be done at the storage/query planning layer after that, but I’m hopeful once the surface exists more widely that will drive more work in those areas.

emodendroket 4y ago

That seems a little like saying there's no reason for anyone to use a language without GC. Sure, for most applications it is fine.

trashtester 4y ago
That's a good analogy. SQL RDBMS's, just like Java and other languages with GC have huge utility in a multitude of enterprise software situations. These probably make up the majority of software systems and lines of code out there. Then there are a few domains that NEED other solutions. In terms of CPU cycles these may be consuming more resources. These are operating systems, game engines, ML libraries, search engines, social media platforms and huge webshops like Amazon. But to store all data in Spark or MongoDB just because that's what <insert Cargo Cult idol> is doing makes about as much sense at programming everything in C/C++.

winrid 4y ago

You can use NoSQL with a schema and have strict enforcement. What the NoSQL db does is make storing objects easy with less boilerplate or abstraction.

9dev 4y ago
How is NoSQL with schema validation and strict enforcement anything but SQL with extra steps?
- dgb23 4y ago
  The schema restrictions you can express in SQL are both insufficient and not flexible enough even for relatively trivial things, except you are either fine with storing and retrieving things in a completely different shape than you actually need, or if you are fine with constantly migrating your schema. That's not a sufficient argument against adopting SQL for something, but other solutions are certainly _not_ just SQL with extra steps. Not everything maps nicely onto flat tables with predefined slots.

hugofirth 4y ago

You may be interested in https://www.gqlstandards.org/ https://www.gqlstandards.org/ and https://www.iso.org/standard/79473.html https://www.iso.org/standard/79473.html TL;DR the ISO standards committees behind SQL are working on bring graph query languages and SQL databases closer together. Obviously there is work to be done at the storage/query planning layer after that, but I’m hopeful once the surface exists more widely that will drive more work in those areas.