Are the posted questions getting worse?

  • I'm up to TimeStamp 00:40:00 in 'tube that Steve Collins just posted.  The speaker, Adam Ralph, is doing a great job (well, except for using a laser pointer to point at the screen, which is a huge "Boz0-No-No" 🙁 ).  His methodology for the solving the problem is spot on.

    One of the issues that I've seen is what he explains at 33:04.  Just prior to that, he explains how MSMQ and SQL Server does a great job but then explains that MSMQ is no longer supported by MS.  And, with that, he went to another product (to replace MSMQ, not SQL Server) other than an MS product.  How long before that's "no longer supported" in favor of a newer, shinier stone?  I went through that when I was a Develop more than 2 decades ago and it happens on a regular basis and I don't know how it is that Developers don't actually lose their minds in that fray.

    In other words, someone stopped making a critical part to the "futuristic hover car". 😉

    Then you have folks that don't really understand how SQL Server works and they'll try something like {gasp!} sp_GetAppLock (like a fellow did for one of the companies that I do work for) and, man!  Blocking to the max with bunch of CPUs doing nothing but waiting.  Lordy.  And, remember, even Adam Ralph's method hit the database and had to wait for a failure and then do a retry of the message.

    I'll also say that while he has eliminated the "Batch Job", which I agree is highly inappropriate to use in the scenario that he's portraying, there's still something running all the bloody time to check on orders that are older than a week to have them update the "current balance" of orders in that have occurred in the last 7 days.

    I believe that the "forward looking" nature could be fairly easily duplicated in T-SQL but I'm not sure that's the best method because processing is being done for customers that may never order again.  A complete waste of clock cycles.

    I believe this can be done in an easier and less computationally intensive method using a "winged Mach 2 dinosaur" but I have almost no bandwidth for the next couple of weeks to prove it with code.  It's the proof that takes the time, not so much the code.  It's a bit like writing a presentation of the same good quality that Adam Ralph did on the methods he spoke of.

    And, again, I really enjoyed listening to Adam Ralph on this subject.  He did a great job.  I intend to finish the 'tube during a "break" in the other things I'm doing because he's getting ready to solve "reporting issues", which I'm actually speaking on at the Ohio North SQL Saturday 2023 this coming Saturday (20 May 2023).

    And, yes... he's using the right tools... they're just not the only tools and there are tools that are never going to "go away" like how MSMQ has.

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Dennis Jensen wrote:

    Jeff Moden I did try to outline that in context. I was saying I have actually seen this before with a dynotopic language (aka Cobol) where the powers to be were not biting the bullet and moving to a better language but they were instead trying to make their dynotopic language more relevant. Which if you have ever coded in Cobol you will know that is next to impossible, which means expending at least 5 times the effort that it would take to change to a more viable language and still not guarantee you have a quality solution.

    Further I was not saying someone was promising a futuristic hover car but that one (if not many) actually already existed and were being used.  However, these archaic thinkers could not give up what they were using and embrace the futuristic change but felt it was worth wasting resources to great a dynotopic solution which of course is going to fall significantly short of these futuristic hover cars.

    Heh... there ya go again. 😉  You reworded it but your basically saying the same thing. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Deleting the duplicate post I made because of the "first post" syndrome.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Deleting the duplicate post I made because of the "first post" syndrome. 🙁

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden wrote:

    Heh... there ya go again. 😉  You reworded it but your basically saying the same thing. 😉

    Uh yes that was the point to reword what I had intially said because it had seemingly been misconstrued, which is what one should do as a communicator when the communicatees have not seemed to grasp what it was you were trying to say.

    So that brings us to, what is your point about me having reworded it.  What do you feel is wrong with what I have said. Perhaps you might want to reword your objection, assuming you have an objection.

    • This reply was modified 10 months, 2 weeks ago by  Dennis Jensen. Reason: fix typo
  • Dennis Jensen wrote:

    Jeff Moden wrote:

    Heh... there ya go again. 😉  You reworded it but your basically saying the same thing. 😉

    Uh yes that was the point to reword what I had intially said because it had seemingly been misconstrued, which is what one should do as a communicator when the communicatees have not seemed to grasp what it was you were trying to say.

    So that brings us to, what is your point about me having reworded it.  What do you feel is wrong with what I have said. Perhaps you might want to reword your objection, assuming you have an objection.

    Just to ask the question, are you referring to Steve Collin's post?

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • The link Steve Collins posted is interesting. Got through it, and while I don't quite agree that stored procs create a strangler pattern, I do think in the high concurrency situation he's working, you really do need messaging. This is how Amazon does things. Once in awhile you'll actually find the order you placed isn't in your orders because the messages are bottlenecked somewhere.

    It's interesting, and I'm glad I don't have to solve those problems. I especially wouldn't love the business conversation trying to explain a sliding week window vs a calendar window to a business person.

  • Jeff Moden wrote:

    Just to ask the question, are you referring to Steve Collin's post? 

    No this was not in response to Steve Collin's post it was in response to your post #4192760 which was in response to my post #4192719 which was a response to your post #4192711.  I hope that sorts it all out for you.

  • As you said, I'm making sure of clarity. 🙂

    With that, I'll say that you've just repeated yourself.  You're insisting that SQL is a dinosaur here and the its technology is archaic and your comparison to a problem with people on Cobol suggests that you feel that same way about the people that insist SQL would be good for the same thing in Adam Ralph's good 'tube covered.

    Have you considered that the futuristic hover car that's being portrayed might actually be the archaic thing?  That's a rhetorical question, for sure, because it's obvious that you have not and don't understand how it could be. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • No Jeff Moden I did not state that SQL was a dinosaur at all, I think I basically referred to others doing so with dynotopic languages such as Cobol. I never combined the dynotopic prehistoric concept in regards to SQL and I apologise if that was the take away you got from my statement as that means I did not communicate well what I was trying to state.

    Further the key is not that I do not understand (because I absolutely do) but that you did not fully comprehend what I was trying to communicate which again is not your fault as the fault with poor communication falls fully upon the communicator not the communicatee. I hope my statement here helps to clarify the point I was making if not please let me know I will try again.

    • This reply was modified 10 months, 1 week ago by  Dennis Jensen.
  • Dennis Jensen wrote:

    No Jeff Moden I did not state that SQL was a dinosaur at all, I think I basically referred to others doing so with dynotopic languages such as Cobol. I never combined the dynotopic concept in regards to SQL and I apologise if that was the take away you got from my statement as that means I did not communicate well what I was trying to state.

    Further the key is not that I do not understand (because I absolutely do) but that you did not fully comprehend what I was trying to communicate which again is not your fault as the fault with poor communication falls fully upon the communicator not the communicatee. I hope my statement here helps to clarify the point I was making if not please let me know I will try again.

    While Dynotopia is a film and a video game, the word dynotopic does not exist in any dictionary I can find.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Steve Jones - SSC Editor wrote:

    The link Steve Collins posted is interesting. Got through it, and while I don't quite agree that stored procs create a strangler pattern, I do think in the high concurrency situation he's working, you really do need messaging. This is how Amazon does things. Once in awhile you'll actually find the order you placed isn't in your orders because the messages are bottlenecked somewhere.

    It's interesting, and I'm glad I don't have to solve those problems. I especially wouldn't love the business conversation trying to explain a sliding week window vs a calendar window to a business person.

    It's interesting to me how the SQL based solution which worked in development suddenly produced errors in production.  At that point, at a minimum, he should've made a service call to Microsoft support.  Without knowing all the technical details of the exact situation tho it's just speculation.  I get what Jeff is saying too, unless I'm ready with an alternative it's not really fair to criticize a solution which works.  To my way of thinking future messaging, or undoing transactions a week or month in the future, creates new and bigger headaches more than it solves old ones

     

    Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können

  • Well, Phil Parkin just because a word does not currently exist within any known dictionary does not mean it is not a viable word. In fact, Shakespeare is credited with creating 1700 words and there are many others that created words of their own that later found their way into the official dictionaries. The question is did you understand at least kind of what I was saying (in context) with that non-official word? If yes, then it served its purpose.

    Thinking outside the box is part of the reason I can solve problems fairly quickly as I use approaches that are not always predefined.

    • This reply was modified 10 months, 1 week ago by  Dennis Jensen.
  • My impression wasn't that the SQL thing caused errors, but that it was a pattern they didn't like for development. I could see potential deadlocks in a high concurrency environment, though I suspect the issues are more that they didn't structure the SQL correctly.

    However, like you, I'm loathe to criticize too much since I didn't see the system, errors, or effects.

  • Dennis Jensen wrote:

    No Jeff Moden I did not state that SQL was a dinosaur at all, I think I basically referred to others doing so with dynotopic languages such as Cobol. I never combined the dynotopic concept in regards to SQL and I apologise if that was the take away you got from my statement as that means I did not communicate well what I was trying to state.

    Further the key is not that I do not understand (because I absolutely do) but that you did not fully comprehend what I was trying to communicate which again is not your fault as the fault with poor communication falls fully upon the communicator not the communicatee. I hope my statement here helps to clarify the point I was making if not please let me know I will try again.

    So tell me that this sarcastic remark has nothing to do with SQL, which was the subject at hand.  And then tell me what your were referring to as a "dinosaur" when you said "build a better dinosaur".

    Dennis Jensen wrote:

    Yes, why would anyone want to use that complicated futuristic hover car when we can spend 10 times the amount of resources to build a better dinosaur. I mean, then we will still have the dinosaur and its simplicity.  Yeah it is a bit slower by maybe uh a meer 75% and it has a lot of waste by product where the hover car has no emissions but hey its still a better solution because its the dinosaur we know.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 15 posts - 66,331 through 66,345 (of 66,536 total)

You must be logged in to reply to this topic. Login to reply