• -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.

  • Duke of New York (unregistered)

    So the initial WTF here is that … the code is modular? I’ve been on a project where the prior devs coded each business operation as one big normal-form statement with much duplication and obscurity of intent.

  • (nodebb)

    Once you start adding a fair number of views, there's always the temptation to add Yet One More View; ultimately, you get four different versions of exactly the same SELECT statement, with different people using different ones.

    The only real solution, of course, is to have the One 10X Programmer To Rule Them All, who keeps every aspect of the DB in their head, and enforces their will upon the huddled masses of DBAs with an iron fist of PR reviews.

    Addendum 2024-11-26 12:23: (Or a good naming scheme, but who has time to make one of those?)

  • (nodebb)

    who have had been

    Ow, my helping verb.

  • Duke of New York (unregistered) in reply to PotatoEngineer

    Sure, you can end up with duplicate views, but that's easier to fix than subexpressions that aren't broken out at all.

  • (nodebb)

    There was a time you couldn't use GETDATE() in MSSQL user-defined functions. Creating a view that returned GETDATE() got around that limitation. It had problems, but worked for most situations.

  • enkorvaks (unregistered) in reply to SupportTillIDie

    I really hope that you mean 50 megabits (a little over 6 megabytes), but somehow I doubt it.

    Even 6 megabytes is somewhat obscene for a text representation for a query, 50 is utterly outrageous.

  • löchlein deluxe (unregistered) in reply to -to-

    :giggle:

    Nope. Remember the old motto: "Bugs are deviations of reality from the specs. No specs, no bugs." The customers will only give you one spec now, that it works like it always has.

  • (nodebb)

    Normal views (I'm not getting into materialized ones here, that's a whole other bag of bees) are basically macros like #define in C/C++. So all they do is creating overhead for the execution plan generator. This feature was one of many to make a DB more human accessible, they really have no place in machine-machine interactions cause they were simply not created/designed for that purpose.

  • SupportTillIDie (unregistered) in reply to enkorvaks

    I did indeed mean Megabytes. or Mebibytes, possibly, but you get the drift.

    And Yes, it was outrageous

  • Erwin (unregistered) in reply to löchlein deluxe

    ... that it works like it always has, but faster!

  • Duke of New York (unregistered) in reply to MaxiTB

    "Overhead" over what? That's what the execution planner is for.

    While there might have been other ways to generate the report than with 100% SQL, my working assumption about a reporting system with "19 layers of complex and non-obvious abstraction" is that those layers serve the requirements of the report until it is shown otherwise.

    I struggle to assign any meaning to "complex and non-obvious" here other than that the developer was afraid to read the code placed in front of him.

  • LZ79LRU (unregistered)

    I would propose that the meaning in question is:

    Code that is very complicated and full of various idiosyncrasies which are either the result of bad programming, bad design or both but could equally just be specific unique special case features genuinely needed somewhere non obvious.

    However, because the code is used and reused in many places around the system and nobody bothered to do proper modularization it is now so bloated with genuine unique special cases and bugs alike that the only way to tell the difference between the two is to do a static code analysis of the entire thing and basically reverse engineer the entire system complete with diagrams.

    You can tell I've been there.

Leave a comment on “Hall of Mirrors”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article