August 3, 2019 at 12:30 am
Comments posted to this topic are about the item Best Practices and Band Plans
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 3, 2019 at 12:40 pm
Good article! Glad to see Amateur Radio get a little love. I have talked to some people that state "our best practices is to never use..." because they tried it when it was first introduced in SQL Server 2005 and it didn't work for them so now they won't use it at all. I try to point out that in the past fourteen years that feature has seen lots of improvement and if it was truly horrible Microsoft would have dropped it. I know vague statement but I don't remember the exact feature...but we are using it in our environment with great success whatever it was. The point is we can't be stuck on what may have been best over a decade ago and best practices have to evolve along with the technology and have to be accepted throughout the community not just "this is OUR best practice."
Good luck on the license upgrade, I hope to go for Amateur Extra this coming winter myself.
73,
KA0SQL (Marcus)
August 3, 2019 at 4:13 pm
Nice article! It's interesting how some best practices change over time...
And good luck with your license I got my advanced license years ago, and 73.
WA3MH (Mark)
August 3, 2019 at 7:02 pm
KC1KCE 73 DE WS1O
August 3, 2019 at 7:31 pm
"I have talked to some people that state "our best practices is to never use..." because they tried it when it was first introduced in SQL Server 2005 and it didn't work for them so now they won't use it at all. "
Yeah. My pet peeve: people saying that views are banned because they cause performance issues. Despite those same people having no real background in databases, and hiring me as an expert they still manage to tell me this. Fortunately I can usually ignore their rules. But more junior permanent co-workers are not always as lucky.
Oh, and the "no foreign keys" always makes me mad. If you as a developer don't understand database integrity, you have no business touching my database in the first place. Grrrr....
One of my best practices is: not putting hints in queries (emergencies exempted). I've seen people putt hints in EVERY SINGLE QUERY they write because it's best practice to always force hash joins or something. What the heck? If you need to force every plan to get it to perform, perhaps there is something wrong with your database settings or your queries? Naah... that could never be the case...
August 5, 2019 at 10:22 am
Great to see all the hams.73 to you all
This fight, like so many others, does come down to ignorance. We have to constantly educate ourselves and others.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 5, 2019 at 9:30 pm
Great article Grant.
Former WN4NKJ
June 13, 2021 at 7:36 am
The referential and check constraints in SQL don't cover all possible necessary constraints.
Therefore you need to use triggers to enforce these constraints.
The arguments against triggers come from the Oracle camp. In Oracle triggers are dubious because they are row rather than set oriented - leading to the infamous "mutating tables" error.
Secondly Oracle (and Postgres) only support MVCC (snapshot isolation) which means you are potentially reading out of date data in your validation - and therefore can get the wrong answer - unless you adopt a very complex and arduous method in your stored procedure or application.
These problems don't exist in SQL Server and triggers are the right way to enforce integrity that isn't covered by the methods built into SQL (specifically multi-row constraints and cross table constraints other than foreign keys).
Of course you need to learn how to use triggers properly - always set oriented and no side effects.
June 13, 2021 at 7:42 am
As an additional point, lobby Microsoft to implement assertions (in the SQL Standard since 1992) which would eliminate the need for constraints in triggers. I know that the implications for locking are a bit tricky but I am sure that the folks at MS are clever enough to solve this conundrum ;-).
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply