May 19, 2023 at 3:46 am
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
Change is inevitable... Change for the better is not.
May 19, 2023 at 3:48 am
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
Change is inevitable... Change for the better is not.
May 19, 2023 at 3:50 am
Deleting the duplicate post I made because of the "first post" syndrome.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2023 at 3:52 am
Deleting the duplicate post I made because of the "first post" syndrome. 🙁
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2023 at 4:02 am
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.
May 19, 2023 at 4:33 am
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
Change is inevitable... Change for the better is not.
May 19, 2023 at 7:29 pm
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.
May 20, 2023 at 1:56 am
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.
May 20, 2023 at 3:13 am
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
Change is inevitable... Change for the better is not.
May 20, 2023 at 6:12 am
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.
May 20, 2023 at 7:42 am
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.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
May 20, 2023 at 12:45 pm
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
May 20, 2023 at 3:31 pm
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.
May 20, 2023 at 5:05 pm
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.
May 21, 2023 at 1:06 am
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".
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
Change is inevitable... Change for the better is not.
Viewing 15 posts - 66,331 through 66,345 (of 66,738 total)
You must be logged in to reply to this topic. Login to reply