SQL Server Needs Incremental Updates

  • Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/bknight/s

  • A good idea, but I'm not sure I agree. Unless there is some pick and choose and a subscription model. Upgrading our DBs is a major challenge, both in time and resources (testing) and politically (money), so having the releases fewer and father between is something i like. If Yukon released in Q3 or 4 of this 2003, there's no way we'd upgrade for a couple years. However with the release next year, it's an easier sell to start testing.

  • I don't like the idea of a huge and radical change to something as fundamental as the SQL.

    Don't get me wrong, I'm enthusiastic about SQL2005 its just that the learning curve, from what has been said so far is going to be pretty steep.

    That said a release of a database tends to be pretty major, and therefore it is not something you want to be doing every year.

    I like the way that Microsoft have released the Reporting Services as a bolt on to SQL2000.

    It would be good if the various components of SQL Server were available as bolt-ons so if a huge upgrade occurs you simply upgrade the bolt-ons as and when is appropriate.

  • The learning curve will be steep, but I must admit this is the first time Microsoft has involved developers from ISVs from all over the world in beta testing and design input of any product (so they said !!)

    I was on the Ascend Phase 1 training program (Developmentor run) in in Germany in Jan of this year and Yukon will be a mjor change, but it's a major change for the better and I really don't think it could be done in stages. Saying this the new veriosn of Reporting Services was available as a stand alone beta called Rosetta. It's now part of Yukon.

    If I was a database developer or DBA I'd spend the next year learning C# and .Net and becoming more familiar with XML. TSQL will still be the language of choice for set based querying but I think C# will become more prevalant as it's a much richer environment to work in.

     

    cheers

    dbgeezer

  • I completely agree with Brian.

    There are a number of issues here...

    1) Comparisom with other vendor's release stategy.

    My main experience is with DB2.  When IBM are near to making a new DB2 release RTM (GA in IBM terminology), they will make known to technical conferences the major line items in the subsequent release  (Vnext), and those line items that will not be considered until after Vnext is RTM.  This gives about a 6-year plan for the product's future.  They also have about a 2.5 - 3.5 year release cycle and regular (approx quarterly) service packs.  The shorter release cycle means an easier upgrade path, with the +1 release supporting everything that has not been deprecated in the current release.

    All this allows sites to prepare far more for what is coming, and the regular SPs help greatly in budgeting manpower for maintenance.

    2) Credibility of vendor

    When a vendor makes it known they hope to release a major update in 3 years, and it actually takes 5 (e.g. SQL Server 2005), you start to wonder about their ability to deliver for the future.

    If Microsoft continue to deliver major upgrades a year or two after making their initial plans known, it will have a corrosive effect on their market share, regardless of final product quality.

    3) Size of feature set

    SQL2005 is massive compared to SQL2000, but SQL2000 is not the main competition.  Compared to its main rivals, SQL2005 will deliver VERY little that will not already be in other products.

    For SQL2000 people, the feature set size is a problem, especially for DTS.  I think it is a major error on Microsoft's part the SQL2005 DTS does not have source compatibility with SQL2000 DTS.  Run time compatibility only is simply not good enough for adjacent releases.  We will have to re-engineer all our DTS at the time of migrating to SQL2005, to ensure that any further troubleshooting or maintenance of a single DTS package will be compatible wih the other packages it works with.  This will add perhaps UKP 200,000 to our SQL2005 upgrade costs, due to the amount of DTS we have.

    4) The SQL2005 legacy

    The frightening aspect of a 5 year wait for SQL2005 is the prospect of a further 5 year gap for the next release. 

    In a number of areas, SQL2005 technology will be inferior(*), and while its rivals move further ahead with their 3-year release cycles we will be stuck with what we have until maybe 2010.  By then, we will either have a release that makes SQL2005 seem minor, or SQL Server will remain permanently and visibly many years behind the times.

    (*) Areas where SQL2005 is inferior include continued index locking for insert/delete activity, single dimension only index clustering, slow adoption of SQL standards changes, etc.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • I believe that part of the situation MS has faced is that SQL Server has been playing catch up for a long time. Even though I use SQL Server 2000 extensively now in my day-to-day development, its weaknesses have been very evident. Some might have been addressed in service releases, while others were of a nature that would have made that difficult.

    Looking at the feature set of SQL Server 2005 suggests that with a few notable exceptions they have caught up to the marketplace, and I suspect that after this release, we will see more of the missing elements provided via service releases on a tighter schedule. I am only guessing, but I believe that what took so long with this release was that some fundamental changes had to be made to the core of the server to open that option.

    It is also important to remember, though, that they did release some major feature extensions during the wait (such as Reporting Services and the XML Services packages). What has been lacking has been an integrated release that made some of these disparate parts accessible.

    Let's hope that with this coming release it is done right.

  • Personally I think they should put the beta out for the public to download, or request since there are some many new features. The only people who will be ready are those lucky enough to be on the beta. I agree too much to absorb in one go and even when released it will be a year before most actively consider. A public available beta will allow many to adopt faster with more confidence.

  • Inded.

    Although i WAS on the beta and am now not. I've moved companies.

    Ironically the company i worked for were really lucky to be on the ascend program and they're not interested in yukon at all. they'll probably deploy it but are 'too busy' to follow the beta process though, which is a shame when there are companies out there that that would be interested.

    Rant over. My boss was a nice guy. Really he was.

    cheers

    dbgeezer

  • I think Brian has the right approach, but for a different reason.  Part of the process of an upgrade is the testing that MUST occur for all of your applications that use the database.  Testing against the huge set of features in the SQL Server 2005 release is going to be a mammoth task that, frankly, most companies are going to gloss over or skip altogther.  Having a smaller feature set allows that testing to be much more concise and manageable by an already downsized and overworked database admin and development staff.

    MW

  • I agree with Brian.  In my case, it will take at least 6 months to test, wait for a service pack, test again and then get management buy in.  By that time, it will end up being more of a 2006 implementation. 

    We were able to upgrade from SQL 7 to 2000 in a very shore time frame due to the smaller amount of changes.  I just don't see how that would be possible here, unless this is one of the few times when Microsoft get's it right the first time.  Their track record on first releases is not good.

    As Steve Brett said: rant over

  • I agree that in order to compete with other DBMS vendors MS needs to come out with releases often. Five years is too long a time especially when SQL Server is lacking in security features. But on the other hand constantly releasing new versions mean that companies need to upgrade constantly which is an inconvenience when the older version becomes unsupported by MS.

  • Could you give examples of the "notable exceptions"?

  • Not having had time to dig into all the raw details of all the available information, I may be mistaken, but it does seem that they will still lack some low-level control over indices and that their analysis tools will still be limiting in some regards as to the management of analysis cubes, etc. I admit to some ignorance on the correctness of those specific feature criticisms though, which have come to me indirectly via database administrators whose experience with recent versions of Oracle and DB2 have led them to conclude that these features are lacking. While I trust their opinions, it in no way makes them correct.

    Probably, in retrospect, I should have removed the word "notable" from that previous post, since I'm not sure that even giving merit to these critiques makes them "notable" in any way. Speaking solely from my perspective, I suspect SQl Server 2005 will be feature-rich in a way that take sme many month to even dream up an implementation that taxes it.

    I suppose some days the light bulb in my head is brighetr than others.

  • I would be curious to know where Sybase ranks along side SQL Server, ORACLE, DB2 etc.

    I have colleagues who are using Sybase on a particular project and because both SQL Server and SyBase come from the same parentage I get asked a lot of questions.

    There are a number of times when my Sybase colleagues have to say "I'm sorry but we don't have that feature within Sybase".

    The over-riding impression I have gained from these comments is that if SQL2000 is jurassic then Sybase is still primeval ooze.

    Would anyone care to comment on this?

  • David,

    I totally agree with you about Sybase being primeval ooze.  With the  upgrade to Sybase 12.5.1 they just added scheduling services for jobs.  Something that SQL Server has had for the last 5-7 years.  I have been working with Sybase for the last 4 years and I have always thought that Sybase was lacking.  What it isn't lacking is speed.  Running on Sun Solaris 9 we are able to run the 64 bit version of Sybase with great speed.  We are also able to take advantage of 24Gb of ram for caching.  Compressing dump files without having to go through a third party application as well.

    There are alway going to be give and takes for both of these applications.  If we can get to the 64 bit version of SQL and Win2003 we would gladly switch over.

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic. Login to reply