May 18, 2023 at 4:50 pm
I agree with Eirikur on all this... I believe that a whole lot of people resort to the likes of Python because they don't actually know how to use SQL Server/T-SQL.
Another reason is they believe in the total BS out there like "To a hammer, everything is a nail" without understanding that when you're trying to drive nails, you should use some sort of hammer. The other extremely tired saying of "Just because you can do something in SQL, doesn't mean you should". Pure Rubbish. It should be "Just because you can't even spell SQL, doesn't mean you shouldn't learn how". It is, after all, the language of structured data. Perhaps we should start the new mantra of "Just because you can do something in Python (Powershell, C#, VBA, flavor-of-the-day, etc) , doesn't mean you should".
Unfortunately, too many have more knowledge of how to use their tools than the nature of the task at hand.
😎
Having said that, we all need to learn, sometimes by failing. I wrote a zip/unzip procedure in T-SQL, a lesson learned, it worked but soon figured out that it was not the right approach, just as Jeff has so many times stated, "Just be you can" isn't a justification 😉
May 18, 2023 at 5:23 pm
Jeff Moden wrote:I agree with Eirikur on all this... I believe that a whole lot of people resort to the likes of Python because they don't actually know how to use SQL Server/T-SQL.
Another reason is they believe in the total BS out there like "To a hammer, everything is a nail" without understanding that when you're trying to drive nails, you should use some sort of hammer. The other extremely tired saying of "Just because you can do something in SQL, doesn't mean you should". Pure Rubbish. It should be "Just because you can't even spell SQL, doesn't mean you shouldn't learn how". It is, after all, the language of structured data. Perhaps we should start the new mantra of "Just because you can do something in Python (Powershell, C#, VBA, flavor-of-the-day, etc) , doesn't mean you should".
Unfortunately, too many have more knowledge of how to use their tools than the nature of the task at hand. 😎 Having said that, we all need to learn, sometimes by failing. I wrote a zip/unzip procedure in T-SQL, a lesson learned, it worked but soon figured out that it was not the right approach, just as Jeff has so many times stated, "Just be you can" isn't a justification 😉
Too funny... that's one of the things I actually do use SQL Server for... makes logging of status and much more, real easy. So, in that case, I'll have to resort to what we all know... "It Depends". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2023 at 6:06 pm
Check out this video. The speaker gives a whole laundry list of reasons, a litany of epiphanies, on why SQL Server is not well suited for transaction processing. Instead, the better way, as he's telling it, is to create "future transactions" (jumbo shrimp?) to undo the cumulative totals he's running to facilitate calculating a discount for a promotion. Still using SQL Server afaik. At around the 5:50 second mark he basically confesses to not knowing anything about SQL Server. At around the 7:00 mark he goes to a SQL DBA for advice and he receives a stored procedure which works and performs well. Then he gets requests for more work and again we're told SQL Server is not well suited for exactly what he's doing. He feared his favored code was losing relevance and he laid awake at night worrying about stored procedures. So he invented this future events driven thing. Wow
https://www.youtube.com/watch?v=9ix0vVL34-M&t=2691s
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
May 18, 2023 at 6:19 pm
Yes, why would anyone want to use that complicated futuristic hover car (aka T-SQL in this case) 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.
I ran into this years ago, and I would not be surprised if they are still doing it. But instead of upgrading their code to a better language they decided to upgrade Cobol by giving it all the features that the better more efficient languages have that Cobol did not have. And this was just the more simplistic constructs like While and For loops for example. So I would not be surprised if they have spent tons of money transforming Cobol into an object oriented language by now or are still working on doing so. Just so they have all that current technology within that dinotopic prehistoric language.
May 18, 2023 at 9:26 pm
Well, my workplace desktop support is useless on the SSC website issue. I am the only person in the office having problems with it but apparently the issue is SSC. And I sent an email the SSC webmster and haven't heard a thing back. So I have to access this website from my personal laptop, which is hard to read during work because it's twice as far from me as my work laptop. I'm dying here. I didn't realize how much of a lifeline this place was for me.
That being said, because of this I can't post screenshots properly, just text. And I urgently need help here: https://www.sqlservercentral.com/forums/topic/ssisdb-and-availability-groups-problem if someone has any thoughts on SSISDB and AGs and master key issues.
May 19, 2023 at 2:21 am
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.
You're insisting that it will be a dinosaur. I'll say "It depends". More times than not, someone has promised "futuristic hover cars" and, compared to the crap code that was written as a predecessor by someone that doesn't actually know SQL. it frequently is.
I try not to waste my time on "futuristic hover cars"... "transporters" work much better. 😉
Even with that, though, "It Depends". Sometimes a winged dinosaur that can fly at Mach 2 gets the trick done. Its only emissions are the occasional hover car that it ate along the way. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2023 at 2:55 am
Jeff Moden I did try to outline that in context. I was saying I have actually seen this before with a dynotopic prehistoric 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 prehistoric 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 prehistoric solution which of course is going to fall significantly short of these futuristic hover cars.
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.
Viewing 15 posts - 66,301 through 66,315 (of 66,816 total)
You must be logged in to reply to this topic. Login to reply