June 15, 2010 at 2:00 pm
YSLGuru
MANAGEMENT - The problem (from personal experience) is that far too foten the managemnt or decission makers are often programmers themselves and unless they have at least a respect for SQL they will treat it as poorly as the rest of their staff.
This appears to be a manifestation of he old adage, 'People are promoted up to their level of incompetence"
When employed by G.E., such was not the case, developers, DBAs , etc., were all part of the IT department. With each group headed by their own designated Lead, that is a Lead developer, a Lead DBA, etc all reporting to the IT Manager.
A common bonding point was ALL members jointly attended an every other year, at an off site location, a week long training program at which each individual gained some knowledge and a great deal of respect for the tasks / problems of all those in IT.
June 15, 2010 at 2:21 pm
Charles Kincaid (6/15/2010)
YSLGuru (6/15/2010)
MANAGEMENT - The problem (from personal experience) is that far too foten the managemnt or decission makers are often programmers themselves and unless they have at least a respect for SQL they will treat it as poorly as the rest of their staff.The truth is that procedural programmers who did not learn and work with SQL before becoming a programmer are most likely not going to learn to respect SQL and will continue to make the same mistakes in SQL design as those who came before them.
Its funny because you'd think after as many years as the Relational DB has been around, that procedural programmers would have finally confessed and admitted that the SQL:/DBA needs to be part of the development team when the software will be using a RDBMS for storage.
I have been writing code for a living since Sept. 1972. Much of it procedural in nature. Now from that standpoint I agree with you.
The switch to event driven was tough. The switch to set based is tough. Now that the tough is done I now have the power to choose what technique is appropriate where and when.
Making changes for some people is hard. Any change. Still one has to decide that staying with the old ways is just a recipe for early retirement.
Charles,
Don’t get me wrong on this b/c I am definitely not against change, I just am not change for the sake of change or when it’s because someone wants to bend to their way that which does not work in the manner that the rest of their processes do.
Example: I just go thru re-writing a very simple procedure in SQL that while not complicated at all, is used a lot and I mean a lot by our financial system. The procedure used a cursor to append the text values form a couple of records. The procedure was setup like this because it was created by a procedural programmer with little if any SQL understanding.
Not only did the re-worked procedure look better but it was shorter, literally containing less characters. Not that the number of characters in a code make a difference; it’s just a way of emphasing how the procedural developer made it harder on themselves by writing something more complex then was needed.
I know that I'm no VB or C# or ASP.Net guru and that I know just enough to be dangerous and so I do not take the approach of your ASP page needs to work more like my SAQL Queries. And yet the reverse is often how procedural developers look at all things SQL. Keep in mind I know ther are exceptions and that I am referring to those programmers without proper SQL training & skills. If the programmer has learned SQL the right way, they usually are not so arrogant or disrespectful of it.
Kindest Regards,
Just say No to Facebook!June 15, 2010 at 2:53 pm
YSLGuru (6/15/2010)
Charles,Don’t get me wrong on this b/c I am definitely not against change, I just am not change for the sake of change or when it’s because someone wants to bend to their way that which does not work in the manner that the rest of their processes do.
Right on! Again we agree. Better has to be better because ... Style is just style. I had trouble getting queries changed because I was not putting all of the conditionals in the WHERE clause. I had elevated the conditionals (predicates) to the JOINs. Not because of style but because the new way did not time out. The old way was so bad we often timed out. We had one that was so bad that we improved performance by using a CTE. I got flak for that because it was not a recursive example.
Set based is better (most of the time) because it yields better results. Tally tables are cool because the solve a problem. Dates tables the same way. I just read an article here about a Dates table function that is even better because I don't have to store the huge table.
You get to learn new things all the time. This industry keeps growing and evolving. I might never retire!
ATBCharles Kincaid
Viewing 3 posts - 31 through 32 (of 32 total)
You must be logged in to reply to this topic. Login to reply