4 ms·

I work extensively with Splunk which is dominantly based on noSQL underneath (MongoDB, among other, proprietary technologies) I've also recently been [re]intro

I work extensively with Splunk which is dominantly based on noSQL underneath (MongoDB, among other, proprietary technologies) I've also recently been [re]introduced to graph databases (which are highly similar to the pre-relational network database paradigm) You can simulate graph relationships with an RDBMS or noSQL - but you shouldn't You can simulate an RDBMS with a graph db or noSQL - but you shouldn't You can simulate noSQL with graph and RDBMS tools - but, again, you shouldn't They all have their place - and ca even work quite well together, if you use them as they're intended

gibsonf1 4y ago
But thats just it, having many silos for connected information is just not the way we humans do it, nor necessary. A single conceptually indexed space/time hypergraph (as we humans do it) for any part of the world is all you need, scalable up to many billions of edges for that one part of the world.
- tremon 4y ago
  having many silos for connected information is just not the way we humans do it What do you mean? I can think of many silos containing connected information: municipal residence records, marriage registries, birth records, police reports, tax records, medical records (for each hospital) are all silos connected by a citizen's identity.
  - gibsonf1 4y ago
    You missed the "humans" part of my statement. We humans mentally have a fully linked graph (hypergraph) of what we know through space-time and conceptually indexed. We do not have a whole bunch of disconnected data silos in our minds. Modelling the very successful human approach to data and reality modeling may make more sense then using these 50 year old tables and disconnected silos?
johannes1234321 4y ago
> You can simulate noSQL with graph and RDBMS tools - but, again, you shouldn't What is the feature which makes the noSQL which you shouldn't do in a relational database? To me noSQL always looks like a subset of relational database. The only thing, maybe, is that you can truly put everything in, but with modern JSON features and all the other things I don't see a downside in using relational. (Except a little learning curve, while that can be hidden behind some ORM or something if you really want for the beginning)
- warrenm 4y ago
  The "schema on the fly" is the draw for noSQL - nothing has to be rigidly predefined like an RDBMS mandates
  - johannes1234321 4y ago
    CREATE TABLE foo (doc JSON); done. If that's really what you want.
    - warrenm 4y ago
      For every bit of JSON that comes in? No And then having to figure out what all the fields are after the fact? No That's why noSQL exists
      - johannes1234321 4y ago
        What is the thin noSQL brings to the table which a relational system doesn't have? (Except that writing a depth search in a JSON document in SQL is a bit more cumbersome, but if that is a concern that can be wrapped in a data access library to generate the SQL)
        warrenm 4y ago
        I think I've explained that above - it's not having to be rigidly tied to a schema :)

gibsonf1 4y ago

But thats just it, having many silos for connected information is just not the way we humans do it, nor necessary. A single conceptually indexed space/time hypergraph (as we humans do it) for any part of the world is all you need, scalable up to many billions of edges for that one part of the world.

tremon 4y ago
having many silos for connected information is just not the way we humans do it What do you mean? I can think of many silos containing connected information: municipal residence records, marriage registries, birth records, police reports, tax records, medical records (for each hospital) are all silos connected by a citizen's identity.
- gibsonf1 4y ago
  You missed the "humans" part of my statement. We humans mentally have a fully linked graph (hypergraph) of what we know through space-time and conceptually indexed. We do not have a whole bunch of disconnected data silos in our minds. Modelling the very successful human approach to data and reality modeling may make more sense then using these 50 year old tables and disconnected silos?

johannes1234321 4y ago

> You can simulate noSQL with graph and RDBMS tools - but, again, you shouldn't What is the feature which makes the noSQL which you shouldn't do in a relational database? To me noSQL always looks like a subset of relational database. The only thing, maybe, is that you can truly put everything in, but with modern JSON features and all the other things I don't see a downside in using relational. (Except a little learning curve, while that can be hidden behind some ORM or something if you really want for the beginning)

warrenm 4y ago
The "schema on the fly" is the draw for noSQL - nothing has to be rigidly predefined like an RDBMS mandates
- johannes1234321 4y ago
  CREATE TABLE foo (doc JSON); done. If that's really what you want.
  - warrenm 4y ago
    For every bit of JSON that comes in? No And then having to figure out what all the fields are after the fact? No That's why noSQL exists
    - johannes1234321 4y ago
      What is the thin noSQL brings to the table which a relational system doesn't have? (Except that writing a depth search in a JSON document in SQL is a bit more cumbersome, but if that is a concern that can be wrapped in a data access library to generate the SQL)
      - warrenm 4y ago
        I think I've explained that above - it's not having to be rigidly tied to a schema :)