4 ms·

Why is this better than just using any SQL database? Also, considering that only in-memory storage is shipped here, is this an internal Google project that was

• dragonwriter 11y ago
  > Why is this better than just using any SQL database? Lots of SQL databases don't have good constructs for dealing with ranges, which make lots of operations you'd want to do with temporal data awkward (PostgreSQL since 9.2 has range types, and lots of useful features attached to them, that address this.) Beyond that, pretty much all the normal SQL vs. NoSQL considerations would seem to apply without much change when you address temporal data, so the usual mix of ACID vs. scalability, schema enforcement vs. schemaless flexibility, etc., considerations apply.
• JPKab 11y ago
  It's a triple store that doesn't suck. If you want to know the advantages of triple stores, there's a lot out there. One key strength is that triple stores have a "schema as data" approach, meaning that schemas can be made to follow rules on the fly based on the data contained within them. Nothing that application code can't do, of course, but the entire purpose of these kinds of databases is to find a way to have data be as self-descriptive as possible.
  • dragonwriter 11y ago
    > One key strength is that triple stores have a "schema as data" approach Schema as data is historically a fairly important element of the relational model.
    • BinaryIdiot 11y ago
      > Schema as data is historically a fairly important element of the relational model. Not really. You derive a schema from data already stored in a relational database by looking at multiple, non-data places. I'm not sure I would necessarily consider that "schema as data" especially since many of the things you would need to automatically derive a schema may not be present in an optimally performing RDMS. For instance you need foreign keys to understand relationships but I've seen many times where performance is improved through handling foreign key integrity through the application versus at the database level.
      • maaku 11y ago
        Many (most? all?) traditional relational database management systems have table schemas specified as "control tables" within the database itself. I think this is what the parent was referring to.
      • dragonwriter 11y ago
        > You derive a schema from data already stored in a relational database by looking at multiple, non-data places. No, the schema is itself stored in tables; conceptually, while the structure of those control tables needs to be immutable (that is, the data in the control tables that also relates to the control tables needs to be protected against modification), in an ideal DB following the model, schema changes that can be done through DDL are logically equivalent to executing DML against the control tables and can be done that way, as well; in practice, several RDBMS's do allow this, though typically they only allow superusers to use DML against system tables, even though normal users may have permission to make equivalent changes through DDL.
        • BinaryIdiot 11y ago
          Fair enough but when you consider internal structures as "data" I think the phrases loses some of its power; you could effectively make this argument about any type of meta data system at that point.
• gtrubetskoy 11y ago
  Triplestores are good for storing and processing graphs, which don't fit the relational database model very well. There is a variant of SQL called SPARQL intended specifically for querying triplestores: https://en.wikipedia.org/wiki/SPARQL https://en.wikipedia.org/wiki/SPARQL
• xllora 11y ago
  BW author here. Work in progress.