''Real'' SQL Server Developers

  • In my company, SQL Server plays a big part of the process.  However ever since I came to work here, I found out most of the SQL Server developers could not even figure out the difference between an outer join and inner join.

    What I found out was the VP here thought SQL was so simple, anyone can do it.  When they first implemented SQL Server, he just told the 'COBOL' programmers to learn SQL themselves.  Unfortunately not everyone is Bill Gate nor Larry Page.  They could write some SQL, but it was so bad that it would execute hours.  One of the DBA advised the VP that the company needed real SQL server developer to design database and write decent stored procedures. He refused to believe it.   He would send people to C# training class but not SQL training class.

    Is SQL that simple that anyone can do it? or just the people in my company had a hard time to learn it.

     

     

  • Let me put it this way... I have 3000+ hours experience with sql/sqlserver and I'm just starting to feel comfortable.

    This is not something you can learn by yourself... You need a teacher or mentor to jump start you in the right direction, then you can start to learn on your own. But you're still gonna be learning every day (unless you always do the same boring stuff).

    I'd say you can lern by yourself... but you're never gonna produce anything good, performance wise, or even logic wise.

  • Writing good SQL requires a totally different mindset than writing good procedural code.  Set oriented thinking isn't a natural mode for COBOL programmers.  Many moons ago, I made that shift and it took as long to un-learn my old ways of problem solving as it did to learn the new.

    I've worked with SQL (MS SQL Server on OS/2) since 1993 and I'm still learning things from the folks on this forum.  I buy a new SQL book every couple of years, because the language evolves and vendors provide useful (and sometimes non-relational) extensions.  SQL Server 2005 will alter the landscape tremendously with the CLR integration feature.

    The ability to write good sql really requires 2 things: a firm grounding in relational theory (I like the works of Chris Date and Fabian Pascal for this), and a good understanding of the particular product you are working with including the internals of the storage and optimizer engines (Ken Henderson's "The Gurus guide to SQL Server Architecture and Internals" is my personal favorite).

     My recommendation:  Go to class, read up on the theory, and haunt the discussion forums on a regular basis.


    And then again, I might be wrong ...
    David Webb

  • There are so many areas of Sql Server that one may never get to use on the projects that the developers are working on....Replication, linked servers to name just a couple...in fact (imho) database design itself is a fine art that very few have mastered..but again, it all depends on the scope of your project and how you plan to use your database.

    There are as many simple databases out there as there are really complex ones...so if the project you're working on is not cluttered with a zillion business rules and your database consists of no more than a few tables, views and procedures your VP MIGHT be forgiven for thinking that SQL is easy enough to learn on one's own...

    In fact, in the real world there are about 50 Oracle schools/training for every one of Sql Server 2000 - when I asked a SQL teacher at a local training program why this was, his response was similar to your VP's attitude...Oracle is difficult to learn and infinitely more complex than Sql Server whereas with time and effort Sql Server can be mastered with enough individual grit and determination...







    **ASCII stupid question, get a stupid ANSI !!!**

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply