• -to- (unregistered)

    Od course the first thing to do would be to add some regression testing so you can try to simplify while keeping functionality.

  • Hanzito (unregistered)

    Just spool up another one of those ml.r5.largex24 instances.

  • Jaloopa (unregistered)

    I used to work at a place where this was common practice. I don't think the view nesting ever got as far as 19 but I found more than a few that were over 10. I achieved some decent speed ups by replacing calls to the views with simplified ones that called the tables directly and avoided tables that weren't ever used in what I was querying. Unfortunately, I also discovered while doing that that some versions of the software we integrated with threw a fit if you used schemas other than dbo, leading to a very embarrassing rollback script to put my new views back in dbo

  • (nodebb)

    The first C++ app (MacOS, 1995) I ever saw at an employer had only a few classes, but each was around 10 subclasses deep, each layer adding and overriding dozens of things; figuring out what any piece of code did took forever.

  • SupportTillIDie (unregistered)

    I'm currently in support for "a data lakehouse" . 100s of levels of nested views. I've seen text representations of the actual underlying queries get up to 50Mb...

  • Argle (unregistered)

    [sigh] And I felt such guilt the time when I realized the simplest and cleanest solution to something I was doing was a second layer view. I still feel guilty.

Leave a comment on “Hall of Mirrors”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article