August 26, 2019 at 12:57 am
Comments posted to this topic are about the item Growing and Changing
August 26, 2019 at 10:51 am
We are in a profession, not a trade, so (re)learning is essential. Practices that may have been best at one time may no longer apply. This reminded me of my Are you a DBA Monkey? blog post where I suggested one revisit practices that might be followed only due to institional memory.
August 26, 2019 at 2:44 pm
Boy, I see this a lot. In fact, I think I see IT and developer people relying solely on their experience much more often than trying anything new. It's very prevalent here at work. It's prevalent with tech people I know in the community. I'd go so far as to say it's the norm, rather than the exception. "Stick with the tried-and-true" and "don't fix what ain't broke", is the mantra. I'm not saying that the only thing you should do is something different, every time. That's a recipe for disaster as well. Just how about giving something else a go every now and then.
Kindest Regards, Rod Connect with me on LinkedIn.
August 26, 2019 at 2:51 pm
I struggle with this myself as well. When I'm in a hurry, tired, or busy, I tend to lean on experience. It's hard to know how often to try something new, but I do keep reading and learning, looking for ways to think about problems differently. Usually for T-SQL, the forums here provide lots of ideas on how to better approach problems.
August 26, 2019 at 7:04 pm
Ha:),
We called them "old man rules". The practices you follow because you know you were burned badly and don't want to have it happen again.
Many of them are captured in Phil Factor's Code Smells.
But just because they are Old Rules does not mean they are bad rules. Nested Views are the devils spawn and lead to perdition. I wish I could set up a review council to test every trigger, view, cursor, etc. prior to going to production. Actually, it would be nice just to get a few coding standards in place :).
August 26, 2019 at 7:44 pm
I hear ya, Ray. I also struggle with modifying other people's code, unless they've asked me to or I've been assigned to do it. Anyway, one of my coworkers absolutely LOVES cursors! He uses them liberally throughout his T-SQL code. Sigh.
Kindest Regards, Rod Connect with me on LinkedIn.
August 27, 2019 at 3:24 am
Banned temp tables? This is a first for me to hear about problems with them in tempdb. I also started with SQL Server in v4.5, and used temp tables of all sizes over the years, and never experienced any problems at all. One of the largest SQL jobs we had running was an hourly download and upload from an IBM mainframe system of very large flat files that we imported/exported and processed heavily in tempdb. We were passing data inserts/updates and hundreds of customer orders hourly for replication between local databases and remote dealer servers. Other than some poor original development of the SQL code there were zero problems with tempdb. There were very complex stored procedures, some reaching many pages of code, which used large and small tables in tempdb.
You just never know...
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
August 30, 2019 at 12:16 am
OS/2 that was a missed opportunity, 1994 when OS/2 Warp came out I loaded it on my Gateway 486/2 as a dual boot system, (Paragon Partition Magic). I loved it, but it never got developer support, and MS was left as the only end user option. Unix and the others were not yet end user friendly.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply