April 3, 2009 at 6:44 am
I am mainly a C# web designer (only about 2 years in), and have to daily create sprocs to fill data tables which in turn fill my data grids, etc.
While T-Sql was frustrating to me at first because of the lack of intellisense (which I probably rely on too much in my C# coding 🙂 ), I do feel that the simplicity of its design has grown on me. I leave the concept of creating relational databases to the experts in my group, but I understand the overall concept. The primary keys, secondary keys, etc. are an absolute must for our databases to work.
April 3, 2009 at 6:46 am
I think its important to have a good foundational understanding of programming and when/why to use an SQL query instead of writing code.
I learned SQL by looking at the resulting queries from MS Access applications I created. Hush, I can hear the groans already...
I can and have hacked out TSQL code if I needed to, and have programmedin VB and so many other languages I've literally lost count.
The one thing common to all of them is the fact that there are some things they just can't do easily (and sometimes not at all). And, there are easy and difficult ways to get things accomplished in each of them.
My biggest problem when I switch to a new language is trying to do things the way I did them in the last language.
So, to me it boils down to understanding what TSQL (or any language) can and can't do, what can programmed easily in it and what can't, and most importantly, where to find the information that explains all that to me.
April 3, 2009 at 6:52 am
I'm old-ish, too. And I have to concur with Bob 100%.
Everybody I work with is always jumping onto the latest shiny new thing: today it's LINQ, so DataSets and SqlDataReaders are automatically deprecated. Never mind that they, too, were once "the only way you should ever do data access, moving forward". What will it be tomorrow?
I work as a dev/DBA, and I have "developed" using LISP, Pascal, Excel's macro language(!), Lingo (for an old product called Director), Actionscript, VB.NET and C#. From my experiences (and I don't think anyone's mentioned this yet), I've found that one of the things that makes it "harder" to work with application development languages is the sheer size of the libraries that accompany those languages. The .NET library has thousands of classes and it's being added to every day. So, the developer's job includes staying up to date on the state of the libraries that lie beneath the language(s) he or she works with. With T-SQL, we don't see that kind of growth and it is more "up to you" how you will craft your solution -- provided that T-SQL is the best tool to leverage in creating that solution.
So, I think that though we work with technology it is not technology that ultimately gets the job done. It is the people employing the technology who get it done. There's an earlier poster in this thread who says he's a DBA, working with developers. That's great! And I hope his company maintains that structure, because it demonstrates the best way to operate by utilizing people as assets. Those developers know (or they should know) that they have a resource available to them as they code their apps -- a resource that lives and breathes and can be gone to for help when needed. That beats Google any day. Or at least it helps Google.
As for the paradigm, I've found the set-based mindset easier and more comfortable over the years. So for me, SQL (in all of its flavors) is an "easy enough" paradigm to work with.
April 3, 2009 at 6:58 am
For myself (primarily a web developer), my problems with SQL aren't rooted so much in the language syntax and nuances, but rather familiarity with the paradigm itself. I think SSC Journeyman illustrates that point when he talks about the idea of making SQL (something simple) more C#ish implying it would make it more difficult to be productive with.
Unfortunately, I can only slice my learning time pie into so many pieces so you have to balance what topics of study and experimentation will benefit your immediate project needs, long term career goals and overall personal interests. With so many languages and technologies we are required to know about, I think many of us (like myself) sadly just don't have enough time to become a master at many of them.
I have personally come down the side of "it's better to know a little about everything than to know everything about little". I feel it's more important to know something CAN be done rather than the mechanics of HOW to do it (that's what Google is for). The unfortunate side effect to that is that you frequently miss many of the tips and tricks that might lead you to make better designs and write more efficient SQL queries. I have frequently been surprised by the DBA's that I work with when they explain why they would have written the SQL code differently than I did.
So, in the final analysis, I guess you could say I'm pretty much language agnostic. I think SQL while different from C# or VB, is appropriate for the tool it interacts with. Had SQL been initially released with a C#ish syntax and someone proposed a simpler T-SQL like syntax, I suppose we'd be having a similar discussion about that.
April 3, 2009 at 7:07 am
I think it all comes down to a paradigm. Folks who spend most of their time in an object-oriented environment tend to think in those terms. The same is true with procedural programming. T-SQL is really a mixture of procedural and set-based approaches.
I've been around for a while and I've developed in numerous languages (COBOL, APL, LISP, PostScript, C, Pascal, C#, VB, T-SQL, etc.), databases (Rdb, Oracle, mySQL, SQL Server, etc.) and platforms (OS360, THEOS, VAX/VMS, HP-UX, Linux, Windows, etc.). That exposure has fortunately given me a "buffet" approach to development and has not locked me into any one paradigm. It's true that I have favorite features from each of the different languages and environments, but that doesn't mean that I would want to combine them all into a single comprehensive language that would handle all paradigms! Such a beast, if it were even possible, would not be appropriate.
The old adage "the right tool for the right job" is very applicable to software development. T-SQL does an outstanding job at set data manipulation and C# is in a class by itself (pun intended), but they serve different purposes and getting T-SQL to be more like C# would be no more effective than getting C# to be more like T-SQL.
And that's all I've got to say about that.
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
April 3, 2009 at 7:11 am
Both sql60190 and Steve point to another issue.
That is the massive extent and learning curve of modern languages. It was fairly easy to "know" 50% and utilize or more of the capabilities of early languages such as Cobol or Fortran.
I feel fairly certain that I only use less than 1% of the capabilities of TSQL, or VB.
Part of this is because there is just too much for one person to know, a larger part is lack of need, but a large part is also different terminology
I've often wished that someone would create programming language to language dictionaries, or perhaps a "customs, norms, and common practices and courtesies" dictionary between languages.
At times jumping to a new language is really a bit like moving to a foreign country.
April 3, 2009 at 7:16 am
I agree with much that's been written already. Some have mentioned the disconnect that we developers have with thing in set-based terms. That's true. It took me a few weeks to finally get it. The reason developers and procedural programmers don't think in sets is because we normally want to work with one record at a time. When a user wants to update a database, they are usually working with one record such as an employee master record or a customer order record. When updates occur, they may cascade to other tables such as order history but, for the most part, we are interested in one or a few records. Batch processes can update many records but we think of them on at a time.
I understood the set-based mindset when I was tasked with developing stored procedures for SSRS report. Reports require the presentation of groups or sets of records.
I've been using .NET and T-SQL for two years and I like the separation of the UI from the database. I have some trouble now going back and working in the AS400, RPG style of programming.
I've found that developers who complain about T-SQL are unwilling to take the personal time to learn it, study it, and become comfortable with it.
April 3, 2009 at 7:18 am
There have been quite a few excellent and rational comments so far.
There seems to be a common thread to them in that SQL is just the tool and it is the craftsman who makes the difference. It is worth hiring a plasterer to fix the walls and ceilings in your house. While the novice can use the same tools and pickup the concepts and techniques there is an art to mastering the tools and manipulating the medium.
Could there be improvements to the T-SQL syntax? Sure but syntax is not what makes it difficult for novices to learn or developers with experience in other environments.
There is clearly a paradigm shift from other development environments in that SQL is a language specify crafted for the querying and manipulation of data. The fact that a SQL developer can write one select statement that would be hundreds of lines of code in other environments is the true beauty. Conversely it would be a miserable experience trying to write a parallel processing ray tracing 3D rendering program using T-SQL.
The reason I have my profession is a result of others not wanting to do the database work because it was too hard conceptually not syntactically. Having mastered my trade over two decades I create value by understanding complex issues and relations of data and structuring them to yield the most value for the problem. Couple that with the mastery of the tools, T-SQL, I can further create value by taking the work of linear procedural programmers who solve their problems one record at a time and apply set based processes that kick the stuffing out of other techniques in performance.
As SQL/database developers we wield the biggest baddest hammer data has ever seen. We are closer to and more adept at manipulating and finding vast amounts of data then in any other environment.
To a carpenter every problem can be solved with a hammer and a nail. This is true of developers as well. We use the tools we have to solve the problems we face. Understanding what problems you can solve and what you can't is one of the keys to success.
SQL is excellent for what is was created to do. That being said, there still is room for improvement.
April 3, 2009 at 7:45 am
I have to agree with Bob. I suspect that comparitively few developers really spend time learning SQL past making basic querys or the bare minimum to get the job done and out the door.
April 3, 2009 at 7:49 am
Who made the APL dig? (Steve?) The beauty of APL (and later J) is that it is array based (set based, but in more than SQLs two dimensions limit.) Yes I have written major applications in APL, in about 10% of the time it would take in other languages (and I have used most of them.)
I continue to be impressed with the power of relational database engines; but that is unrelated to the language with which the database engine communicates.
I hesitate to reveal my bias (because I didn't participate in the previous discussion), but I think SQL (and no less T-SQL) is at best cumbersome, ugly, and poorly designed (evolved?). A good DB interface language should really start with a clean sheet. Compare SQL to an elegant and powerful language like J or K! Ugh.
April 3, 2009 at 8:06 am
T-SQL is clunky in certain regards. For example, why doesn't this work:
select Col1, count(*)
from dbo.MyTable;
SQL Server will raise an error that Col1 is neither contained in a Group By nor an aggregate. Quite obviously, it is meant to be contained in the Group By, so why not implicitly include it? Sure, that may be a violation of the standard, but in my opinion, the standard is flawed on this point.
- 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
April 3, 2009 at 8:11 am
GSquared (4/3/2009)
Quite obviously, it is meant to be contained in the Group By, so why not implicitly include it? Sure, that may be a violation of the standard, but in my opinion, the standard is flawed on this point.
I guess I'm strange, I prefer an language/environment where explicit definitions are required.
Honor Super Omnia-
Jason Miller
April 3, 2009 at 8:17 am
Old Hand, it wasn't me that made the APL dig!! 🙂
I wasn't going to say anything about this, but since I'm posting a second reply anyway, brownph99 seemed a little harsh to me in stating developers just want to do the bare minimum in SQL to get something out the door.
There may be some developers that don't care about performance or overall quality of their code but in my experience, these kinds of developers are the exception and not the rule. There isn't a single developer on my team that doesn't put considerable thought into performance not just from a web based responsiveness but also from a SQL data access standpoint.
Getting the Data required to populate the User Interface has always been a primary concern for most developers here where there can be hundreds of concurrent Users working with an application and all accessing the Database simultaneously.
I suspect that if developers are doing as brownph99 suggests, it is likely due to inexperience or a lack of understanding of the importance of efficiently getting and saving Data. After all, the whole point of an application ultimately comes down User interaction with data - regardless of the store model employed to support that interaction - data access efficiency is critical to a good performing application.
I'm sorry that there are those developers out there that may disregard the importance of solid data access methodology but in my personal experience, I've rarely run into developers like this. Most of us are professionals that really do care about the quality of our work. Many of us work late into the wee hours of the morning to tweak our code to make for a better User experience and data is at the very heart of what we do.
April 3, 2009 at 8:23 am
Steve (4/3/2009)
Old Hand, it wasn't me that made the APL dig!! 🙂I wasn't going to say anything about this, but since I'm posting a second reply anyway, brownph99 seemed a little harsh to me in stating developers just want to do the bare minimum in SQL to get something out the door.
There may be some developers that don't care about performance or overall quality of their code but in my experience, these kinds of developers are the exception and not the rule. There isn't a single developer on my team that doesn't put considerable thought into performance not just from a web based responsiveness but also from a SQL data access standpoint.
Getting the Data required to populate the User Interface has always been a primary concern for most developers here where there can be hundreds of concurrent Users working with an application and all accessing the Database simultaneously.
I suspect that if developers are doing as brownph99 suggests, it is likely due to inexperience or a lack of understanding of the importance of efficiently getting and saving Data. After all, the whole point of an application ultimately comes down User interaction with data - regardless of the store model employed to support that interaction - data access efficiency is critical to a good performing application.
I'm sorry that there are those developers out there that may disregard the importance of solid data access methodology but in my personal experience, I've rarely run into developers like this. Most of us are professionals that really do care about the quality of our work. Many of us work late into the wee hours of the morning to tweak our code to make for a better User experience and data is at the very heart of what we do.
I agree entirely. However, there's a middle line.
I've met few developers who're unprofessional enough to disregard performance. However, I've met several more who're a little blinkered (and DBAs too, for that matter). These people will be keen on optimising performance, but they'll look at how they can make their existing model run quicker rather than look at other models that might be more efficient. These are the people who would most benefit from having their eyes opened.
Semper in excretia, suus solum profundum variat
April 3, 2009 at 8:27 am
As a database developer who frequently writes applications outside of the database platform (but often interacts with it and are data-driven), I'm a big fan of T-SQL and I feel bad that some other Microsoft developers struggle with it. I've gotten a lot of help from mentors and the community and think others should seek those resources out.
The need for T-SQL has increased and the barriers have diminished. I think those who put it in their toolbox will be rewarded. Part of this discussion involves the vague suspicion that perhaps T-SQL might be replaced some day with something better, or it's somehow fundamentally flawed. Forget about that. It's solid.
People are looking to aggregated data to solve problems like improving government transparency or understanding web search trends. New reports and visualizers are being invented that often derive from database query results. The deluge of transactions taking place between entities are being nicely handled using T-SQL and other similar methods that can commit or roll back a transaction.
The internet continues to pile data on top of data. Not only do we get search results, but we're starting to rate the result entries and track result comments and ratings. We're posting a deluge of images and attaching text tags to them so they can be associated with terms and searched. Micro blog entries are stored and searched.
Enter the common Microsoft developer who'se in an organization leveraging the SQL Server platform that doesn't have a dedicated database developer. To put T-SQL in the toolbox, a developer could use the help of training, good tools like those offered by Red Gate (SQL Prompt, etc.) and good references like The Practical SQL Handbook 4th Edition.
There are organizational hurdles and financial hurdles in the way. Developers are often denied access due to the need to protect mission-critical database assets. The employer won't add training to the budget. However, these issues are being addressed. Microsoft offers SQL Server Express for free along with Express versions of Visual Studio which offers code generation features so it's easier to connect to the database, get results and separate the data layer. There's a lot of help available from this community and others.
Then there are the psychological and emotional hurdles and these are perhaps the biggest problem. My co-worker is planning a trip and decided for Hawaii because Cancun requires a passport. Same kind of issue. People want the path of least resistance and then try to make their preferences seem like they're based on technical imperatives.
A lot of the imagined controversy with T-SQL ends up being illigitimate uses or apples-to-oranges comparisons with non-database coding. When legitimate nees have arisen, the folks at Microsoft have offered additional features like the new CLR extensions.
This talk about LINQ being a parallel technology is odd and maybe due to not understanding what it's there for. It's there to add elegance to scenarios that require a loop outside of the database to help manage complexity. Or, correct me if I'm wrong. In the background during runtime, a loop is actually executed, but at least a programmer can hide loops from code.
If you're struggling with it, reach out to a mentor and the community.
Bill Nicolich: www.SQLFave.com.
Daily tweet of what's new and interesting: AppendNow
Viewing 15 posts - 16 through 30 (of 266 total)
You must be logged in to reply to this topic. Login to reply