Bet Against SQL: Queries as Code by James Cowling & Sujay Jayakar

แชร์
ฝัง
  • เผยแพร่เมื่อ 24 พ.ย. 2024

ความคิดเห็น • 31

  • @keokawasaki7833
    @keokawasaki7833 2 หลายเดือนก่อน +36

    The intro theme doesn't need to go this hard

  • @NostraDavid2
    @NostraDavid2 2 หลายเดือนก่อน +6

    RE: Andy Pavlo
    Carnegie Mellon University has an _excellent_ freely available database course, presented by Andy BTW.
    "CMU Intro to Database Systems", here on YT.

    • @mattayes
      @mattayes หลายเดือนก่อน

      💯 Intro and Advanced Database Systems are great. Andy and the rest of the CMU Database Group does such a great job.

  • @NostraDavid2
    @NostraDavid2 2 หลายเดือนก่อน +8

    I can't have you disrespecting The Coddfather (E. F. Codd) like that! The Relational Model was invented in 1969 (nice!) in a paper called "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", and took off in the second paper called "A Relational Model of Data for Large Shared Data Banks" in 1970.
    He also designed ALPHA in his paper "ALPHA: A Data Base Sublanguage Founded on the Relational Calculus", an unimplemented language that was based on Relational Calculus that could've been used to query data, instead of SQL, but alas. Oracle took SQL as basis and IBM had to follow suit if not to lose market share to Oracle, as the Relational Model was VASTLY superior to existing data types (trees and networks) that were being abused as databases - they were not even official models yet - The Relational Model predates whatever models IMS and IDS later on generated.
    There. Now I'm much more content.

    • @NostraDavid2
      @NostraDavid2 2 หลายเดือนก่อน

      If you wish to check out all his papers (ordered in release date): thaumatorium dot com/articles/the-papers-of-ef-the-coddfather-codd/

    • @NostraDavid2
      @NostraDavid2 2 หลายเดือนก่อน

      No ads, nor tracking on Thaumatorium BTW.

    • @JamesCowling
      @JamesCowling 2 หลายเดือนก่อน +3

      You won't find us taking Codd's name in vain over here! As far as abstractions go the RDBMS is one of the all-time greats. Transactions, relations, type safety and consistency are evergreen and will hopefully long outlive SQL.

  • @trejohnson7677
    @trejohnson7677 2 หลายเดือนก่อน +1

    this truly conveys that idea that databases are literally just shared space.

  • @kellymoses8566
    @kellymoses8566 2 หลายเดือนก่อน +4

    Datalog is a fantastic query language.

  • @jaybny
    @jaybny หลายเดือนก่อน

    Conversational transactions == State
    the problem is micro services sold to masses - that's the bad abstraction

  • @YuFanLou
    @YuFanLou 2 หลายเดือนก่อน +2

    10:59 I think SQL being a *query* language, it is maybe unfair to start off judging it with “hard to express application *behavior*”. It’s like judging a cake for not being savory. The fact that so many have been abusing SQL, which is designed to query for current time snapshot, to write time-varying behavior instead, is a testament to how good an abstraction it is at querying that it forces systems around it to conform to its shape.

    • @YuFanLou
      @YuFanLou 2 หลายเดือนก่อน

      24:12 The point about performance predictability is cool, but this code example really does not show any superiority over SQL other than integrating with host language error reporting. The point is supposed to be something better than conversational transaction, but then it goes off into side effect management. Where is the demo for rolling back?

    • @maksimmuruev423
      @maksimmuruev423 2 หลายเดือนก่อน

      Sql when you should put flat number before house.. this is not good for autocomplete and not intuitive.. general idea was use it by accountant.. but they wasn't happy with this instead devs are struggling.

  • @thelinuxlich
    @thelinuxlich หลายเดือนก่อน

    This makes me think of the RethinkDB query language with explicit index range.

  • @NostraDavid2
    @NostraDavid2 2 หลายเดือนก่อน +1

    Current Relational Databases also completely ignore the concept of a sharable Domain; some DBs have them, but nobody is using them or teaching them either.
    For simplicity's sake think of a Domain as a datatype with extra constraints (either a subselection of specific values, or perhaps a range), that can be shared between columns (Column A from table X can have the same domain as column B from table Y).

    • @TapetBart
      @TapetBart 2 หลายเดือนก่อน

      Clickhouse has something called Domains. I wonder kf that is the same.

  • @MartinCharles
    @MartinCharles 2 หลายเดือนก่อน

    This is all true for transactional workloads

    • @MartinCharles
      @MartinCharles 2 หลายเดือนก่อน

      This talk really glosses over a bunch of important details

  • @pookiepats
    @pookiepats 15 วันที่ผ่านมา

    heresy! boo hsss

  • @jaybny
    @jaybny หลายเดือนก่อน

    12 minutes in. so far nothing was said.

  • @NostraDavid2
    @NostraDavid2 2 หลายเดือนก่อน +4

    SQL is indeed a terrible language. I hope that in the next Stack Overflow Survey they'll introduce a separate "Query Language" question, instead of slapping SQL between regular programming languages.
    BTW, it's terrible because a Relational Query Language should ALWAYS return a Relation (a set of tuples), but SQL can return a table, a row, a column or a cell, which is kind of awful.

    • @YuFanLou
      @YuFanLou 2 หลายเดือนก่อน +1

      but all of table, row, column, cell are indeed relations! lol
      I’ve come to accept that pragmatic QoL is a valid trade-off against conceptual simplicity
      speaking of relational language been looking at Alloy, albeit for modeling not querying

  • @kellymoses8566
    @kellymoses8566 2 หลายเดือนก่อน +6

    Git is a example of terrible abstractions.

    • @mattmurphy7030
      @mattmurphy7030 2 หลายเดือนก่อน +8

      Explain?

    • @r.g.thesecond
      @r.g.thesecond 2 หลายเดือนก่อน +3

      @@mattmurphy7030 Well, perhaps the Git CLI. Its verbs don't help at all until you learn the underlying structure and use gitk a couple of times.