Is T-SQL enough to be a valuable Yukon DBA?
-
Considering Yukon will be .Net, it seems the DBA who knows only T-SQL will be left behind. So the question is what do I need to learn to stay current, Visual Basic .NET, C# or something else? I am a DBA with a Network Admin background so I have no experience with languages other than T-SQL. Considering this, would VB.Net or C# be easier for me to learn? But more importantly will one of them be better for a SQL DBA?
-
I can only provide my proverbial "two cents"; I won't claim it's authoritative. First, I believe that Yukon supports the Common Language Runtime (CLR) introduced as a fundamental piece of .NET. This being the case, you would not be limited to a choice of VB.NET or C# as possible languages that you could use for coding in Yukon; theoretically, you could code in any language that has support for CLR, which include languages such as Perl, Python, C++, Java, and a host of others (I believe Microsoft claims there are about 20 languages that have support for CLR). However, different implementations may cost some money, and not all languages support the same features or are as robust (obviously).
For now, though, limiting your choice to VB.NET and C#: which will be easier for you to learn? Frankly, I think that if you haven't had any experience out of T-SQL, then either language will be equally as difficult/easy to learn. You'll find that some of your experience and knowledge of T-SQL, in particular concepts such as variables, control flow statements (e.g. CASE, IF...THEN...ELSE, WHILE) are common concepts in all languages, and understanding these concepts will greatly assist you in learning any programming language, whether it's VB.NET or C#. So, I think as far as ease of learning is concerned, either one will ultimately be as easy as the other. But I will qualify that: C#, and most C-based languages, tend to lend themselves to a lot more abbreviated coding; in other words, if you're new to programming, they can look like gibberish. VB on the other hand tends to have a more natural syntax - in my opinion - the language is more readable and understandable, even if you've never seen it before. This being the case, you might have an easier time initially comprehending what is going on in a VB program. Personally, I prefer the syntax of C-based languages, but it's a personal choice.
Finally, as to which is "better" to learn, I would suggest VB.NET will probably be more marketable. VB was (and still is) so widely accepted as an easy to use language for business application development that its use is very widespread. I think that follows through into .NET; people will be more inclined to turn VB apps into VB.NET apps, leveraging the familiarity and wide use of that language, than they will be to switching from VB to C#. Consequently, I think you'll find a larger number of available jobs out there if you know VB.NET.
Again, this is nothing authoritative, just my thoughts. In summary, given your situation and your questions, I'd suggest you learn VB.NET.
Matthew Burr
-
I agree that a basic understanding of VB.Net or C# is worth acquiring. Basic flow control and how to use the new data access that is built in. I believe it is just more of the shift away from the DBA writing procs to the DBA managing the procs, checking for bad practices, and just managing the server.
Not much different with XML. Need to know enough to support developers as they accelerate its use in applications.
Andy
-
I think it will be enough. Nice to know the others, but not necessily needed. Last I saw, Yukon wasn't completely set, so not sure how much .NET will be in there.
Steve Jones
-
Where I work we have 3 major programming departments. One is SQL, another is Cold Fusion for our web site, and the last is VB for our researchers. We have 5 Cold Fusion programers. They all develop some stored procedures. I think some of them know Java and/or C++ also. We have two dedicated VB programmers who are learning .NET. We have two people who are designated as VB/SQL programmers they work in both areas. We have one DBA and we have one dedicated SQL Programmer (I am that programmer). I know no other languages.
I anticipate that when we upgrade to Yukon some of our programmers will try to use Java, possibly C# or C++, VB, and VB.Net. However, we will still have a need for someone to ensure all stored procedures are tuned and running the best they can and I doubt anyone is going to go through and convert all our existing 1000 some odd stored procedures to C# or .NET. So I believe there will still be a need for people who specialize in just T-SQL and as those developers start using those other languages that will give me the excuse I need to learn whichever one they choose to use and thus I will pick up a programming language.
Just my opinion on the subject, I don't claim to be an expert either.
Robert W. Marda
SQL Programmer
bigdough.com
The world’s leading capital markets contact database and software platform.
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems -
I think the answer to that question relies most on what it is your current role is and what the company needs out of it's databases.
My role requires that I write all kinds of different mini applications in several different languages. I'm also the defacto DBA. For what I do, I have to know several programming languages so I can use what's appropriate or available (one time I had to use REXX...).
If your role is just to run the databases and write stored procedures, I doubt that you would be required to also know VB.NET or C#. If management wants to expand your role to include interface development, then you should probably learn a .Net language.
Note that my personal preference is for C#, and I haven't really used VB.Net. I have, however, used VB for a number of years, and some VBScript, etc... The fact that there is a VBScript and not CSharpScript (that I know of, but does jscript almost count?) might mean that you if you have to pick one, you should learn VB.Net just because it (almost) applies to some other environments.
Something to consider as well is that, at it's heart, running things through the CLR is VERY much like Java. I learned Java quite a while ago, and while I loved how the language was structured, it just wasn't fast enough to do anything heavy in. Computers are much faster now so that takes care of some of the problem, but I'd want to run some speed tests, implementing identical processes in both T-SQL and CSharp running inside SQL Server like a stored procedure, before I did any serious development on it. Point here being that it may not be appropriate to replace what you do in T-SQL with equivalent CSharp code; we'll have to see when it comes out.
Matthew Galbraith
Lead Database Programmer
Data Services
Brann Forbes
-
TSQL I expect to remain a key part for a long time to come anyway, why else would we bother with a RDBMS standard anyway. MS is just proposing to open that to other options that do each have their own benifits. That said, it never hurts to make yourself more valuable than the next guy. VB.NET and C# are pretty close together with concepts of work. VB is probably the easiest to learn but with a good background in TSQL a lot of syntax is easily grasped in C# and C++ it boils down then to concepts of language and objects.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
-
I think T-SQL will be enough if that's the way you want to go. Look at Oracle, most DBAs are still only using PL/SQL, even though it is possible to use Java in Oracle and has been so for a while.
--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
-
We had a Yukon demo a few months ago at the UK User group meeting by by Euan Garden and Patrick Conlan. It was stated that for standard data manipulation, inserts, updates etc (set based processing) then TSQL will be the option that has to be employed. For more iterative process then the use of .net languages to provide extended programming will be the better solution.
A couple more points,
There will be restrictions cpu, memory, io in place on the use of .net code.
MS said they would be providing best practices of what should be done where.
Columns can be declare as .net objects, so you could do column.method to obtain a rowset of data or some specific formatting.
The database is still the least scallable tier.
For prodcution DBAs you will need to understand the basics of how the CLR fits into the database engine.
For development archtiects/dbas the workload is much more difficult. I believe you have to be ale to control how the database is used and accessed, for this you have a full understanding of the different interactions, just like you did with ADO. What is better to write something in TSQL or .net or middle tier and be able to justify it.
The latter is a huge job, especialliy as there are generally more developers than DBAs. So as a DBA you have to know your stuff and their stuff, if you don't want an db that grinds to a halt with 10 users.
Simon Sabin
Co-author of SQL Server 2000 XML Distilled
http://www.amazon.co.uk/exec/obidos/ASIN/1904347088
Simon Sabin
SQL Server MVP
http://sqlblogcasts.com/blogs/simons -
Wow! What a diverse collection of responses! It makes you think about what you do as a "DBA" compared to others in the same profession. I'm entitled the DBA here, but I do the following:
Attend every executive meeting. Discuss where the business is going, what technical support will be needed to reach that "destination." After that, I go back to my desk and I begin analyzing the business need. Any data will be stored in SQL-Server, so that's the sql part. Tables, views, stored procedures, we put there. Then I need to determine the presentation level. If they want web, it's ASP html, and maybe business logic in dlls...Maybe it's a custom "thick client" front end, so it's VB...Maybe we'll be packaging it to sell or distribute to our clients, so I use Wise Installer for that...Reports will be necessary, so will it be Access 2000, if applicable, Cognos, or Crystal, Excel, or home grown in VB?
Now that .NET has arrived, my tool chest just got bigger...C# and VB.NET, and Web Services...So here's the list:
ASP
ASP.NET
HTML
VB 6.0
VB.NET
C#
SQL-Server 6.5-2K T-SQL
Access 2000 (Yes we still use it!)
Crystal Reports
Cognos Impromptu
Wise InstallBuilder
So you can see, from the perspective of this "DBA", these are the skills in my area that will make me a viable "DBA."
Lonnie
-
Simon hit on my #1 concern with SQL Server being "opened up" with .Net languages... WHEN to use which language. It is my great fear that programmers who are used to writing iterative code will be that much more likely to continue that practice in SQL Server with the .Net languages, instead of learning faster, more efficient, set-based solutions to their needs. I run into enough developers using cursors in T-SQL where a simple set-based solution would be so much better, that I'm concerned this will accelerate with .Net.
On the other hand, it suggests there will be ongoing need for contractors like me to come in and clean up systems, so maybe I should be thankful for the job security.
-
There is definitely the concern that developers will be more likely to ignore set-based solutions with the advent of the CLR in Yukon. On the other hand, there's nothing to suggest (as far as I know) that Microsoft might not add additional classes to the .NET framework that will allow set-oriented operations when using the CLR. If you've used ADO.NET at all, you'll notice that - to some degree - DataSets, DataAdapters and DataViews allow some level of set-oriented operability. And in current application design, you can always generate SQL commands (e.g. normal UPDATE, INSERT, DELETE and SELECT commands) written in T-SQL that you can send to your SQL connection, thus allowing you to work in a set-oriented fashion from your application code; you ought to continue to be able to do so once the CLR is integrated with Yukon. Perhaps Microsoft will go the next step of allowing you to execute such commands without creating Command objects and Connection objects.
Ultimately, I'd be very surprised, given that the SQL Server engine is becoming more ubiquitous in Microsoft's product line (consider future versions of Exchange, the future of the Windows registry, or even the future of the Windows file-system) in conjunction with Microsoft's introduction of .NET as fundamental to the future direction of the company, if Microsoft didn't make strides to allow programmers to execute set-oriented operations directly from .NET-based applications; that, to me, seems like a natural extension of Microsoft's future direction.
Matthew Burr
-
The key with anything is to be aware of what you allow to run against your server and the impact it has. I spend sometimes several hours a week fighting programmers who love cursors and cannot see how to function without them. We spend time together trying to exaughts all options until we find the best solution (even if it is the cursor, but lucky for me generally has not been).
I still occasionally fight VB programmers on the use of .UPDATE and .ADD as opposed to Stored Procedures as well.
You will always be fighting someone to make sure it is done right. But you will always find new ways and new processes to do it. Yukon with .NET is going to be one of those situations where you have to get the programmers to realize they had better understand their code as you need to make them give you a business case for anything they do. Otherwise just learn what you can, find networks like this one where you can question those who do know, and when in doubt if it shows to high of an impact refuse until they can give you better code or another solution that does not cause issues.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
-
I agree that they must include some set base operations into TSQL either via TSQL or via CLR code. The need one for XML, OPENXML currently uses the MSXML parser, thus the performance is directly related to the numebr of columns and rows you return (i.e. procedural code), they need code that translates SQL into a form that allows the performance not so linear (i.e set based).
If you think SQL server has been developed over years to optimise the set based code, this is a different mind set. Introducing procedural ability into the engine is to allow it to do procedural work, without a middle tier having to perform multiple calls to the database.
Are well enough pondering, we have a long wait.
Simon Sabin
Co-author of SQL Server 2000 XML Distilled
http://www.amazon.co.uk/exec/obidos/ASIN/1904347088
Simon Sabin
SQL Server MVP
http://sqlblogcasts.com/blogs/simons -
The MS Press book SQL Server 2000 with XML has a whole chapter on enabling your SQL Server to allow queries and updates via HTTP.
It then goes on to say, don't do it in a production environment because of the security risks.
So we have this fantastic whizzy bang feature we can't use, not because of any technical limitation, but because it isn't malice proof.
My worry is that YUKON and .NET will be another case of this. A fantastic opportunity, but absolutely crippled by security issues.
Another one of the pitfalls you have to be aware of is, just because you are a SQL Server person the answer is not always to use SQL.
As mentioned earlier in this thread, there is a fight to get developers to use stored procedures rather than .Add and .Update.
How many people will use none SQL code to do the job that SQL is best suited for? .NET is a great opportunity, but the very freedoms it offers make the job of enforcing best practices more difficult.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply