Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

The T-SQL Paradigm Expand / Collapse
Author
Message
Posted Friday, April 3, 2009 6:03 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, April 25, 2014 6:31 AM
Points: 29, Visits: 1,018
I agree with Bob.Sargent comments.

I go back 20 or so years to mainframe assembler, COBOL and JCL. I am currently a asp.net/vb.net developer and an "Application DBA".

I am fine with SQL. I've never had a requirement that it didn't handle.

Also, I hope that LINQ dies the quick death it deserves.

M
Post #689762
Posted Friday, April 3, 2009 6:09 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, August 28, 2013 6:59 AM
Points: 149, Visits: 51
I've been developing web and win apps for the retail and financial market for many years and I've found SQL to be very valuable and T-SQL an easy language to work with.
I've put a great deal of time learning as much about SQL as possible (to the point where I've often been asked for advice from DBAs in companies I've worked for!). This has resulted in me being able to write some great applications. In retrospect, if I didn't have the SQL knowledge I currently possess would those apps have been as good? Simple answer - No.
I feel SQL can sometimes be given a low priority in the personal learning curve of developers. A message to those that do give it a low priority - give it a lot of focus and learn as much as possible and you'll come to find it time very well spent. You might not agree with that now.. but you will do!
Post #689769
Posted Friday, April 3, 2009 6:12 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, November 18, 2010 5:25 AM
Points: 162, Visits: 694
Having started my db work in EXEC, REXX, RAMIS (sp?), and the like, then moving on to procedural programming languages in college, Modula-2 for the most part, after college moving to Sybase, and eventually MSSQL 4.3... I think I know the disconnect. Someone stated before, the problem is in the mindset. Having been the hired gun in a few shops (consultant), I can say that the biggest problem I see is developers who can not break free of the procedural, RBAR (thanks) mindset.
The developers can not or will not think in sets.
The most recent, and one of the most painful examples is a db tracking certain events. The db is ~600GB, grows about 10 GB a week, adding some 5M rows a day. For whatever reason, the app developers decided to CLUSTER the index on a GUID, and then they wrote an archival routine to remove old data via a cursor, row by row by row by...
The data was coming in more than 10x faster than it could be deleted. I rewrote the procedure(s) and introduced small batches to the idea... Now, the test machines could delete everything they need to (on going) in about 30 minutes.
Haven't heard if it's been tested in production yet.

I should really finish that education I started... (Actually, I'm supposed to graduate this summer, it's only taken me 22 years.)




Honor Super Omnia-
Jason Miller
Post #689772
Posted Friday, April 3, 2009 6:19 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, May 7, 2012 9:23 AM
Points: 304, Visits: 716
Amazing!!! I was just at a meeting recently where some of us "old guys" were talking about how these younger generations just seem to LOVE complexity and confusion. To suggest that T-SQL should be replaced with C#, or should be more C#-ish - well, now I have heard it all! Right, replace something very simple, with something totally confusing - great idea!

T-SQL is fairly easy and more, you can be "good" at it without having to be "great" - that is, you can teach it to non-programmers and find they do some good basic work. SQL can be tricky, and does have it subtleties but still, I would agree that its easy to work with and probably the easiest after the XBase languages (which were all more English-like).

This reminds me of the famous tale of two engineers (one from Microsoft) given the task of building something to take a person one block from their apartment, to the local corner store. The non-Microsoft engineer comes back with a skateboard, and the Microsoft guy comes back with the Space Shuttle. Yeah, they will both get you to the corner store, but one does it in less than minute with no complexity involved, and the other requires tons of fuel, tons of parts, and has to fly into space and return to just go one block. And of course, after you get your stuff at the store, the Space Shuttle needs to be towed to a launchpad to fly again. The problem these days is too many developers continue to build Space Shuttles where skateboards would do.

I don't know where it all got lost - but simple is always better than complexity for the sake of "cool". I wish the generations of programmers that came after mine had learned that lesson - but sadly, they seem to have learned just the opposite...

...and this fellow's rant about T-SQL illustrates that quite clearly.




There's no such thing as dumb questions, only poorly thought-out answers...
Post #689783
Posted Friday, April 3, 2009 6:29 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, August 22, 2014 9:18 AM
Points: 751, Visits: 1,915
It's great for what it does, handle complex queries and set operations. It's less than great for procedural code, I like c++ but c# or VB will do.

...

-- FORTRAN manual for Xerox Computers --
Post #689789
Posted Friday, April 3, 2009 6:44 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, March 28, 2013 7:09 AM
Points: 11, Visits: 43
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.

Post #689807
Posted Friday, April 3, 2009 6:46 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, October 2, 2009 6:43 AM
Points: 57, Visits: 151
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.
Post #689812
Posted Friday, April 3, 2009 6:52 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, November 9, 2012 1:39 PM
Points: 22, Visits: 166
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.
Post #689817
Posted Friday, April 3, 2009 6:58 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, June 15, 2012 6:47 PM
Points: 8, Visits: 36
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.
Post #689829
Posted Friday, April 3, 2009 7:07 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, August 4, 2014 6:48 AM
Points: 1,111, Visits: 542
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.



"...when ye are in the service of your fellow beings ye are only in the service of your God." -- Mosiah 2:17
Post #689839
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse