1. 2
  1.  

  2. 1

    Even at that time the lines were beginning to blur, e.g. with HSQLDB, somewhat a precursor to SQLite. Also about that time the downsides of elaborate ORM’s were beginning to be felt. The stage was set for ActiveRecord-like mechanics and even simpler, less magical mechanics. Of course today there are barely any lines at all, an entire spectrum of databases balancing memory and durability. This is a good historical piece from 20 years ago.

    1. 1

      I still feel the effects of these tradeoffs constantly. I shared this because I think it’s not just a historical piece, but a timeless analysis of where to place logic.

      1. 1

        Yeah, agree the tradeoffs continue. I just don’t see the contrast being nearly as sharp as it was 20 years ago.

        1. 1

          I’m legitimately interested - what do you think has changed in that time? I saw you mentioned Active Record. My time with ActiveRecord is one of the reasons why I think this problem is so universal, I didn’t see it providing any solution at all. It just leaned harder into the impedance mismatch between the DB and the programming language.

          1. 1

            ActiveRecord took a few steps in the direction of a compromise between an object model and a relational model. Still a lot of magic. Sequel for Ruby is much simpler and another step toward a blend of the two models. The greater changes over 20 years though are in the hardware cores, memory, caches supporting a much richer breadth of database options, relational, document-oriented, SQL, NoSQL, property graphs, triples, in-memory, various approaches to distribution, synchronization, etc.