7 ms·

Well, sort of. Every decade it bolts on support for the new technology craze, and usually that proves insufficient so vendors add their own features, and even t

Well, sort of. Every decade it bolts on support for the new technology craze, and usually that proves insufficient so vendors add their own features, and even that tends to be pretty painful. Definitely a useful skill set but it’s still pretty painful.

tomnipotent 8y ago
> Every decade it bolts on support for the new technology craze You mean they got better? I've been using Postgres, MySQL, and SQL Server professionally for over 20 years (Postgres for only 15), but they've only become better & faster over time. I don't see this "technology craze" you mention, but I have seen things like parallel processing, bitmap indexes, selective indexes, query plans that use multiple indexes, online index creation (no locking), support for complex data types like JSON or XML, partitioning, vastly improved resource usage (CPU+memory+disk) just to name a few. This doesn't even include some of the cool vendor-specific features like foreign data wrappers (FDW) in Postgres, embedded language runtime support (SQL Server can do .NET, Python, R) and so on. > so vendors add their own features Of course they do, RDBMS' are products.
- weberc2 8y ago
  > You mean they got better? Well, I mean they support new features, which is perhaps "better", though when you continue to tack on features for decades, perhaps something was wrong with the relational algebra model to begin with. Also, you're conflating "SQL" with advancements in individual implementations of a relational database. Relational databases are great; I just think we'll find a model that is more suitable for application development than "relational algebra + the kitchen sink".
  - tomnipotent 8y ago
    Good point, I was conflating SQL & RDBMS.
  - 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.
  - smadge 8y ago
    What do you think of perhaps a logical (e.g. Prolog or Datadog) model for databases?
    - weberc2 8y ago
      I’m not familiar with those. What do _you_ think about them? :)
      - smadge 8y ago
        They are what came to mind when you said perhaps the relational algebra was not sufficient as a theoretical model of databases.
- naasking 8y ago
  > I don't see this "technology craze" you mention, but I have seen things like parallel processing, bitmap indexes, selective indexes, query plans that use multiple indexes, online index creation (no locking), support for complex data types like JSON or XML, partitioning, vastly improved resource usage (CPU+memory+disk) just to name a few. Those all seem like pretty ad-hoc features, some of which were influenced by prevailing tech fashion trends at the time. For instance, the fact that you need to manually specify so many details about indices sounds like a failure to have a good theory around indexing which can be integrated into query plans. There are a lot of flaws like this in SQL stores as a whole.
  - MaxBarraclough 8y ago
    How are they 'ad-hoc'? With the exceptions of JSON and XML support (cf. the 'NoSQL' fad), they're all valuable enhancements to core functionalities, no? > the fact that you need to manually specify so many details about indices sounds like a failure to have a good theory around indexing which can be integrated into query plans I'm no SQL guru, but this smacks of a variant on the 'sufficiently smart compiler fallacy' to me. That the system can't always, uh, optimally optimise, isn't necessarily an indication that the system is fundamentally flawed. GCC permits inline assembly, but that doesn't mean GCC is a failure.
    - Retra 8y ago
      If GCC required inline assembly everywhere, it would definitely be a failure.
      - MaxBarraclough 8y ago
        Of course. Given that this feature was added to the DBMS pretty late in the game, we can infer that it's only rarely worthwhile.
    - naasking 8y ago
      See my other comment [1] if you want further details as to SQL's limitations. [1] https://news.ycombinator.com/item?id=18147388 https://news.ycombinator.com/item?id=18147388

tomnipotent 8y ago

> Every decade it bolts on support for the new technology craze You mean they got better? I've been using Postgres, MySQL, and SQL Server professionally for over 20 years (Postgres for only 15), but they've only become better & faster over time. I don't see this "technology craze" you mention, but I have seen things like parallel processing, bitmap indexes, selective indexes, query plans that use multiple indexes, online index creation (no locking), support for complex data types like JSON or XML, partitioning, vastly improved resource usage (CPU+memory+disk) just to name a few. This doesn't even include some of the cool vendor-specific features like foreign data wrappers (FDW) in Postgres, embedded language runtime support (SQL Server can do .NET, Python, R) and so on. > so vendors add their own features Of course they do, RDBMS' are products.

weberc2 8y ago
> You mean they got better? Well, I mean they support new features, which is perhaps "better", though when you continue to tack on features for decades, perhaps something was wrong with the relational algebra model to begin with. Also, you're conflating "SQL" with advancements in individual implementations of a relational database. Relational databases are great; I just think we'll find a model that is more suitable for application development than "relational algebra + the kitchen sink".
- tomnipotent 8y ago
  Good point, I was conflating SQL & RDBMS.
- 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.
- smadge 8y ago
  What do you think of perhaps a logical (e.g. Prolog or Datadog) model for databases?
  - weberc2 8y ago
    I’m not familiar with those. What do _you_ think about them? :)
    - smadge 8y ago
      They are what came to mind when you said perhaps the relational algebra was not sufficient as a theoretical model of databases.
naasking 8y ago
> I don't see this "technology craze" you mention, but I have seen things like parallel processing, bitmap indexes, selective indexes, query plans that use multiple indexes, online index creation (no locking), support for complex data types like JSON or XML, partitioning, vastly improved resource usage (CPU+memory+disk) just to name a few. Those all seem like pretty ad-hoc features, some of which were influenced by prevailing tech fashion trends at the time. For instance, the fact that you need to manually specify so many details about indices sounds like a failure to have a good theory around indexing which can be integrated into query plans. There are a lot of flaws like this in SQL stores as a whole.
- MaxBarraclough 8y ago
  How are they 'ad-hoc'? With the exceptions of JSON and XML support (cf. the 'NoSQL' fad), they're all valuable enhancements to core functionalities, no? > the fact that you need to manually specify so many details about indices sounds like a failure to have a good theory around indexing which can be integrated into query plans I'm no SQL guru, but this smacks of a variant on the 'sufficiently smart compiler fallacy' to me. That the system can't always, uh, optimally optimise, isn't necessarily an indication that the system is fundamentally flawed. GCC permits inline assembly, but that doesn't mean GCC is a failure.
  - Retra 8y ago
    If GCC required inline assembly everywhere, it would definitely be a failure.
    - MaxBarraclough 8y ago
      Of course. Given that this feature was added to the DBMS pretty late in the game, we can infer that it's only rarely worthwhile.
  - naasking 8y ago
    See my other comment [1] if you want further details as to SQL's limitations. [1] https://news.ycombinator.com/item?id=18147388 https://news.ycombinator.com/item?id=18147388