September 11, 2009 at 3:34 pm
rja.carnegie (9/11/2009)
We get it, you hate non-set-based programming. But sometimes an exercise has to consist of more than one SQL statement. And while only in unusual circumstances should an operation be deliberately slow (I think I found in the past on 2000 that a script that restores a database in one statement and starts reading or writing in it in the next statement is unsafe), there isn't necessarily a payback for a program being faster than "fast enough". If you can improve performance but at the risk of creating programmed errors or just burning up development time, when you have a prototype program that does the job clumsily but adequately and reliably, stop there. You can probably find something else useful to do. Yes, even if that first draft program is RBAR.
Heh... that's kind of what I'm talking about... folks (like you, in this case) who don't even know what set-based programming is keep justifying the mistake of RBAR. First of all, set-based programming has NOTHING to do with writing it all in "one SQL statement". In fact, very high performance set based programming and "Divide'n'Conquer" methods go hand in hand. Then there's the "fast enough" syndrome... if folks don't know what is possible and they aren't actually testing for performance and scalability, then they also have no clue as to what "fast enough" actually is yet they continue to justify RBAR as "fast enough". The bad part is, those people usually don't stick around long enough to see the fruits of the RBAR labors crash and burn. If they did, they'd stop doing it. Also, if someone wrote the first draft as RBAR, then they don't really understand the set-based concept to begin with and should stop there before they make a bigger mess of things.
To be sure, I'm not talking about the arcane methods of replacing some forms of RBAR with set-based technology. I can understand someone not knowing how to use a Tally table to replace a myriad of RBAR tasks or someone not knowing how to use a "quirky update" to do a set based running total. No, I'm talking about the very basics of the language... For example, someone (GUI programmer or not) who has to write a simple multi-row UPDATE to a table should know that you don't need to use a cursor to do the update which is, ironically, easier to learn in a set based fashion than in a cursor fashion. Like I said earlier, it's not necessary for a GUI programmer to become a proverbial "Master Plumber" at SQL, but they should at least know what a proverbial pipe is.
As for spending personal time developing workplace technical skills, you can get burned when an employer drops the product that you skilled up on. I have, more than once. I wonder if you ever heard of a database product called Recital. If you did, I wonder if you heard of Recital Internet Developer. Try selling that expertise in the twenty-first century. Then our outfit had the bright idea of marrying Java and SQL Server, products whose owners were in the middle of a decade of sueing each other. But I did get paid professional training on SQL Server 7, a thousand bucks per course. Then I was working full time on Recital again for two years, and, come to think, we never implemented SQL Server 7 either. I hate the fact I spent any personal time on this. We should band together and tell employers: we do this for pay, not because we enjoy it, and that includes learning about this junk. If you want knowledgeable employees, get them enknowledged on your dollar, not as their gift to you.
Heh... everyone has been through that and folks should plan on such facts of life. Think of the FoxPro developers that have been left behind. Think of all the Lotus Smart Suite experts that had to make the conversion to Microsoft Office. Think of all the WordPerfect and Office Writer users who suddenly had MS Word thrust upon them. Going back a bit, how about all the COBOL and RPG programmers that have been left behind? What do you think they did?
Now, Sun Micro Systems has been sold... will the new owners continue to support Java? Forever? We'll see.
So while I empathize with what you said, I’m not real sure why you think it’s a valid point to not spend time learning how to do your current job by learning enough to keep from being dangerous in SQL especially since it's likely that SQL (whatever it's flavor) will be around for quite some time.
No one owes anyone anything any more, and that goes both ways.
Based on your experience with Recital and my experience with putting my heart and soul into a company only to have it go bankrupt because of upper level mismanagement or become very successful and move to another state, it would be very easy to take on such an attitude. I'm glad I haven't and I'm sorry you apparently have.
One of the reasons why I participate in the forums on SSC is to try to help folks that may have no where to turn and, maybe, push them towards learning a bit more on their own. Sometimes it comes out in the form of "tough love" (ie. LMGTFY.com) and sometimes I end up feeding someone with a silver spoon. Either way, it's meant to help even if I have to take it on the chin once in a while. I understand that not everyone is or needs to be a "Master Plumber" and that not everyone even knows what a "pipe" is. But I'll always take exception to folks that say they don’t need to spend a little time learning how to do their job better. Especially in this day and age, they owe it to the company that sees fit to pay them a salary for their supposed knowledge of the job.
To wit, if they're writing RBAR, then they are intentionally writing slow code simply because they've made the choice to do so. 😉 Hmmmm…. maybe that’s why so many people don’t believe in code header documentation.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2009 at 4:28 am
Well, set operations on a relational database aren't the way to do everything in computing, particularly if you're developing an application for computer operators who are not trained in set-based operations - who probably interact with the database RBAR in their heads instead of batchwise as in the days of punched cards. And if a specification isn't well met by a set-based solution, you can't say that the specification is wrong. There is a growing community of heterodoxist database professionals who spit on the relational database, the object database people for instance, and while their arguments haven't convinced me yet, I respect their right to hold an opinion and recognise that sometimes they may get the job done better... at least until their latest project fails spectacularly and the boring old SQL people step in to save the day. Failure can be good if it's happening to somebody else. 😉
September 14, 2009 at 9:22 pm
rja.carnegie (9/14/2009)
... at least until their latest project fails spectacularly and the boring old SQL people step in to save the day. Failure can be good if it's happening to somebody else. 😉
Heh... Man, do I agree with that. In fact, that's the short version of my job description. :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply