April 3, 2009 at 8:32 am
Agree with Aaron, T-SQL is a mixture of set-based and procedural programming. Any individual SQL command, like a SELECT, is set-based, but if you put anything after it suddenly you get into the world of procedural programming, which is technically T-SQL at that point. I read somewhere where the person described SQL as a declarative language and I have to agree with that. When you issue a SELECT statement you're not telling the database engine how to get your data, just what you want; the engine figures out the how. It's like HTML or other declarative languages. And if you really want to go there you could say any language other than assembly is declarative, you're just telling the compiler what you want, it figures out the processor instructions for you. 🙂
April 3, 2009 at 8:32 am
I read the T-SQL rant and to me it seemed more a SQL rant than a T-SQL one. A paradigm problem, not a language one. I still shudder when I think about the poster that said his developer wasn't concerned with such "theoretical" things as primary keys! :crazy:
Personally, I like SQL for the domain it was intended for. The 92 syntax in the FROM clause is something I've still never completely wrapped my head around (Joins via WHERE always made more sense to me), but that's what visual query builders are for. 🙂 Other than that, SQL is extremely straight-forward. Well, other than the bells and whistles they keep adding, but cruft is the cost of SQL-as-hammer, right? (chuckle)
Now, having said that, T-SQL *is* a bit clunky as a procedural language. I'm a syntax-snob and hate both COBOL-style Victorian Verbosity and C-style Obfustication By Brevity. My taste lies more toward Basic or Python style syntax. Clean, free of compiler sugar, and vaguely english-like while still allowing things like:
A=B+C
If A=B Then
li_Counter++
I've done a lot of work in Access (no boos from the peanut gallery please), specifically Jet. Conceptually and syntactically VBA does a *lot* of things right, particularly immediacy of error handling. There are issues, OOP would be a welcome addition, but it's not essential, just desirable. I did Powerbuilder in the early 90's and sometimes miss OOP.
T-SQL was never intended as a heavy-lifting procedural programming language, and so it's no surprize it's not the best choice to create an entire application in. That's why we have the CLR for when there's simply no substitute for RBAR. And .NET to make the client app.
For handling data, for doing data validation, and other light-duty procedural tasks T-SQL isn't horrible. I can live with the clunky syntax choices, they aren't *that* bad. I could stand things like code-folding in the IDE (still using SQL Server 2005) but horses for courses, right?
April 3, 2009 at 8:35 am
Jason Miller (4/3/2009)
I guess I'm strange, I prefer an language/environment where explicit definitions are required.
I couldn't agree more. While it may be a pain to type in the "extra" stuff, I believe that leaving too much as optional or implicit leads to bad assumptions and misunderstandings when someone else has to maintain the code. Explicit definitions and statements may be more work, but it certainly makes the code more definitive and clearer. This is true no matter what language or environment you're working with.
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
April 3, 2009 at 9:05 am
Thank heaven for this forum. Hearing things like "dBASE dot prompt" etc. makes me glad I'm not the only DBA flashing back on SQL 4.21 days...
I learned SQL "back in the day" almost exclusively by using sp_helptext. I saw how Microsoft wrote their stored procedures and followed suit.
While I'm not [against] other languages, I am against bad practice. As long as the "other language" (aka. nonT-SQL) doesn't do anything stupid against my database like cursor through a million rows one by one, or do a "SELECT DISTINCT *", I say live and let live. There are always more than one way to code a query but precious few ways that are good, optimized code. Write it how you like in what you like but if it's not optimized, developer meets speeding bus.
Am I personally going to jump on every new language that is "SQL friendly"? No. I'm waaaay too old for that stuff. Languages that I find value in or I can leverage to do my job, like T-SQL, , etc. are on the top of my list. I'd rather be good at coding a few languages than jack of all languages and master of none.
Of course, I'm a DBA not a developer so I certainly hope I don't get flamed by my front-end-coding friends out there... . I'm more of a "do everything with a stored proc" than a "let the app do everything" sort of guy.
April 3, 2009 at 9:27 am
Like so many others have said, T-SQL excels in data extraction and manipulation. For other purposes, other tools are considered to be better. I've heard, and read, that T-SQL is a "hack", or not a real language, or not as "elegant" as C#, etc. But, for what it's designed for, it's great. And I've got a lot more to learn about it.
😛
April 3, 2009 at 9:35 am
I am a database application programmer (VB.Net) who had the good fortune to be mentored by a great DBA in my last job. My knowledge of SQL makes me a better coder. I can get the exact dataset that I want in the format I want. I don't have to futz with the data after I pull it back to VB. I always say let the database do the donkey work; that's what it's there for.
Granted, SQL requires a different mind set than VB, C#, etc. but it's well worth the effort to learn it. And this web site sure helps. 🙂
April 3, 2009 at 10:09 am
My 2 cents. I'm a really old developer. Been at it for more than 40 years. I started using a KSR33 teletype at 50 baud. The list of languages that I have used makes Steve Jones' look short. Yes, there are a few languages that "suck" (ADA being one of them). SQL (and not specifically T-SQL), doesn't actually "suck", it's just has bizarre syntax, with bizarre commands that can be significantly different from other languages. For the most part, the differences in languages is just syntax (grouped by type, like RPG is nothing like Basic, but is not that different from DYL260 - OK, both are probably dead). As my use of SQL is a small part of my use of other languages, I find myself using a reference book (or Google) to find the synonym that SQL uses. I find it hard to accomplish tasks that are easy in other languages, so I tend to use SQL for data access, and process the data with another language - even though pure SQL might be very significantly faster (most of my work is with small databases, and many times one-shot, so efficiency isn't usually a factor). There are some good commands in SQL - I especially like "IN". Overall, I would be a lot happier with SQL if the commands and syntax were more like other languages.
April 3, 2009 at 10:21 am
QUOTATION: I speak Spanish to God, Italian to women, French to men and German to my horse.
ATTRIBUTION: King Charles V (1500–1558), King of Spain and Holy Roman Emperor.
Looks like someone's been having this conversation already?
Mind you while the English we speak now is very different to the English we spoke in the time of Shakespeare it is still pretty much recognisable. Could we say the same about sql in 500 years? I think so.
April 3, 2009 at 10:22 am
kevriley (4/3/2009)
dphillips (4/3/2009)
I concur with the previous post, and would also add that the IDE's for T-SQL or SQL in general could do with a lot more features.dphillips, like what?
Kev
I'll throw in my 2-cents.....
* Source refactoring (i.e. changing variables, reformatting) I use Management Studio for my work, so there may be other solutions other there that do this.
* Auto-completion/compiling. Why does Mgmt Studio only do this for 2008 databases, or do I not know how to turn it on for everything else?? It's going to be a couple of years before all our databases are migrated, gotta do all that testing first you know. Why should I pay for SQL prompt to get this capability?
* 'Show me all uses of this variable' highlighting
* Click to follow calls
I also don't understand why MS can't add packages like Oracle has with true re-entrant subroutines. I don't want to write 10 stored procs that will never be used by anything else, I want true subroutines.
The lack of the above items means I will continue to use Java (using the free Eclipse IDE) to write anything but simple or one-time-use procs. I get more flexibility, and have yet to see any appreciable performance hit.
April 3, 2009 at 10:24 am
The O/R Impedance Mismatch has always been the greatest issue for newbies. If you let the right tool do what it's designed for, nothing will go wrong. Let the database handle data and let high-level programming languages handle business logic: this is the key.
If you're in trouble, maybe you didn't put everything in the right place. There's plenty of frameworks and paradigms to handle this the right way: pick one and go with it! Maybe tomorrow will come a new technology able to sum up everything, but today this is the best we can have and it seems to me that building a clean and performing application is far from impossible.
I've worked with Java, C#, VB, VB.Net, Delphi and many others and I can definetly say that any of these sucks if the programmer sucks. The same can be said for SQL and database languages: the power to do a good job is in your own hands.
-- Gianluca Sartori
April 3, 2009 at 11:53 am
I certainly can't argue with "the power to do a good job is in your own hands.", my only point about SQL, is you shouldn't have to learn new verbs when using the ones (synonyms) in other languages would do. I suppose, while having used so many languages, they tend to blur, it seems unnecessary to use a synonym and different syntax when the same thing has been accomplished by several other languages for years.
I guess I should be happy that IF...THEN was not changed to POSSIBLY...THEREFORE.
April 3, 2009 at 12:05 pm
fnoell (4/3/2009)
I guess I should be happy that IF...THEN was not changed to POSSIBLY...THEREFORE.
OTHERWISE .....
We could market the new linguistically challenged version SCL...
Super Confusing Langauge...
Honor Super Omnia-
Jason Miller
April 3, 2009 at 12:20 pm
T-SQL is a wonderfully logical language.
April 3, 2009 at 12:44 pm
I'm a data architect, a mathematician who was dragged into the IT world. I've worked with SQL in RDBMS's for 10 years, on DB2, Teradata, SQL Server, Access/JET, SAS, FOCUS & WebFOCUS, Oracle, you name it. I have also worked in numerous procedural and scripting languages (I won't bore you with the rest of my resume here). I find this discussion very engaging, though I don't have time to add anything especially salient. I've already read echoes of my own opinion in this thread, that the complaints about SQL come primarily from folks who don't understand set theory, relational algebra, or those faced with poor db design. That's not a put down, mind you. It's just different and takes some work to understand. I will readily admit that I quickly become befuddled when I try to pull apart OOP code, especially when it's procedural written in faux-OO--augh! (as in, I just spent an hour tracking down classes and methods and now I find out that little bit is all it does?!?!) Obfuscation indeed. It's just when I hear complaints about SQL being obtuse or flawed I am flabbergasted. SQL is crystal compared to some of that!
There is nothing wrong with the 'paradigm' or 'science' behind relational databases. SQL is the lingua franca for the RDBMS world and if you want to play there, you must speak it. It is not Microsoft or Sybase or anyone else's 'fault.' It works, it works well and it works fast. There are other interesting approaches, but nothing that moves the mountain like SQL. I agree that returning to hierarchical dbs, albeit with new twists, is likely a dead-end road that will not pan out, though I wish those engaged in those endeavors the best of luck, and try to keep up with the innovations and white papers of such theoretical experiments. Nothing has sold me on giving up on RDBMS yet.
Mostly, I want to say that I think the minor complaints about the interfaces are hilarious. Anyone worked with BTEQ? Written DB2 cursors for COBOL (yes, RBAR all the way)? Oh, it doesn't do the typing for you and THAT'S your biggest complaint? MERGE doesn't have enough outputs? OMG some people are just spoiled! You should have tried to work with SQL before CASE! It's just a matter of time before the UI catches up to the current parallel terminology (refactoring!--ROFL) and then there will be some other new 'issue', some other new technology that SQL is 'not as good as'. Grow up and learn that different is not always bad and new is not always better. I mean there is a point to keeping up your skills and keeping an open mind but OW! don't throw the baby out with the bathwater!
Enough with this rambling, I've work to do...
😎 Kate The Great :w00t:
If you don't have time to do it right the first time, where will you find time to do it again?
April 3, 2009 at 12:54 pm
katedgrt (4/3/2009)
Grow up and learn that different is not always bad and new is not always better. I mean there is a point to keeping up your skills and keeping an open mind but OW! don't throw the baby out with the bathwater!
Kate, I couldn't agree with you more. I guess that us "old-timers" have a greater appreciation for the advances that have been made. If your biggest complaint is the UI is not as slick as some other gizmo tool, then perhaps you should take a turn at developing applications on punch cards or the new fangled green screen terminals where you have to deal with your own memory management and 8-bit logic!:hehe:
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
Viewing 15 posts - 31 through 45 (of 266 total)
You must be logged in to reply to this topic. Login to reply