The CLR in SQL Server 2005
-
Joe is a bit of a reactionist, but he's right on the money here.
By accepting the CLR into SQL you are no longer going to be writing SQL. I mean, your language will have SQL elements in it, but good luck trying to move your database to mySQL, or SQLAnywhere, or Oracle without huge re-writes.
One thing Celko hammers on over and over again is writing portable, standard SQL. If you've read any of his books you'll see how portable his techniques are. SQL was meant to be a STANDARD, one that could be implemented by many vendors. OK, I'll grant that the CLR is a standard (http://www.mono-project.com, anyone?), but it's not a SQL standard.
Really, the idea of vendor neutral SQL code is being destroyed, and it has been since the beginning. The main reason for this is:
1) Vendors straying from the standard to implement "custom" functionality
2) Lazy developers, not willing to take the extra time to write portable code.
I'm as guilty as the next guy, as you can tell if you see the code I post on this site or elsewhere. But he's right on the money...the CLR is a bad thing for SQL Standards. I really think the only answer will be a set of vendors commited to supporting standards instead of locking in their customers. I look to mySQL and the Open Source movement as the brightest hope, but I'm worried.
cl
Signature is NULL
-
I think PostgreSQL and Firebird are both much brighter hopes than MySQL...
But either way, SQLCLR is a lot more interesting than the SQL/PSM standard that Celko is pitching as the better alternative. Have you checked that out?
To me it seems as if this isn't about customer lock-in so much as it's about providing something that's useful to customers. If SQL/PSM were so wonderful, someone would have implemented it by now; indeed, no one has, and almost every vendor has some sort of procedural language support at this point.
--
Adam Machanic
whoisactive -
SQL CLR is Microsoft specific (right now), while SQL/PSM is an accepted SQL Standard. I grant that support for SQL/PSM has been sparse, but I don't see that as a problem with the standard, it's a problem with the vendor implementation. While SQL/PSM may not be "interesting", it is quite functional.
You are right that PostrgreSQL and Firebird are great products that provide quite full ANSI SQL-92 support. They haven't been getting the same growth and press as mySQL, which is why I named that as the best hope. Really, the standards need to be supported by a number of vendors, otherwise portability isn't that useful.
cl
Signature is NULL
-
MySQL provides very little in the way of ANSI compliance, and lacks basics like constraints. Be careful when you rant on compliance and then mention one of the least compliant products on the market.
And what's so "functional" about a standard no one has implemented? Don't you think there's a reason no one has implemented it?
--
Adam Machanic
whoisactive -
The reason no one has implemented standards is simple - it isn't in the best interests of their business. Does anybody believe Microsoft (or Oracle) gives a rip about how well their products lets you get along with their competitors? Anytime standards get in the way of profits, standards will lose.
Bob
SuccessWare Software -
mySQL offers a fairly high level of compliance:
http://dev.mysql.com/doc/mysql/en/compatibility.html
http://dev.mysql.com/doc/mysql/en/differences-from-ansi.html
I don't know why you think mySQL doesn't offer constraints, cause it does:
mySQL is a work in progress...so be careful what you know is up to date. (Have you actually used it?)
I'm not trying to start a fight, and I'm not being flippant.
Signature is NULL
-
Bob: I haven't seen support for it in open source products either, unless I've missed something. Have you seen this support?
Calvin: What constraints? No foreign key support in the current version. The version that's in beta appears to have it, so that will be better... But until now there's been no support. No mention of CHECK constraints anywhere. Looks like they added PKs since the last time I saw the product, but no FKs means that PKs aren't worth much.
--
Adam Machanic
whoisactive -
"Starting from MySQL 3.23.44, InnoDB features foreign key constraints." NOTE: Current recommended production version is 4.1
http://dev.mysql.com/doc/mysql/en/innodb-foreign-key-constraints.html
The mySQL version of a check constraint is called a "set" or "enum" constraint (5.02 or higher). Grant you, it doesn't offer the exact same functionality, but I'm sure more features are coming.
http://dev.mysql.com/doc/mysql/en/constraint-enum.html
Signature is NULL
-
We should probably end this conversation soon since this isn't a mySQL forum
-- but I was under the impression that InnoDB is a totally different product that goes on top of mySQL... Is that wrong?--
Adam Machanic
whoisactive -
Adam,
http://dev.mysql.com/doc/mysql/en/innodb.html
You can use this instead of MySQL's own MyISAM stuff. However I think most people using MySQL use MyISAM and I also think that most ISP's (at least mine) does not allow to create InnoDB tables.
Can't find the link right now, but I remember a discussion between folks from MySQL and, I think it was Fabian Pascal about whether MySQL is a relational database at all or not. IIRC, lacks MySQL some of the very basic functionalities of a RDBMS. If someone can post that link again, that would be very good!
Anyway, get a server, Linux, Apache, MySQL and PHP and you have the typical low-budget webserver. I guess that's why MySQL became that popular. And for what I need it, it's absolutely okay. For me it's nothing more than a data storage tool. I certainly would *very* carefully evaluate it before using it for Enterprise development. But that's just me.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Frank,
Exactly what I've heard (I've read the Pascal debate), and seen from personal experience talking to people who use mySQL (quote: "we just need to store some data; nothing fancy!") ... I still don't get why these people wouldn't use PostgreSQL instead, which has all of the features we know and love
--
Adam Machanic
whoisactive -
I also come from a mixed background with experience in both programming (primarily in VB) and SQL (Specifically SQL Server 7 & 2000) and I see the CLR integration as another tool in my development arsenal. Nothing more, nothing less. As a developer it is my responsibility to write good code that gets the job done in an efficient manner and that is as portable as possible and as easy as possible to enhance when changes to it are needed. This same mentality applies to query construction for SQL Server. The CLR is a tool in the SQL Server 2005 toolbox that will give me one more option to get my job done.
There will be times when using the CLR is the easier to implement solution that is also less efficient then a true Set Based T-SQL approach. When that happens do I choose the easy path or the proper path? It will be my responsibility to make the right decision and no one else. If I choose poorly then I condemn myself and no one else however I will have an incentive to go for the right decision as often as possible for fear of replacement when my poorly written code backfires.
My question to those who feel the CLR should not be an option is this, if I choose to use the CLR when it is not the best answer how is that any different then writing poorly constructed queries out of a need of laziness or because of a time constraint or some other factor? At least with the CLR I have another option to get the job done and there will be times, even if they are but a few, where the complexity of the solution will be best handled by the CLR.
The true threat has been, currently is and always will be the user and not the technology. If we decide to use technology in a poor manner then we will pay the price for that. If we use technology the right way then we will be rewarded. If the technology being offered truly has no valid use then it will die out, perhaps slowly but it will eventually die out or evolve to a useful state. In the end its always been up to us as developers to do the right thing. Placing the blame on the technology is no more then denying to except responsibility for our own actions. In my line of work there are those around me who choose to produce code in a manner that allows them to produce more in less time then I. I have made the decision that regardless of pop culture in the development community that I will take the time to do it right regardless of others. While this may make me less popular at times I at least know that when I turn off my computer and go home that I have done my job to the best of my ability and have not taken any shortcuts that sacrifice the quality of my work. In the end this attitude does pay off and the CLR or any other new technology can not and will not change the way I view how I should write code.
Ed
Kindest Regards,
Just say No to Facebook! -
I'm not suggesting we should be just database geeks or stand Canute like before the .NET tide.
I'm facing a situation where I have inheritted a mission critical system that was implemented by someone who liked to carve himself a secure job niche by using non-company standard technologies.
Never mind how it came about the sorry fact is that he did it and now I am having to pick up the pieces.
I desperately want to expand my experience into .NET. To become a mentor in something takes time and if someone starts blasting away at my databases in something I don't know yet then how am I going to maintain control of the business asset.
It is the role of the DBA to maintain control over their databases. That means that certain standards have to be adhered to.
.NET allows coders to write in many languages and although there are only so many ways you can write an IF statement or do a FOR loop every language has its subtleties. It is those subtleties that take the time to learn and to appreciate the impact that they will have.
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply