 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / DB2 Topics / March 2005SQL Server 2005 - Still not upto it
Trolling before someone else does -) http://www.eweek.com/article2/0,1759,1776048,00.asp Oh geez. I guess a car must be a death trap if no crash test reports are available six months before release, eh? > Trolling before someone else does -) > > http://www.eweek.com/article2/0,1759,1776048,00.asp Interesting article but a couple months back Infoweek carried an article that stated that the beta version was missing the optimizer. If I was in charge of the project I would want the otimizer beta tested also, but just because I think all the code should be beta tested does not mean MS's approach is wrong. It does however raise questions about why the beta engine is claimed to be non-optimizing. It could be that MS is having trouble getting the optimizer to work correctly, or they could be planning to spring a surprise. In another few months we will find out. -- Mark D Powell -- > not mean MS's approach is wrong. It does however raise questions about > why the beta engine is claimed to be non-optimizing. It could be that > MS is having trouble getting the optimizer to work correctly, or they > could be planning to spring a surprise. Personally, I think there is some value in getting the functionality perfected before you start optimizing performance. It's the same approach I take with many of my development efforts. Of course, when you get down to the final few tweaks, the impact of each can affect the other in minor ways. But there was a large portion of completely new functionality in this release, and I'm glad they focused on having new functions return the right answer, rather than return the wrong answer a little bit faster. But I agree, we will have to wait and find out. eWeek's statements that because no TPC-C score is available now, performance in the release will suck, are just asinine. A The article said ... "TPC benchmarks are one of several criteria customers use to choose a high-end, scalable database" Guess we can all chip in with how knowledgeable the writer is about how the database selection process is, eh? <<Personally, I think there is some value in getting the functionality perfected before you start optimizing performance. It's the same approach I take with many of my development efforts. >> This statement I disagree with. I have seen to many software projects fail (not just RDBMS project's, but others, as well) because performance was not designed into the application from day one. Usually performance is directly related to application design. I can create a Fred Flintstone car tomorrow that I move with my legs that is totally functional, but it probably wouldn't sell too well. Regards, Steve > This statement I disagree with. That's fine. Your analogy of a Flintstone car is incorrect, however. I wouldn't consider a car that you "drive" with your feet fully functional. In addition, you failed to identify that it's not a one-or-the-other thing. You do both, but fine-tuning performance (not designing for general performance, that's always a goal when implementing the design from the start) doesn't need to be done until you're sure the tool does what it's supposed t. It's just a different approach, not a right/wrong thing. Maybe the software projects you've seen fail just didn't have the right people.  SignaturePlease post DDL, sample data and desired results. See http://www.aspfaq.com/5006 for info. >>This statement I disagree with. > [quoted text clipped - 8 lines] > It's just a different approach, not a right/wrong thing. Maybe the software > projects you've seen fail just didn't have the right people. As Stephen, I have to disagree with that you. Delivering performance within the defined constraints (the system must be able to support X transactions within m seconds; this transaction may not take longer than n seconds...; the system must meet this criteria for the next y years with a growth rate g in datavolume/transactions) is a functional requirement. Either you meet that requirement by designing for it, or you don't. Sometimes it might be impossible to meet some requirements (Cary Milsap has a very good example in his book on Oracle performance) but you don't tune after the fact. And the analogy of a flintstone car holds perfectly well. Look at your own statement: > I wouldn't consider a car that you "drive" with your feet fully functional. Well, who said a car has to have an engine? My four-year-old son would be perfectly happy with the flintstone edition. Oh, well let's finetune and add an engine. Damn, now we need something to keep the fuel in. No worries, I can fix that.... If the requirement is that the car must reach a minimal speed you can either let it roll down a hill crying "See? it can reach 20 MPH, I didn't know you wanted to go uphill" or you design the car to reach that speed everytime upfront. My 2 eurocents Holger You both have missed my distinction between "designing for performance" (which should be a given in any development effort) and "fine-tuning performance" (which doesn't need to be a cart in front of the horse). So go ahead and disagree with me all you like, but I don't think we're as far apart as you're implying. > >>This statement I disagree with. > > [quoted text clipped - 35 lines] > My 2 eurocents > Holger > You both have missed my distinction between "designing for performance" > (which should be a given in any development effort) and "fine-tuning > performance" (which doesn't need to be a cart in front of the horse). > > So go ahead and disagree with me all you like, but I don't think we're as > far apart as you're implying. It's probably because I don't consider fine-tuning an developement thing: If an application is designed and written for optimal performance, then and only then fine-tuning may happen but, at least for database projects this goes more in the direction of the administrators by balancing the different pools correctly, spreading I/O etc. thus getting the most of the given hardware. But since most developers I've seen lately fail on the design stage, there is not much so-called fine-tuning going on. And if you don't mind, I'll quote your original statement: > Personally, I think there is some value in getting the functionality > perfected before you start optimizing performance. It's the same approach I > take with many of my development efforts. I don't see any fine-tuning mentioned here, nor did you indicate that design for performance was part of getting the functionality perfected. So I'll happily disagree with you and this will be my last post because I just realized that we're crossposting which I don't do. Meet me at c.d.o.s if you like. Cheers Holger >> Personally, I think there is some value in getting the functionality >> perfected before you start optimizing performance. It's the same approach I >> take with many of my development efforts. > > I don't see any fine-tuning mentioned here, Sorry, the word I used initially was "optimizing." > > You both have missed my distinction between "designing for performance" > > (which should be a given in any development effort) and "fine-tuning [quoted text clipped - 30 lines] > Cheers > Holger Agree, Performance is part of the day to day job and not something you "bolt on" later. That said, everything is a balance, but one should keep focus on performance as a day to day part of the job. Jim > Agree, Performance is part of the day to day job and not something you "bolt > on" later. That said, everything is a balance, but one should keep focus on > performance as a day to day part of the job. I give up. Clearly I do not advocate throwing performance concerns out the window and focusing only on the features until the very last minute. I was merely trying to point out that there are different aspects of performance tuning... from overall, sensible design, which should go without saying in this crowd absolutely has performance elements involved (even at whiteboard / paper napkin stage), all the way to fine-tuning once the functionality is complete. And all I was doing was hypothesizing that this is the way Microsoft is proceeding ... that of course they have performance in mind throughout the design phase (in fact I know that they do), but it makes little sense to release TPC-C numbers now when the functionality isn't complete and they haven't approached the fine-tuning side of performance. Since everyone continues to disagree with their perception of my initial comment rather than my explanations thereafter, I'm going to bow out and let you all keep feeling good about yourselves. But please, go on, keep disagreeing with your perception of what I was implying in my first response, rather than what I've been forced to elaborate multiple times because I can't make myself clear enough for you. Enjoy. SignaturePlease post DDL, sample data and desired results. See http://www.aspfaq.com/5006 for info. >>>This statement I disagree with. >> [quoted text clipped - 44 lines] > My 2 eurocents > Holger automotive performance analogy reference: www.overhaulin.com they make sure the chasis and drive train can handle the high-performance engine during the spec & design phase ++ mcs > Personally, I think there is some value in getting the functionality > perfected before you start optimizing performance. It's the same approach I Functionality is what you sell the customer. Performance is what keeps it sold. The former can be handled with prototype code. While I agree with Aaron's sentiments in other fibres in this thread (about designing with performance vs fine tuning), too often organizations simply throw the prototype over the wall and expect THAT to be 'fine tuned'. Further, there are a lot of people who believe that designing can be vendor-independent, not accepting the fact that beauty (the SQL) is only skin deep. However, the internal workings can, and do, make a huge difference in how the design needs to be approached. /FGB > Interesting article but a couple months back Infoweek carried an > article that stated that the beta version was missing the optimizer. I'd like to see that article. :-) The execution engine cannot execute an SQL query. It needs a execution plan. The execution plan is generated by the optimizer. Now, the optimizer might not have been as polished at that point in time as it will be in the released version, but that is of course the case with all parts of a product. SignatureTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ http://www.sqlug.se/ > Interesting article but a couple months back Infoweek carried an > article that stated that the beta version was missing the optimizer. [quoted text clipped - 7 lines] > > -- Mark D Powell -- > I'd like to see that article. :-) > The execution engine cannot execute an SQL query. It needs a execution plan. The execution plan is > generated by the optimizer. I was going to make the same comment but I think the difference between "the optimizer" and "an optimized optimizer" might have been lost. > Now, the optimizer might not have been as polished at that point in time as it will be in the > released version, but that is of course the case with all parts of a product. Right, I guess most people have forgotten that we're not even at beta 3 yet. > Interesting article but a couple months back Infoweek carried an > article that stated that the beta version was missing the optimizer. Meaning what, that there was no optimizer, in which case I'd not believe the article. That it was the sql 2000 optimizer, in which case I'd not believe the article - the read-committed level wouldn't work, period. That it was not the completed optimizer, in which case the article is probably correct, but is stating that the beta software currently available isn't the final product. Like others, I'd like to see the article. SignatureNiall Litchfield Oracle DBA http://www.niall.litchfield.dial.pipex.com You forgot the bit where they ask 12 unattributed individuals who say off the record that they are seriously considering switching to Ford instead... It of course true that we still don't know how an unreleased product runs software that no-one uses to do anything other than generate marketing. I'll not sleep easy tonight no sir. SignatureNiall Litchfield Oracle DBA http://www.niall.litchfield.dial.pipex.com > Oh geez. I guess a car must be a death trap if no crash test reports are > available six months before release, eh? > >> Trolling before someone else does -) >> >> http://www.eweek.com/article2/0,1759,1776048,00.asp Not trying to go off a tangent, but when I think SQL*Server, I remember the importance of semantics, as does Oracle. See my SQL*Plus session below:: SQL> drop table t; Table dropped. SQL> create table t(t_pk number(11) not null primary key,name varchar2(40)); Table created. SQL> create or replace procedure invalid_proc 2 is 3 begin 4 insert into t(wrong_column,wrong_column_again) values (1,'Arun'); 5 end; 6 / Warning: Procedure created with compilation errors. SQL> show errors Errors for PROCEDURE INVALID_PROC: LINE/COL ERROR -------- ----------------------------------------------------------------- 4/1 PL/SQL: SQL Statement ignored 4/28 PL/SQL: ORA-00904: "WRONG_COLUMN_AGAIN": invalid identifier This behavior is expected. However, when I worked with SQL*Server a few years ago, it wouldn't check for semantics. So, the above procedure would actually compile in SQL*Server, and I wouldn't know this procedure is wrong until I call it. I posted my observation on one of Tom Kyte's useful discussions, http://asktom.oracle.com/pls/ask/f?p=4950:61:::::P61_ID:3512483632553 , hoping someone would chime in and say "You're wrong. SQL*Server does check for semantics". Instead, someone posted saying this behavior still exists in SQL Server 2000. So, optimization aside, how about an engine that can compile? Regards, Arun You code adapted for SQL Server: create table t(t_pk int not null primary key,name varchar(40)); create procedure invalid_proc AS insert into t(wrong_column,wrong_column_again) values (1,'Arun'); Above fails with error: Server: Msg 207, Level 16, State 1, Procedure invalid_proc, Line 2 Invalid column name 'wrong_column'. SignatureTibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ http://www.sqlug.se/ > Not trying to go off a tangent, but when I think SQL*Server, I remember > the importance of semantics, as does Oracle. See my SQL*Plus session [quoted text clipped - 42 lines] > Regards, > Arun Thank you Tibor. I found a machine running SQL Server 2000, and was able to reproduce the behavior you posted. I misunderstood the checkmark button, thinking it checks both syntax and semantics when it appears that both checks occur when the user clicks the green play button, and not the checkmark button. At this point, the only difference I observed is that SQL Server would not store the invalid_proc procedure in its data dictionary, whereas Oracle will, and mark it invalid. Regards, Arun |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.