1. 18

  2. 2

    Oooooh this is good stuff. I would say some of these concepts are swinging back into the center after the whole idea of “throwing out” modeling for schema on read environments (i.e. most of NoSQL), or have morphed into other areas outside of just the database and are just reflected downwards. See anything related to canonical models for talking between microservices or Business/Behavior Driven Development.

    Also of note is that a lot of this still applies to data warehousing, where it’s still relational on a much bigger scale. The major change there has more do with trying to make the model a little more flexible so we can move away from the more waterfall oriented approach, in the same way operational systems (i.e. the back end of your usual software application) already have.

    1. 1

      Triggers are out of favor?

      1. 1

        That surprised me too.

        1. 2

          One of the core tenets of modern development is keeping logic together where it can be modified atomically through deploys (that can be deployed, run in split mode, and reverted), and database triggers have fallen heavily out of use because they struggle to provide these properties.

          The only part of this that triggers don’t necessarily suit very well is the “run in split mode” part. You can certainly deploy and revert triggers via migrations. I guess most people who’re using some A/B testing don’t have that integrated with their DB, so maybe that’s the concern: it’s hard to conditionally activate a trigger (is it?).

          I also think the author may be overestimating how many products are doing that degree of split testing, and the extent to which that testing really impacts upon the use of triggers.