June 30, 2008 at 8:13 am
Jeff Moden (6/30/2008)
Dang.... that's exactly what they did at the place I work... the worst part is... the DBA recommended it! 😉
Here too, except the previous database architect recommended it. It didn't help that he misunderstood what nolock did. He though it worked like snapshot isolation in 2005 does.
Did I mention I work at a bank?
Fortunatly, the system's borderline a datawarehouse and isn't affected too much by dirty reads.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 30, 2008 at 10:22 am
Jeff Moden (6/30/2008)
Antares686 (6/26/2008)
You could go to your bosses and propose the idea of a DBA doing code quality exams and explain they improve performance, can reduce unexpected downtime and overall produce a better product. Then suggest you hire someone or they give you a raise while explaining the benefits. Win/win if you do right. Plus you can vastly reduce your headaches before production.Shoot... I already do code reviews... nothing goes into the database unless it has my approval on it...
The bad part is, embedded SQL... in order for these dummies to get around a code review, the do the damage in Java. Now, I have to beat the ears off the managers yet again and get them to realize what's going on and to start doing code reviews for all Java code!
And this is why I prefer Stored Procedures over direct table access. Or create a process to kill any connections that take over an amount of resource time to see if you can make them think about the issue but that requires no exceptions to the rule and we know even with the best toughts there can be.
June 30, 2008 at 12:56 pm
June 30, 2008 at 2:41 pm
Steve Jones - Editor (6/30/2008)
http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html
I worked with a guy who really, really, really felt that same way. To him, the database itself was a necessary evil, and should be used only as a semi-structured data repository. He's currently proseletizing object oriented databases.
One time, while bored, I challenged him to use his automatic SQL generator to build 100 SQL commands, and bet him that I could improve the speed and reliability of every single one of them. I won.
I'm sure the technology has improved since then (this was 4 years ago), but I'm also sure it hasn't improved enough to replace a real knowledge of SQL.
For one thing, an automatic code generator can only use existing indexes, it can't review the tables involved, review use of those tables, and decide that a small change to an existing index would dramatically improve an otherwise slow query, and then implement that, all in the context of on-the-fly SQL generation. Designing a stored proc can involve all of those steps.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 30, 2008 at 5:06 pm
GSquared (6/30/2008)
They've been taught the magic words and the mystic gestures, they know that when you say "waz zug cho cthulhu", you have to turn around widershine three times, with one hand in the air and the other hand holding your right ankle.
Hey! Stop it! A bunch of warts just appeared on the back of my hand! What the... :w00t:
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
July 1, 2008 at 7:28 am
Steve Jones - Editor (6/30/2008)
http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html
This was my favorite statement
As far as I am concerned the use of stored procedures, database triggers and foreign key restraints is OPTIONAL, not MANDATORY, therefore I am free to exercise my option not to use them. That is my choice, and the software that I produce does not suffer in any way, therefore it cannot be defined as the wrong choice.
Procs yes are fully optional, but in a good solid design triggers may be required and fk should never be considered optional. The above is usually the closed minded view of someone who assumes only their application will interact with the database and the application is the control source. Knowing this to be fiction if I want my system to have actual meaning as a source of information is why I know there is some BL you must include in the database side. I have come across many systems who say we are the source for this information and when you state you need to feed off/into their information they get all up in arms about they won't do it, mostly becuase they don't won't to maintain your application should they have to make changes. These are also the same folks thou that when they need a source for any information expect it to be handed to them no questions asked. Guess what hand jesture I usually am thinking of at the tim they approach. 😀
I really love people who take a strong stance on one side or the other. Read most of the related links but liked this one a whole lot more
This person basically blasts RI and states it is a myth and that only the application really can prevent such issues (more or less). You have to read their examples about patient (vertical duplicate not really an RI issue as it could be valid and their arguement hinges on a scenario where they did not use a known natural key) data and visa (so you think the database somewhere decided this was so and that the source data will say truely otherwise with or without enforced RI ? Sounds to me like it is a valid condition but somebodies application somewhere had made an error or the condition is completely valid, pictre you make use yur visa fr a gas purchase wich they place a hold of $75 against the card when you start and don't reconcile the actual amount until later with the visa system which to me is nuts but this hold could cause your next use to decline due to over the limit even if it would not, so in the case persons lack of knowledge of the system creates a view for an invalid arguement ).
Regardless of what anyone thinks as you most likely will not change someones view anyway, I think the application and the database are both responsible for doing as much as possible to ensure the consistancy and accuracy of the data. But overall it is still garbage in, garbage out any way you look at it.
July 1, 2008 at 7:44 am
GSquared (6/30/2008)
Some people just apply what I call "professional rituals". They've been taught the magic words and the mystic gestures, they know that when you say "waz zug cho cthulhu",
Heh... I just swing a rubber chicken over my head in a counter-clockwise fashion while drinking the magic elixer(Coffee) with the other hand. (Think patting the belly and rubbing your head at the same time :P). Sorry, Barry... didn't mean to give you whiplash 😀
There are some professional "ritual's" that are worthwhile... Documentation... formatting code for readability... not using explicit loops to make a Tally table or split code... drinking coffee while listening to users that think they know how to write database code to prevent laughing out loud... 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 1, 2008 at 7:59 am
To me, wanting to learn SQL is a good first step...
What amazes me is that some of the people responsible for Lead/QA testing on our SQL based package, don't know the first thing about SQL! What's worse, they don't see the need to learn...they just go by what the screens return. And to me, this doesn't give the complete story. Our security/user admin for the package can't even code a 'select' statement - she just uses the admin interface provided! I've nudged her that way by sending tutorial links, loaning books, etc. but learning something new is the last thing she cares about, even though it's directly related to her job! Arrrrgggghhh!
:angry: Thanks for letting me rant.
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply