January 25, 2008 at 7:23 am
Straegen (5/2/2005)
Not buying it. In many (read most) small companies, the dev is the SQL guy and the software developer. Most small company devs will leave TSQL quickly since working in one language is easier than two. It will take longer for large companies to switch as they move slower for good reason, but small companies are usually the first indicators of where the industry is headed. With the switch to dotNet and many apps being rewritten, it won't take long for TSQL to become CLR code in most shops. The great news is that TSQL developers willing to make the switch will likely find good jobs over the next decade porting code.
Also, TSQL is horrible... let me say it again... HORRIBLE as a language. CLR is better and I speak from experience. This has been coming for years and all the major commercial SQLs will all switch sooner or later. I can see MySQL and smaller engines staying in SQL syntax for a while, but it wouldn't suprise me to see some PHP or similar engines being fitted for them as well.
Just like COBOL had to die and VB Classic will soon be pronounced, it is time to stick a fork in a language that should have been dead years ago. I get that DBAs with little or no programming skill might beworried, but in my experience it isn't the TSQL that keeps a DBA around. It is the tuning and maintenance which software developers generally don't want to do or are incapable of doing.
My last comment on the subject is don't be an ostrich on this one. If you do,youwill likely pull your head from the sand and realize that a part of your skillset has been rendered obsolete. I still remember my COBOL friends from the mid 90s saying there is just too much tested COBOL code to replace. COBOL will be around for my lifetime. That VB stuff isn't as solid and proven. Yada... yada... yada. Theyall eventually converted and unfortunately for most it was too late. Being the new kid on the block at age 50 just isn't pretty.
January 25, 2008 at 7:36 am
Grasshopper: I have to take issue with your statement that TSQL is a horrible language. From my 38 years first as a developer and then a DBA, I can vouch for the fact that for the languages I have used over the years, Assembler, Autocoder, Cobol, Basic, RPG, Fortran, and for the past 15 yeas SQL, including TSQL, there are many more bad developers than bad languages. SQL, IF you know how to use it, is an extremely powerful and fast tool. But it's just like woodworking. Having the best tools doesn't buy you a thing if you don't know how to use them. I have witnessed an appalling decline in the skill level of developers over the past ten years. Companies no longer want quality, they want quantity, and if the customers aren't yelling TOO loudly, that's OK, so lets push the next version out the door with more features that - sort of - work. I currently have a whole list of SQL processes created by our best developers, waiting to have me correct and improve logic for things as simple as reporting only 11 of the past 12 months, unless the process runs and succeeds in the last 10 minutes of the current month, with no possibility to rerun without code changes.
I don't want these sincere folks dabbling in my databases!
R Coffman, SQL Server DBA, with 38 active production servers.
January 25, 2008 at 7:48 am
It feels to me that with 2005, Microsoft is moving SQL Server into the application server space. In some instances, perhaps a low transaction volume environment, it make sense that the application server and the database coexist. But then I don't think that a DBA is the right person to manage it.
I do think that for the enterprise you still will want to separate out your database and your application servers. The nice thing is that the same software can serve both roles, capitalizing on your knowledge investment of the platform.
Additionally, comparing SQL Server to other application servers, SQL Server has alot more to offer than most due to the integration of the CLR with the already strong database and XML support.
January 25, 2008 at 8:03 am
I am thinking of implementing a CLR solution for sending an XML file to another company. Scenario: Company A runs SQL 2005 and so does company B. In a stored procedure at company A, instantiate a CLR object that is passed an result set from SELECT....FOR XML Auto, etc... and the CLR sends the XML file to a stored procedure at company B, which is configured with EndPoints. Therefore, the stored procedure at company A may be schedule to process throught the day.
Let me throw my 2 cents into the ring on the business layer. I believe the business logic should reside in the stored procedures. I know Republican vs. Democratic type of topic. As with anything, there are exceptions when this is the case, but for the most part I put the business logic in the stored procedures and returning appropriate results sets via SQL Reader is the fastest way to display data to the users. Users want data returned to them fast. We agree that logic is logic is logic and it needs to reside somewhere. Putting as close to the data as possible and just the reduction of text passed across the wire will speed it up.
Go George Bush...oh yes...he is not running again 😉
January 25, 2008 at 8:42 am
Some interesting comments and thanks for the debate.
I think the idea of replacing xp_cmdshell for specific functions is a great one, and one that I hadn't thought of when I first wrote this article. that alone would make sense, though I'm not sure why MS hasn't implemented those. Maybe we need an open source project for some those functions!
I'd defintely be interested to know specifically where you've found it useful. I have heard of issues with large strings (>8K), so be careful if you're building XML to send out.
I don't like the idea of SQL Server being an application server. It's too limited a resource to be straining with other functions. Maybe there should be a "SSApp Server" that lets you easily run some of these processes, costs less than SQL, and manages things like business logic.
January 25, 2008 at 8:46 am
What is not understood about interpreted code be it T-SQL, CLR, JAVA or VB3 code? When you add 2 layers of interpretation to a piece of code, it will run slower than it did when it had to be interpreted once.
T-SQL is interpreted by the database engine (more or less). C# or VB.NOT is interpreted by the CLR. Assuming that the C#/VB.NOT programmers put T-SQL into the C# stored procedures, we get multiple interpretations of the code. This must run slower that T-SQL alone.
That C#/VB.NOT coders would combine T-SQL and their language code together is a certainty; that they can do it means they WILL do it. Microsoft knows this yet they created a situation where this compound interpretation problem must inevitiably result.
The CLR inside SQL Server is a stupid idea just as JAVA inside Oracle was a stupid idea. It is bad enough that T-SQL must be interpreted and that Stored Procedures and Functions are partially compiled instead of fully compiled. But, adding the CLR and enabling inexperienced programmers (the kind usually hired by startup specialty companies with a good business idea) to use it in stored procedures added insult to injury.
Truly a dumn, dumn, dumn idea to start with and it will be an even dummer idea in 2008 and beyond.
January 25, 2008 at 9:10 am
I am reminded of the old adage:
If the only tool you have is a hammer, everything looks like a nail.
The more flexibility we have, the more agility we have, and that endears us to the business. A professional picks the RIGHT tool for the job, and doesn't complain about the other guy's toolbox.
There is a place in this world for DOS Batch files, T/SQL, .NET, and yes even VBA and they are all good tools if they are used to solve the problems that they were designed for. .net code in the database gives us another option, and this is not a bad thing.
Complaining that those "developers" want to put their "bad" code in "your" database is seriously immature, learn .net and get over it.:w00t:
January 25, 2008 at 9:18 am
rick (1/25/2008)
Straegen (5/2/2005)
Not buying it. In many (read most) small companies, the dev is the SQL guy and the software developer. Most small company devs will leave TSQL quickly since working in one language is easier than two. It will take longer for large companies to switch as they move slower for good reason, but small companies are usually the first indicators of where the industry is headed. With the switch to dotNet and many apps being rewritten, it won't take long for TSQL to become CLR code in most shops. The great news is that TSQL developers willing to make the switch will likely find good jobs over the next decade porting code.
Also, TSQL is horrible... let me say it again... HORRIBLE as a language. CLR is better and I speak from experience. This has been coming for years and all the major commercial SQLs will all switch sooner or later. I can see MySQL and smaller engines staying in SQL syntax for a while, but it wouldn't suprise me to see some PHP or similar engines being fitted for them as well.
Just like COBOL had to die and VB Classic will soon be pronounced, it is time to stick a fork in a language that should have been dead years ago. I get that DBAs with little or no programming skill might beworried, but in my experience it isn't the TSQL that keeps a DBA around. It is the tuning and maintenance which software developers generally don't want to do or are incapable of doing.
My last comment on the subject is don't be an ostrich on this one. If you do,youwill likely pull your head from the sand and realize that a part of your skillset has been rendered obsolete. I still remember my COBOL friends from the mid 90s saying there is just too much tested COBOL code to replace. COBOL will be around for my lifetime. That VB stuff isn't as solid and proven. Yada... yada... yada. Theyall eventually converted and unfortunately for most it was too late. Being the new kid on the block at age 50 just isn't pretty.
I must concur with Ricks comments about the above with a big AMEN and would add the following:
Your comments about TSQL and Programming languages (notice how I listed these seperately) show either a lack of a clear understanding of the differences between each or a lack of expereince in general. TSQL can't be a HORRIBLE language because it is not a Programming langauge like VB/C/C#/ . TSQL is a set of commands for working with data sets, not for programming. Yes you can create Stored Procedures and even UDFs which are similiar in some ways to functions/procedures in programming langauges but they are very different.
SQL, be it T-SQL, PL/SQL or any other flavor of the core SQL are for working with sets of data where as programing langauges are for not. This is not to say you can't work with a RDBMS using a langauge like VB, only that the flavors of SQL are designed to work directly with the RDBMS where as VB and other programming langauges are not. In fact progarmming lanaguges like VB end up using SQL at some point to get at data in a RDBMS, you just don't see it because the SQL is in a Blackbox such as a DLL or similiar object/file that contains objects you can consume.
Lastly, you are being the Ostrich if you honestly believe that expecting a developer to have to know/work with just 1 langauge (whether its because its easier or any other reason) and or if TSQL is headed the way of past programming langauges. So long as we use RDBMS to store data there will be some form of SQL in use even if it's not named T-SQL in the case of SQL Server.
Ed C
DBA/Developer
Kindest Regards,
Just say No to Facebook!January 25, 2008 at 9:19 am
Alan Robbins, I couldn't agree more! 🙂
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
January 25, 2008 at 9:20 am
Alan Robbins (1/25/2008)
I am reminded of the old adage:If the only tool you have is a hammer, everything looks like a nail.
The more flexibility we have, the more agility we have, and that endears us to the business. A professional picks the RIGHT tool for the job, and doesn't complain about the other guy's toolbox.
There is a place in this world for DOS Batch files, T/SQL, .NET, and yes even VBA and they are all good tools if they are used to solve the problems that they were designed for. .net code in the database gives us another option, and this is not a bad thing.
Complaining that those "developers" want to put their "bad" code in "your" database is seriously immature, learn .net and get over it.:w00t:
Well said Alan!
Kindest Regards,
Just say No to Facebook!January 25, 2008 at 9:23 am
Inside MICROSOFT SQL SERVER 2005: T-SQL PROGRAMMING
by Itzik Ben-Gan
Solid Quality Learning
is a great introduction to SQL CLR
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
January 25, 2008 at 9:25 am
don_goodman (1/25/2008)
What is not understood about interpreted code be it T-SQL, CLR, JAVA or VB3 code? When you add 2 layers of interpretation to a piece of code, it will run slower than it did when it had to be interpreted once.
First of all, CLR code is not interpreted after the first time it's run. So yes, there will be a performance hit the very first time the code is called, but subsequently (until a reboot, service restart, etc) a natively compiled version will be used. This is known as just-in-time compilation... Google for more info.
Second, SQLCLR called from T-SQL is certainly not slower than straight T-SQL. I have tested this fairly extensively over the past three and a half years and am confident in the fact that the technology performs well and has some great potential uses. That said, it certainly has incredibly potential for misuse. But I am personally of the mind that you shouldn't shield potentially powerful technologies simply because they might not get used in the best of ways. If developers and/or architects don't do their research and misuse this stuff, that's their problem, not yours or mine.
--
Adam Machanic
whoisactive
January 25, 2008 at 9:27 am
Marios Philippopoulos (1/25/2008)
Inside MICROSOFT SQL SERVER 2005: T-SQL PROGRAMMINGby Itzik Ben-Gan
Solid Quality Learning
is a great introduction to SQL CLR
Absolutely! And may I also suggest...
"Pro SQL Server 2005"
by Tom Rizzo, Adam Machanic, et al
(Apress, 2005)
... and when you're done with that one, check out the book listed in my signature for even more ...
😀
--
Adam Machanic
whoisactive
January 25, 2008 at 9:29 am
Thank you Adam, will do
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
January 25, 2008 at 9:53 am
Wow, this has been a good discussion to read. Of course, it took me a while to get through all of the posts. It must be that I am on the West Coast, and I already have 6 pages to read. Well, my thoughts regarding CLR and TSQL. I expect TSQL will stay around for as long as we have DBMS systems. SQL Server and other DBMS systems are maintained by DBAs or there "want to be" counter-part, the Developer. DBAs are trained and skilled with planning, maintaining, designing, and tuning the database engine and tools. Developers are mainly focused on the development aspect and they try to perform the same tasks that the DBA performs, which in my opinion takes years to accomplish. Therefore, I don't expect any SQL language to disappear but further enhancements will be made to help the DBA or Database developer to work more efficiently.
When we talk about CLR and SQL Server, I believe there is a time and place for all technology. I have used a few CLR stored procedures and functions, but they are uncommon in most of the environments that I have worked in. I have created REG-EX functions, record-set based stored procedures for data collection of Operating System data that would otherwise be difficult with regular TSQL. Anyone who writes code using the sp_OA objects could potentially rewrite using CLR with greater security and flexibility. I do advocate the use of CLR objects when they are needed or are tested with greater performance for complex calculations. However, TSQL is my top choice for most logic, set based, and code reuse. Profiling CLR is not the easiest task. Monitoring performance and reviewing "Execution Plans" are an important part of the DBA Role. If these tasks are not performed, then the DBA probably isn't focused on the well-being of there environments.
Technology is awesome, and the CLR has provided more features and greater benefits to the DBA. The CLR must not be used as the default logic for the RDBMS. Experienced DBAs will carefully evaluate the technology used in the DBMS.
Thanks Steve, this is another good post.
Viewing 15 posts - 46 through 60 (of 64 total)
You must be logged in to reply to this topic. Login to reply