• (nodebb)

    Um. People like the cow-orker should urgently be taken out back and put up in front of the hot end of a GAU-8, and the said chastiser should be turned on for, I dunno, a couple of minutes or until the cow-orker stops moving, whichever is longer.

    Seriously, there is no excuse for not saying, "Oh, there's a weird and funky special sort order that's unrelated to the data. Add a field for that to the database." That's what databases are for, ffs. Storing data.

    Oh, and nobody wants to watch people orking cows.

  • Prime Mover (unregistered)

    "nobody wants to watch people orking cows."

    Speak for yourself.

  • doubtingposter (unregistered) in reply to Steve_The_Cynic

    indeed, don't yuck someone else's yum :D

    also, double negative. there is an excuse for saying that?

  • Tim Ward (unregistered)

    Eh? But if you're forced into using an ORM you just know that pretty well anything you try to do is going to end up as N+1, somehow or other, sooner or later, so why get worked up about this one in particular?

  • (nodebb)

    Frontend developer doesn't understand database. Nothing new here, business as usual.

  • (nodebb) in reply to Tim Ward

    But if you're forced into using an ORM you just know that pretty well anything you try to do is going to end up as N+1

    If your ORM has proper IN support, they can all be 1+1... which scales just fine. When I need to get two sets of related domain objects, I prefer to do two fetches instead of creating a new domain-level class to wrap the results of a JOIN.

  • Cidolfas (unregistered)

    N+1 is definitely a perennial problem with ORMs and Rails specifically. There are a growing number of tools (that have been around since 2012) to deal with it. The question is always how badly do we need to deal with it. If the application is internal and used by a couple of hundred people, delaying display by a few hundred milliseconds might be totally fine and not worth fixing, in particular if there are (as there will definitely be) dozens or hundreds of these little problems scattered around the legacy system.

    Basically they only really need to be fixed once front-end users start noticing the slowdown. Good news is they're usually pretty easy to fix one by one.

  • WTF Relational Mapping Service (unregistered)

    ORMs are definitely a double edged sword. They allow you to write application and data access code quickly and easily without worrying about database details or cross-DB issues. On the other hand, they allow you to quickly and easily do 100 queries when you meant to do one, or stupid outer joins, or other things that make your DBA sad - and sometimes it can be a huge pain to do anything about that.

    My application has a lot of ORM usage (Hibernate) but we also have some SQL in the data access layer where it just wasn't worth the pain of getting an ORM to do what we wanted.

    Customisable sorting of database results is another huge pain, because most databases won't let you put a functional expression in the order by clause. If you can just get all the data and sort in application code that's fine, but that doesn't play nicely with paging and ranged requests.

  • doubtingposter (unregistered) in reply to Cidolfas

    That fits so well with the 'technical debt' point in the other article - If you wait until it's a problem under heavy load, then the program is already a success story. At that point, profits depend on it and it's probably a legacy app to begin with, so now you will probably not be allowed to fix things that are not completely broken. So now you're stuck with it.

  • sizer99 (google)

    | Tenesha’s team works on a legacy Ruby-on-Rails application

    That alone is your proof that they WANT to suffer.

  • (nodebb) in reply to Steve_The_Cynic

    So ... forever then? Most cow-orkers in that position will keep moving for as long as the GAU-8 is running. You might not be able to see much of them after a couple of minutes, though.

  • Yazeran (unregistered)

    Oh my.

    Brings up old memories.. When I did my first database project (some 15 years ago) I was new to databases and had only just read the first three chapters of 'SQL for dummies' so I knew how to do basic select insert etc. Along comes a requirement for stacking objects on plates for positioning in a furnace and they wanted an automatic stacking sequence (reasonable enough) but at the same time you should be able to override said automatic positioning.....

    Well I was new and had made my own little ORM to get all that database connect done away with so I had a function called get_data_SQL() which took an SQL string and returned the data it would produce, guess what I also ended up doing an N+1 when I first had to get a list of proposed positions, and then loop over the items in order to see fi they had any overrides before storing the data....

    I god curious when at first everything worked fine (stacking sequences up to 20), but when I tested for the full production sequences (some hundreds) it suddenly took 20 seconds....

    I fixed that part, but I am still amazed that the system ran in production for 10 years without any major problems considering the high WTF level of that code (I mean I had used VARCHAR's for primary keys for crying out loud)..

  • eric bloedow (unregistered)

    i seem to remember a story...someone made a system that, for some reason, would try to copy the ENTIRE employee database into EVERY company computer EVERY time ANYONE hit ANY KEY ON ANY KEYBOARD...the resulting delay was unnoticeable for a small company with only a dozen employees (like the developer), but for a large company with HUNDREDS or employees, it was unbearable.

  • (nodebb)

    At least the need to impose such a sort order at all was probably not a WTF. (I work with at least one off-the-shelf package that allows for the possibility of jurisdiction B charging tax on not only the original purchase price, but also on the tax that was previously charged by jurisdiction A.)

  • (nodebb)

    IT may not be that bad. If the context of the ORM has already loaded the information, and the settings align, the filter ("where") could actually be dont 100% using the in memory (Cached) content....

  • Barf4Eva (unregistered) in reply to Yazeran

    I'm guessing you meant for your clustered keys, but yeah, that's pretty bad. My favorites are varchar clustered primaries that are actually string representations of incrementing numbers instead of the usual old identity cols. That will do WONDERS for your performance. /s :|

  • DaBytesKeepComin (unregistered)

    You think hundreds of round trips is bad? For fetching a tiny thing? The DB can take it.

    Much worse happens once you've beefed up the DB as far as it'll go and the geniuses have managed to get that to its knees with what you, from the outside, could only conceive must surely be simple queries?

    I may be working in a bad place, but this is barely a mild shrug for me

Leave a comment on “Sort Yourself Out”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article