March 31, 2008 at 8:38 am
Jeff Moden (3/29/2008)
Well said. I especially like the two rules because, if you substitute the word "RBAR" for "Cursor", I use them all the time in a slightly different manner...I. Thou shalt not use RBAR.
II. When you think something can't be done without RBAR, see rule number I.
Hmm... Careful there... Those "rules" look like RBAR to me. And recursive process no less....
tsk..tsk....:P
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 31, 2008 at 8:40 am
We have 2 RPG IV developers (on an DB2 iSeries legacy system) coming into the VB .Net world, as well as SQL Server. Getting them to use joins instead of "WHERE EXISTS" is where we are at, as well as getting them out of the procedural/RBAR mindset and getting to think in sets are the two biggest challenges for them. The good news is that both are very smart and eager to learn and work with new(er) technology.
"Key"
MCITP: DBA, MCSE, MCTS: SQL 2005, OCP
March 31, 2008 at 6:47 pm
Matt Miller (3/31/2008)
Jeff Moden (3/29/2008)
Well said. I especially like the two rules because, if you substitute the word "RBAR" for "Cursor", I use them all the time in a slightly different manner...I. Thou shalt not use RBAR.
II. When you think something can't be done without RBAR, see rule number I.
Hmm... Careful there... Those "rules" look like RBAR to me. And recursive process no less....
tsk..tsk....:P
I'd rather have them stuck in my loop, than me stuck in theirs. :hehe:
[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]
March 31, 2008 at 7:24 pm
Wayne West (3/31/2008)
I agree, performance isn't as big of a deal as it was back in 4.x/6.5 days.
Perfect... everyone keep thinking that way... keeps me employed fixing performance problems 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:52 pm
Matt Miller (3/31/2008)
Jeff Moden (3/29/2008)
Well said. I especially like the two rules because, if you substitute the word "RBAR" for "Cursor", I use them all the time in a slightly different manner...I. Thou shalt not use RBAR.
II. When you think something can't be done without RBAR, see rule number I.
Hmm... Careful there... Those "rules" look like RBAR to me. And recursive process no less....
tsk..tsk....:P
Heh... and there's only one way to break out of such a "control loop"... do it right :w00t:
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 3:21 am
Jeff are those the 'Three Rules'? 😀
akin to Asimov and Clarke
Hiding under a desk from SSIS Implemenation Work :crazy:
April 1, 2008 at 6:15 am
Shaun McGuile (4/1/2008)
Jeff are those the 'Three Rules'? 😀akin to Asimov and Clarke
Heh... no... these are... 😉
[font="Tahoma"]Jeff Moden's Three Rules of DBA's.
1. A DBA may not injure data or performance of the data or, through inaction, allow data or performance of the data to come to harm.
2. A DBA must obey orders given to it by "Users", except where such orders would conflict with the First Law.
3. A DBA must protect "Users" existence as long as such protection does not conflict with the First or Second Law. [/font]
(Defininition of "Users" is anyone including but not limited to Developers, Designers, Data Modelers, Dev Managers, Project Managers, Customers, other DBA's, Ops personell, one's immediate supervisor, or anyone else who, by command, code, design, setting, or device, may impart changes to the schema, the data, or the server).
I wrote those about 10 years ago and they have served me and other DBA's who have knowingly or unknowingly adopted them very well.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 6:19 am
Ok thats the three rules of DBAs 🙂
What about the three rules of REBAR? :hehe:
Hiding under a desk from SSIS Implemenation Work :crazy:
April 1, 2008 at 6:25 am
No, no... that's one of the 10 Commandments of Developers...
"Thou shalt not commit RBAR" 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 6:27 am
Where is the link to the ten commandments?
--Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
April 1, 2008 at 6:56 am
Heh... Never got around to finishing those... can't find any developers that can follow the first commandment...
"Though shalt have no greater database authority than the DBA."
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 7:01 am
This thread has kept me entertained;
http://www.sqlservercentral.com/Forums/FindPost477574.aspx
What a wheeze! 😀
--Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
April 1, 2008 at 7:11 am
Heh... I can see why... There is a bit of "religion" there...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 7:13 am
"Though shalt have no greater database authority than the DBA."
What if the DBA does not know anything except backup and restore database? I have seen a lot of those DBAs around. As a matter of fact, I receive daily newsletter from SQL Server perfromance.com, it said only about half of the DBAs in the industry know what they are doing, the rest only carried the title.
By the way what is RBEAR?
April 1, 2008 at 7:20 am
Loner - RBAR - see Jeff's signature 🙂
All about evil cursors/triangular joins etc. in SQL
Hiding under a desk from SSIS Implemenation Work :crazy:
Viewing 15 posts - 16 through 30 (of 30 total)
You must be logged in to reply to this topic. Login to reply