4 ms·

There were NoSQL databases well before LDAP was a thing. We called them "Object databases". The idea was that doing object relational mapping was a PITA and w

There were NoSQL databases well before LDAP was a thing. We called them "Object databases". The idea was that doing object relational mapping was a PITA and wouldn't it be better to store your domain objects directly in the database? (As an aside, in case you are curious, the answer is: No. Generally it's not a good idea) Of course if your data is not relational, you can't do SQL. :-)

pjmlp 8y ago
Memories of POET and Gemstone spring to mind...
dragonwriter 8y ago
> Of course if your data is not relational, you can't do SQL. The relational model is, as I understand it, fully general, so this literally cannot be the case. There is a problem of “if you do not know the shape of the data in advance” and “if the RDBMSs available to you do not efficiently handle data of the particular shape and access pattern you are using”, but “relational” isn't an inherent property of data, it's a property of a data model, and any data that can be modelled can be modelled relationally. That doesn't mean it is efficiently handled by every, or any, existing RDBMS, though.
- threeseed 8y ago
  There are plenty of models that don't work well modelled relationally. Few examples here: (1) Wide table with 100K analytical features keyed against a customer. Now if you need to combine a few dozen of these features for predictive purposes then how do you do that in SQL ? You can't. Since every SQL database has a tiny column limit. In Cassandra that is a trivial O(1) fetch. (2) Time series data can be many orders of magnitude faster in JSON document stores where you can have embedded/nested records. (3) Star schema with a fact table and thousands of dimensions. In a SQL database that is thousand joins. In a JSON document store those dimensions can be embedded as well as made available as relations and again that is an O(1) fetch.
  - davidgould 8y ago
    I think you misunderstood the parents use of the term "model". All the things you describe here can be described in the relational model. The parent was arguing that the model is general enough to cover almost all collections of data. You appear to be arguing that for specific use cases specific implementations perform badly. These arguments pass each other unseen like ships in the night.
    - threeseed 8y ago
      Actually wide tables for example can't be done at all. And technically we can use Microsoft Excel as a photo editor. But that's just ridiculous. Just like it's ridiculous to say you can use relational models for any data structure even if the queries will never return.
      - matwood 8y ago
        There may be other limitations, but MSSQL supports[1]: Columns per nonwide table 1,024 Columns per wide table 30,000 I think a lot of this RDBMs can't do X, came from using a MySQL. It has improved some, but was garbage until recently. I'm not sure how wide you're taking about, but PG support up to 1600 depending on the datatypes (there is a page size maximum). Oracle supports 1000 IIRC. [1] https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/sql-server/maximum-capa...
      - Fins 8y ago
        As I recall, MonetDB claims "practically unlimited" number of columns per table. And in this particular use case you're probably looking for an RDBMS specialized in analytics, not a general-purpose one like Postgres. But relational model will handle it certainly better than any other.
      - davidgould 8y ago
        You are still missing the point. The relational model is not about particular implementations. There is no limit on number of columns etc. It is not "ridiculous to say you can use relational models for any data structure", it is the whole point. That particular implementations may not suite your requirements is not a problem of the model, it is a problem of the particular implementations.

pjmlp 8y ago

Memories of POET and Gemstone spring to mind...

dragonwriter 8y ago

> Of course if your data is not relational, you can't do SQL. The relational model is, as I understand it, fully general, so this literally cannot be the case. There is a problem of “if you do not know the shape of the data in advance” and “if the RDBMSs available to you do not efficiently handle data of the particular shape and access pattern you are using”, but “relational” isn't an inherent property of data, it's a property of a data model, and any data that can be modelled can be modelled relationally. That doesn't mean it is efficiently handled by every, or any, existing RDBMS, though.

threeseed 8y ago
There are plenty of models that don't work well modelled relationally. Few examples here: (1) Wide table with 100K analytical features keyed against a customer. Now if you need to combine a few dozen of these features for predictive purposes then how do you do that in SQL ? You can't. Since every SQL database has a tiny column limit. In Cassandra that is a trivial O(1) fetch. (2) Time series data can be many orders of magnitude faster in JSON document stores where you can have embedded/nested records. (3) Star schema with a fact table and thousands of dimensions. In a SQL database that is thousand joins. In a JSON document store those dimensions can be embedded as well as made available as relations and again that is an O(1) fetch.
- davidgould 8y ago
  I think you misunderstood the parents use of the term "model". All the things you describe here can be described in the relational model. The parent was arguing that the model is general enough to cover almost all collections of data. You appear to be arguing that for specific use cases specific implementations perform badly. These arguments pass each other unseen like ships in the night.
  - threeseed 8y ago
    Actually wide tables for example can't be done at all. And technically we can use Microsoft Excel as a photo editor. But that's just ridiculous. Just like it's ridiculous to say you can use relational models for any data structure even if the queries will never return.
    - matwood 8y ago
      There may be other limitations, but MSSQL supports[1]: Columns per nonwide table 1,024 Columns per wide table 30,000 I think a lot of this RDBMs can't do X, came from using a MySQL. It has improved some, but was garbage until recently. I'm not sure how wide you're taking about, but PG support up to 1600 depending on the datatypes (there is a page size maximum). Oracle supports 1000 IIRC. [1] https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/sql-server/maximum-capa...
    - Fins 8y ago
      As I recall, MonetDB claims "practically unlimited" number of columns per table. And in this particular use case you're probably looking for an RDBMS specialized in analytics, not a general-purpose one like Postgres. But relational model will handle it certainly better than any other.
    - davidgould 8y ago
      You are still missing the point. The relational model is not about particular implementations. There is no limit on number of columns etc. It is not "ridiculous to say you can use relational models for any data structure", it is the whole point. That particular implementations may not suite your requirements is not a problem of the model, it is a problem of the particular implementations.