May 25, 2009 at 6:56 am
ta.bu.shi.da.yu (5/25/2009)
Damus (5/25/2009)
I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same 🙂I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in University
I say time for change, even if it is gradual
Why? Just because it's the same old thing doesn't mean it's not worthwhile. I'm curious as to your reasoning.
Dont get me wrong 🙂 it all still works, I am not attacking it. Just not evolving like other technologies. Maybe coz its very basic, or maybe coz they are pulled back with backward compatibility like someone posted earlier.
May 26, 2009 at 4:06 am
ChrisN
I questioned the choice of PowerShell as the core scripting language coming from my decades of scripting and development experience on another redgate forum and was told basically to shut up and enjoy the ride.
I hope it wasn't a Simple-Talk forum! Simple-Talk ran a number of PowerShell articles and we were surprised at the lack of keenness for the scripting shell. After quite a bit of debate, we came to the conclusion that it was just too arcane. Although it would be quixotic to believe we can change the general flight to Powershell, we can see IronPython and IronRuby being far easier to use for administrative scripting for a lot of folks. We're hedging our bets!
Here again, the 'softies' are a bit out-of-touch with the work in ordinary IT departments. When the subject of Powershell came up in the recent DB Teched sessions, the DBAs in the audience showed little enthusiasm, as Tony noted in his editorial when they were confronted with complex XQuery etc.. (I seem to have been as interested in the audience reaction to what was said from the rostrum, as in the talks themselves, but these were recorded anyway for posterity.)
Best wishes,
Phil Factor
May 26, 2009 at 8:09 am
Interesting. A few experts that haved dived in heavily to Powershell and they seem to like it. It follows what I'd consider is a very simple format and structure.
Whether it's good or not, I think it will take off in the MS world since it will be built into every server in the next 3-5 years. At that point, you'll start using it as a default. Just like VBScript, which is relatively simple to start with, and then gets horribly convoluted, established itself since it was built into Windows.
May 26, 2009 at 8:16 am
Damus (5/25/2009)
I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same 🙂I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in University
I say time for change, even if it is gradual
SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.
May 26, 2009 at 8:25 am
Lynn Pettis (5/26/2009)
Damus (5/25/2009)
I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same 🙂I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in University
I say time for change, even if it is gradual
SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.
/sigh. Seems I hit a taboo subject by saying that it is time to change. NOTHING is wrong with it.
Nothing is wrong with Pascal, or Cobol, or punchcards either. They all do what they are/were supposed to do.
May 26, 2009 at 8:28 am
Many Sour Grapes to all who claim expertise in face of daily reality. The fact is most T-SQL programming is mundane and nearly all of the changes made by the Powers-That-Be are marketing messages instead of improvements. That is why folks disconnect from marketing meetings at marketing events.
Do I need power shell? No. Do I need partioning in 2005 when I cannot defrag a clustered index? No. Most of the time if not all of the time, I read a new form of T-SQL coding and think, "Jeez, that's neat. I wonder if I will ever have a chance to use it?" and almost never find a reason to use it. I nearly always find a faster, more efficient way to do the same thing that doesn't lock up the network pipe, disk bind the data transfer or prevent users from retreiving data.
The fact is there is a universal disconnection between the Powers-That-Be at the Microsoft SQL Server Universe and the people that use SQL Server. 95% of all DBAs and T-SQL programmers over-think the problems and write hundreds if not thousands of useless lines of code making things run slower and slower. And Microsoft encourages this bad coding because it thinks that people want to write thousands of lines of code that run really slow so they can buy really big machines with lots and lots of memory. This cycle feeds the machine that churns the purchase of operating systems and hardware. It's part of the "churn" that marketing people like to create in markets. But it doesn't help our users in any way or form.
Nope it doesn't make our users' lives better. Sour Grapes. The folks disconnect from the meetings because the content is irrelevant to what they do. The content doesn't help them isolate bad code, make stuff run faster, eliminate blocking, etc... No improvements in T-SQL will ever do that. Only good code and design will do that and the Powers-That-Be don't teach good code and design. Only code coders do. And MS doesn't have any. They've all been replaced by marketing people.
May 26, 2009 at 8:30 am
Damus (5/26/2009)
Lynn Pettis (5/26/2009)
Damus (5/25/2009)
I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same 🙂I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in University
I say time for change, even if it is gradual
SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.
/sigh. Seems I hit a taboo subject by saying that it is time to change. NOTHING is wrong with it.
Nothing is wrong with Pascal, or Cobol, or punchcards either. They all do what they are/were supposed to do.
It's not a question of taboos. It's a question of, do you have specific, finite improvements, or are you asking for change for the sake of change?
The statement about it being old and therefore needing to change is "change for the sake of change", at face value. If you have specifics, that's another thing entirely.
Edit: Actually, COBOL doesn't do what it was supposed to do. A major part of its original purpose was to eliminate the need for programmers, since businesspeople would be able to build their own computer solutions with it. It most definitely does not achieve that goal.
Punchcards may do what they're supposed to, but keyboards and mice involve definite, finite improvements over them as input devices, and hard drives have definite, finite improvements over them as a means of storing compiled/uncompiled code/files.
SQL in general and T-SQL in particular, and SQL Server, have gone through a number of evolutionary improvements since I started using them in 2000/2001, and a few revolutionary improvements have appeared in SQL Server, like CLR procs and functions. There have been quite a few of them that have very little if any actual practical use, but there have also been quite a few that have a tremendous usefulness.
If you want to contribute to that continued evolution, or if you have something revolutionary that will be a huge improvement, say so and give specifics. Just lamenting how old SQL is and how tired that makes it, doesn't actually accomplish anything. (Sorry, I'm specifics and results oriented. Just the way I am.)
- 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
May 26, 2009 at 9:05 am
Don,
I think you are correct. Most people don't need the new features, and few use them. I'm not sure if it's 5% or 25%, but I bet it's low.
That being said, I think there have been good improvements. CTEs have become a staple of mine, and I didn't think they were great when I first saw them. I think that PBM will become something much handier over time.
Powershell? Not sure. It does look easier to use (to me) than VBScript. And miles easier than Perl.
May 26, 2009 at 9:07 am
I withdraw all comments I previously posted on this discussion.
I appologize to anyone who was offended. Did not mean anything wrong.
Peace (white flag)
May 26, 2009 at 9:14 am
Damus (5/26/2009)
I withdraw all comments I previously posted on this discussion.I appologize to anyone who was offended. Did not mean anything wrong.
Peace (white flag)
I seriously doubt anyone was offended. Just wanted to know what specific improvements you want.
- 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
May 26, 2009 at 9:19 am
Damus (5/26/2009)
I withdraw all comments I previously posted on this discussion.I appologize to anyone who was offended. Did not mean anything wrong.
Peace (white flag)
I wasn't offended. I am curious what you think is wrong with the SQL (or in this case T-SQL) language that it needs improvement.
May 26, 2009 at 9:25 am
/relief
Thanks guys 🙂 for a moment there, you sounded like my x-boss 😉
anyways, not sure if i should post here or not. one question first:
- How to manage SQL code (all stored procs, triggers, tables, change scripts etc...) in an easy streight forward way like we do with c# code for example.
I personally try to organize them in source control as folders/subfolders, logical filenames etc... I would love to have a more efficient way.
May 26, 2009 at 9:30 am
Damus,
I don't see anything offensive in your posts, and I, too, would be surprised if anyone was offended. I think they just wanted you to defend your statement with more detail.
That being said, the management of files is really a platform thing. The problem with SQL is that you submit your file to be compiled in a server, something you don't do with IIS or other applications, so it appears you've lost control. If we took away the ability of the source code to be on the server, then that would force some VCS to be used, but it might create other DR issues.
That's really a management issue though, not a language issue.
There are some language things that people would like, for example, native regular expressions built into SQL. I think Spatial data can have many enhancements, for things like CAD/CAM, but those a specialized areas.
Encryption definitely needs more work, both in making it smoother, and ensuring that things work well. I'm not sure how to build indexing in there, but perhaps we need encrypted indexes that can be used.
The whole permissions structure, IMHO, needs to change to allow databases to exist without the ability of SA to read the data. I could also see the need to have two-login authentication for some tasks.
Some of these are infrastructure type enhancements, but they would need language support, and they might change the language.
May 26, 2009 at 9:40 am
I agree its a management Issue.
some other things i would like to see:
- real foreach loops through table rows.
- object oriented friendly organization of stored procs and triggers coz they are forgotten once you compile them. I can look them up at the moment on the management studio UI or through some SQL function that I will have to memorize. 🙂
- enumerations
those are just what is on my mind right now. will continue tomorrow 🙂
Thanks again guys
May 26, 2009 at 9:46 am
Damus (5/26/2009)
- real foreach loops through table rows.
Why use RBAR when set based solutions work much better and efficiently?
Viewing 15 posts - 16 through 30 (of 43 total)
You must be logged in to reply to this topic. Login to reply