January 26, 2009 at 2:46 pm
Jeff Moden (1/23/2009)
Matt Miller (1/23/2009)
As for me, I would settle for actual, complete, documentation of the new features added as they are added. Functionality changes, "this doesn't work in x version anymore", some GOOD examples.But hey - full XML support, ordered sets and windowed functions, and the ability to manage committed transactions would be awesome too....:)
And Santa, when you read this - I could REALLY use that home Cray. I PROMISE I'll behave....:)
Heh... Cray... showing your age again, Matt. 😛
perhaps - but it's not as crazy as it sounds. Did you catch this recently?
http://blogs.zdnet.com/microsoft/?p=1589
I'll take 3 of those!:cool::w00t:
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 26, 2009 at 2:47 pm
rog pike (1/26/2009)
Jeff Moden (1/26/2009)
I absolutely agree... and one of my favoritie proprietary pieces of code is UPDATE FROM... if that were not available, you'd end up having to do updates like in some other RDBMSs... a pot wad of correlated subqueries in both the SET list and the WHERE clause. Yeah, yeah... MERGE fixes a lot of that problem, but UPDATE FROM has always made it super easy to do joined table updates in SQL Server. And, the syntax is still simpler on the Mark-1 Eyeball than merge (IMHO).Interesting. Here's an opposing view:
'Let's deprecate UPDATE FROM!'
http://sqlblog.com/blogs/hugo_kornelis/archive/2008/07/07/5515.aspx#7702
CLR:=Can't Lick Rbar
Visit here for a gentleman's agreement to model relationally:
He's not actually contradicting Jeff. He's saying he prefers Merge over Update From. Honestly, having played with SQL 2008 (but not yet having it in production), I think he's right that it will be a valid replacement for Update From, once it's in use in more places.
- 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
January 26, 2009 at 4:19 pm
rog pike (1/26/2009)
Jeff Moden (1/26/2009)
I absolutely agree... and one of my favoritie proprietary pieces of code is UPDATE FROM... if that were not available, you'd end up having to do updates like in some other RDBMSs... a pot wad of correlated subqueries in both the SET list and the WHERE clause. Yeah, yeah... MERGE fixes a lot of that problem, but UPDATE FROM has always made it super easy to do joined table updates in SQL Server. And, the syntax is still simpler on the Mark-1 Eyeball than merge (IMHO).Interesting. Here's an opposing view:
'Let's deprecate UPDATE FROM!'
http://sqlblog.com/blogs/hugo_kornelis/archive/2008/07/07/5515.aspx#7702
CLR:=Can't Lick Rbar
Visit here for a gentleman's agreement to model relationally:
Please... not the same old thing, again... he's suggesting that MERGE will replace it. It will... but why bother?
I do, however, like your acronym meaning for CLR. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2009 at 4:21 pm
GSquared (1/26/2009)
rog pike (1/26/2009)
Jeff Moden (1/26/2009)
I absolutely agree... and one of my favoritie proprietary pieces of code is UPDATE FROM... if that were not available, you'd end up having to do updates like in some other RDBMSs... a pot wad of correlated subqueries in both the SET list and the WHERE clause. Yeah, yeah... MERGE fixes a lot of that problem, but UPDATE FROM has always made it super easy to do joined table updates in SQL Server. And, the syntax is still simpler on the Mark-1 Eyeball than merge (IMHO).Interesting. Here's an opposing view:
'Let's deprecate UPDATE FROM!'
http://sqlblog.com/blogs/hugo_kornelis/archive/2008/07/07/5515.aspx#7702
CLR:=Can't Lick Rbar
Visit here for a gentleman's agreement to model relationally:
He's not actually contradicting Jeff. He's saying he prefers Merge over Update From. Honestly, having played with SQL 2008 (but not yet having it in production), I think he's right that it will be a valid replacement for Update From, once it's in use in more places.
Yep... understood... when they get all the windowing functions done correctly, then they can have all the fun they want with MERGE. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2009 at 4:23 pm
Actually... I take that back. They need to leave UPDATE FROM the heck alone so that we can still use the "Quirky Update" for "data smears" even if they do get the windowing functions to work correctly. And, there are certain forms of ranking that those windowing functions will never be able to do.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2009 at 5:42 pm
Update using the FROM clause violates JOINs are idempotent rule in relational algebra.
Microsoft needs to provide Proclarity as MDX query builder in Kilimanjaro because as Ralph Kimball says these are just MDX scripting tools to bundle it with SharePoint makes SharePoint convoluted because it crosses too many skill sets.
SSIS needs connector to all RDBMS and automate templates so data can be used RDBMS vendor agnostic.
Kind regards,
Gift Peddie
January 26, 2009 at 5:53 pm
Gift Peddie (1/26/2009)
Update using the FROM clause violates JOINs are idempotent rule in relational algebra.
Heh... ummmm... so what? Cursors violate the whole idea of a database but they continue to "live". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2009 at 8:35 pm
Gift Peddie (1/26/2009)
Update using the FROM clause violates JOINs are idempotent rule in relational algebra.
If that's true I should think a 'multi-row' trigger suffers the same fate. Perhaps this is a case of two wrongs make a right:)
January 26, 2009 at 8:48 pm
Jeff Moden (1/26/2009)
Cursors violate the whole idea of a database but they continue to "live". 😉
One would think such an idea would be more appropriate describing vermin. Please leave my poor cursor alone (they are sufficient and even necessary in a relational system) 🙂
January 26, 2009 at 9:18 pm
I would love to be able to pass in an array variable as a variable and not some hacked delimited list that requires processing to rip it apart into a temp table/table variable.
I also dislike how convoluted they made creating OLAP cubes in AS2k5. In the 2k interface I could get a cube going in no time flat, now it's a pain in the proverbial.
Admittedly I have had no formal training for AS2k5, but I shouldn't have to; the interface should be intuitive enough that I could get a basic cube going very quickly, requiring training (of some kind, web, classroom, etc.) only for the advanced areas.
O' and the usual re: date functions (first date of month/last day of month, etc. without doing weird datepart/add combo functions)
-d
January 26, 2009 at 11:02 pm
In most cases Triggers are obsolete but most important Triggers were created by the RDBMS vendors to enforce business rules before added to ANSI SQL so like most things in the physical the RDBMS vendors implementation is specific to each RDBMS.
Kind regards,
Gift Peddie
January 28, 2009 at 12:07 pm
Thanks. That's exactly what I wanted.
January 29, 2009 at 11:48 am
From my perspective...
I have been a database developer, DBA, designer and architect for (too) many years on all major DB platforms. I architected and implemented a 7TB data warehouse as early as 1995, and my largest data warehouse was over 300TB. I was a road warrior data warehouse/data migration consultant to primarily Fortune 500 companies for 15 years. I currently manage Clinical Research Informatics databases for the Air Force Chief Medical Information Officer.
I have worked with SQL Server since it's introduction. In looking at the shortcomings of SQL Server, it is obvious that most people here have a list of quite detailed items they would like changed or added. While I agree with most of those suggestions, and feel they would greatly improve the product, my problems with SQL Server are more endemic.
1) It requires MS Windows (or BLOATWARE personified) and this is a huge issue for me. If it ran on Linux or Unix, it would undoubtably be a far faster DB platform.
2) Most error messages it produces have NOTHING to do with the actual error encountered. This just seems part of it's persona. Books Online is probably the worst, most badly organized reference ever conceived.
3) Unlike statements I saw in this discussion, my experiences installing SQL Server (especially on a clustered environment) were awful! As and example: When installing Integration Services, the correct DCOM settings frequently are not done, meaning no non-admin users can connect. The only mention of this, and instruction for fixing it, is in MSDN, not in Books Online where you would expect it to be. What does the Developer Network have to do with basic product installation?
4) CLR assumes you want to use OO code, which is highly inefficient for procedural operations. SQL is a procedural language and does what it does very efficiently if you actually know how to write it. Occasionally you need more logic capabilities, and it would be nice to be able to use procedural C in a direct, easy to use interface, similar to Oracle's PL-C.
5) The comments about a change of paradyme cut two ways. Yes, changing over to an Oracle platform would seem strange to most people who only have experience with SQL Server or it's parent DB, Sybase (since that's where Microsoft originally got the SQL Server RDB foundation). Having said that, most of the companies in the Fortune 1000 are mixed platform shops. If you worked on DB2/UDB, Oracle, Informix, Teradata or any of the other major DB platforms, it is SQL Server that is the odd man out, with it's quirky T-SQL, crappy bulk loading tools, buggy ETL, etc. Most of the database platforms mentioned pre-date SQL Server. Among the other platforms, there is a uniformity, especially in SQL standards and database admin tools, that define a set of recognized industry standards. These standards were there first and existed for a reason, but Microsoft insisted on deviating from them.
January 29, 2009 at 4:11 pm
First Windows is bloatware, though now we have Server Core, which is stripped down and SQL is supposed to work on that. As far as *Nix, there are some fundamental differences in how Windows is designed and rather than support multiple platforms, MS has concentrated on growing things wider. In my view, they've done a better job of that than other vendors.
2. For error messages, I've actually found many that do describe the problem. At least to me. If you find those that don't, you can drop a note to the BOL team with your logic. Those drop into a Q and updates are made to BOL over time.
3. Can't help you here. I rarely have issues installing. Chances are there is some "tribal knowledge" that I don't pay attention to and isn't well documented. Again, send feedback in.
4. Not sure this is true, need someone else to chime in here. You might be right.
5. I've seen differences. Oracle deviates from standards, as do other platforms. I'm not sure that there is a lot of similarity and while I haven't used other ETL tools, the ones with SQL don't seem buggy to me. Seem to work pretty well in fact.
Not saying you're wrong, but I suspect that there's a different paradigm you see as someone working on other platforms that those of us that exclusively work with SQL have. Maybe we're not aware of what we're missing, or maybe we have a different view and so SQL Server works well for us. Hard to tell.
The only thing I can say is that a lot of people I know that have a lot of Oracle or DB2 experience and SQL Server experience, prefer SQL Server.
January 29, 2009 at 5:51 pm
Irish Flyer (1/29/2009)
4) CLR assumes you want to use OO code, which is highly inefficient for procedural operations. SQL is a procedural language and does what it does very efficiently if you actually know how to write it. Occasionally you need more logic capabilities, and it would be nice to be able to use procedural C in a direct, easy to use interface, similar to Oracle's PL-C.
The CLR is Dot.Net. It's your assumption that you can't write procedural code in Dot.Net. Well, you can. I do it all the time. Watch all the developers gag and choke. 😛
The calling interface is a function and in OO terms that's a method. But you are not defining a boat load of properties and then calling a method. You are calling a method (function) and passing some parameters. Inside your code you can be as toady as any COBOL programmer. You can put all you data and code inside the main function and you don't have to call anything else.
There are reasons that developers use objects and define them in classes. So what?
I sort of get putting application like functionality into SQL. It's a convenient way to put everything in a central place.
ATBCharles Kincaid
Viewing 15 posts - 61 through 75 (of 81 total)
You must be logged in to reply to this topic. Login to reply