4 ms·

On the contrary, a model that is solid enough that you can continue to improve and build features on it for decades without changing the fundamentals is an extr

by wrs 8y ago

On the contrary, a model that is solid enough that you can continue to improve and build features on it for decades without changing the fundamentals is an extremely rare triumph in this industry. The signal that “something is wrong” is that you have to reinvent the foundation every five years (e.g., the tottering stack of false starts inside all web browsers).

Latteland 8y ago
sql has stood the test of time, but we've also figured out how to extend the sql dbs and relational model so that it works efficiently in a lot more scenarios. there are column stores that do incredible compression, in-memory row stores, you can put json in a sql database and efficiently query it.
weberc2 8y ago
Features aren’t being “built on it”, they’re being bolted on because the model is insufficiency powerful, which is my point. To be clear, relational databases are great and important, but the relational model will have to be replaced.
- nl 8y ago
  There are two issues I know of with SQL where it isn't super great IMHO. 1) Hierarchical data. The relational model is fine here, but the query syntax isn't awesome. 2) Understanding remote data. This is outside the scope of the data model, but it does effect the way software is built. Neither of these show any evidence that the relational model should be replaced.
  - naasking 8y ago
    > There are two issues I know of with SQL where it isn't super great IMHO. There are many more issues, you've just gotten used to eating SQL turds. Hierarchical data is solved by CTEs, so that's not a big deal. The bigger deal is that relations themselves are impoverished second-class citizens. This means you can't write a query, bind it to a variable and then reuse that query to build another query or store that query in a table column. Something like: var firstQuery = select * from Foo where ... var compositeQuery = select * from firstQuery where ... create table StoredQuery(id int not null primary key, query relation) insert into StoredQuery values (0, firstQuery) That's something like relations as first-class values. This replaces at least 3 distinct concepts in SQL: views, CTEs, and temporary tables, all of which were added to address SQL's expressiveness limitations. Relations as first-class values not only improve the expressiveness of SQL beyond those 3 constructs, it would also solve many annoying domain problems that require a lot of boilerplate at the moment. Then there's pervasive NULL, inconsistent function and value semantics across implementations, and a few other issues.
    - TimJYoung 8y ago
      The schema aspects of this idea are hard for me to grasp. How would the database engine efficiently resolve any references to the embedded relation ? I'm also having trouble understanding how your INSERT statement would even work - is the firstQuery being inserted being treated as hierarchical data where every single relation attached to every single row has its own schema/structure ? Or is the structure fixed in the CREATE TABLE statement so that you can't use just any relation, but rather have to use a relation that conforms to the structure defined in the CREATE TABLE statement ?
      - naasking 8y ago
        I played a little fast and loose to convey the basic idea. To elaborate since you asked, introduce typed tuples/records as first-class entities, then "tables" are just a sequence of records declared with a particular lifetime. Relations are functions over these sequences. The embedded relation is then a stored function over a set of nested sequences. So to add the concrete types: var firstQuery = select Id, Name, Payment from Foo where ... var compositeQuery = select Id, Name, Total from firstQuery where ... create table StoredQuery(id int not null primary key, query relation{Id int, Name Text, Payment decimal}) insert into StoredQuery values (0, firstQuery) Again eliding a few details, but hopefully you get the basic idea.
        Izkata 8y ago
        This particular use case sounds like a MATERIALIZED VIEW, and views in general for doing what you're asking for...
        naasking 8y ago
        A materialized view would be an optimization technique used when compiling a schema containing first-class relations (essentially, memoization). First-class relations are more general though. But first-class relations would also present some optimization challenges, so a subset of a relational system with a restricted form of first-class relations corresponding to materialized views that can be stored in table columns and used in queries would get pretty close.

by wrs 8y ago

Latteland 8y ago

sql has stood the test of time, but we've also figured out how to extend the sql dbs and relational model so that it works efficiently in a lot more scenarios. there are column stores that do incredible compression, in-memory row stores, you can put json in a sql database and efficiently query it.

weberc2 8y ago

Features aren’t being “built on it”, they’re being bolted on because the model is insufficiency powerful, which is my point. To be clear, relational databases are great and important, but the relational model will have to be replaced.

nl 8y ago
There are two issues I know of with SQL where it isn't super great IMHO. 1) Hierarchical data. The relational model is fine here, but the query syntax isn't awesome. 2) Understanding remote data. This is outside the scope of the data model, but it does effect the way software is built. Neither of these show any evidence that the relational model should be replaced.
- naasking 8y ago
  > There are two issues I know of with SQL where it isn't super great IMHO. There are many more issues, you've just gotten used to eating SQL turds. Hierarchical data is solved by CTEs, so that's not a big deal. The bigger deal is that relations themselves are impoverished second-class citizens. This means you can't write a query, bind it to a variable and then reuse that query to build another query or store that query in a table column. Something like: var firstQuery = select * from Foo where ... var compositeQuery = select * from firstQuery where ... create table StoredQuery(id int not null primary key, query relation) insert into StoredQuery values (0, firstQuery) That's something like relations as first-class values. This replaces at least 3 distinct concepts in SQL: views, CTEs, and temporary tables, all of which were added to address SQL's expressiveness limitations. Relations as first-class values not only improve the expressiveness of SQL beyond those 3 constructs, it would also solve many annoying domain problems that require a lot of boilerplate at the moment. Then there's pervasive NULL, inconsistent function and value semantics across implementations, and a few other issues.
  - TimJYoung 8y ago
    The schema aspects of this idea are hard for me to grasp. How would the database engine efficiently resolve any references to the embedded relation ? I'm also having trouble understanding how your INSERT statement would even work - is the firstQuery being inserted being treated as hierarchical data where every single relation attached to every single row has its own schema/structure ? Or is the structure fixed in the CREATE TABLE statement so that you can't use just any relation, but rather have to use a relation that conforms to the structure defined in the CREATE TABLE statement ?
    - naasking 8y ago
      I played a little fast and loose to convey the basic idea. To elaborate since you asked, introduce typed tuples/records as first-class entities, then "tables" are just a sequence of records declared with a particular lifetime. Relations are functions over these sequences. The embedded relation is then a stored function over a set of nested sequences. So to add the concrete types: var firstQuery = select Id, Name, Payment from Foo where ... var compositeQuery = select Id, Name, Total from firstQuery where ... create table StoredQuery(id int not null primary key, query relation{Id int, Name Text, Payment decimal}) insert into StoredQuery values (0, firstQuery) Again eliding a few details, but hopefully you get the basic idea.
      - Izkata 8y ago
        This particular use case sounds like a MATERIALIZED VIEW, and views in general for doing what you're asking for...
        naasking 8y ago
        A materialized view would be an optimization technique used when compiling a schema containing first-class relations (essentially, memoization). First-class relations are more general though. But first-class relations would also present some optimization challenges, so a subset of a relational system with a restricted form of first-class relations corresponding to materialized views that can be stored in table columns and used in queries would get pretty close.