[HN Gopher] Feature Casualties of Large Databases
       ___________________________________________________________________
        
       Feature Casualties of Large Databases
        
       Author : craigkerstiens
       Score  : 14 points
       Date   : 2020-12-01 21:24 UTC (1 hours ago)
        
 (HTM) web link (brandur.org)
 (TXT) w3m dump (brandur.org)
        
       | abraae wrote:
       | Yeah, no shit, it's hard to get things like referential integrity
       | and transactions working at scale, it takes many genius engineers
       | and many years.
       | 
       | A better title would be:
       | 
       | Feature Casualties of Large Databases (except for old-fashioned
       | databases like Oracle, DB2 etc. that have been doing this stuff
       | at huge scale for decades).
        
       | xyzzy_plugh wrote:
       | > SQL is the most expressive language ever for querying and
       | manipulating data, and in the right hands, that power can make
       | hard things easy.
       | 
       | ... what? _The_ most expressive language _ever_?? You 're
       | kidding.
       | 
       | Python? Scala? R? Julia? Java? Rust??
       | 
       | I mean, SQL is fine and all, and folks keep trying to unseat it
       | which I feel is folly but to call it the most expressive
       | language... Not even close.
       | 
       | SQL is rigid and structured. Basic math and string operations are
       | frustrating at best. It's a small, easy to learn and powerful
       | language. But it's far from expressive.
        
         | brandur wrote:
         | (Author here.) I think you're confusing a couple different
         | major classes of languages -- declarative versus procedural. I
         | said specifically "most express ever _for querying and
         | manipulating data_ ", and I'd stand by that.
         | 
         | The nice part about SQL compared to the languages you've cited
         | is that you just need to specify the "what" and not the "how".
         | I tell it what data to fetch, where I want it from, how I
         | wanted it grouped/sorted (etc.), and the engine figures out the
         | best (and probably a very efficient) way to do that. This is
         | different from a procedural language like Python or Rust where
         | it'd be on me to also define the implementation details as well
         | (get data from here, join by doing this and with this
         | algorithm, sort what comes out, ...).
         | 
         | This gives SQL a number of very nice properties:
         | 
         | * It's very fast and succinct to write.
         | 
         | * Even very complex queries are likely to be executed as
         | optimally as they can be (because database engines tend to be
         | very good at this).
         | 
         | * It's so high-level that it can actually get more performant
         | over time. See for example Postgres 12, which eliminated an
         | optimization fence for CTEs (common table expressions) [1],
         | which means that a lot of queries got faster automatically,
         | without the user having to do _anything_.
         | 
         | I love a lot the languages you listed, but SQL is a different
         | animal, and amazing in a way that's quite unique.
         | 
         | ---
         | 
         | [1] https://info.crunchydata.com/blog/with-queries-present-
         | futur...
        
         | heelix wrote:
         | You can call Java from Oracle's PSQL, so that makes it a super
         | set including Java, right? :P (I've done things I'm ashamed of)
        
       ___________________________________________________________________
       (page generated 2020-12-01 23:01 UTC)