Portability

  • I saw this article by Ralph Kimball on OLAP v relational structures and I found it very interesting. One of the prominent proponents of data warehousing and OLAP structures takes a look at the pros and cons of using either structure for Business Intelligence.

    One of the things that Mr. Kimball mentions is the portability of SQL as being an advantage and the non-portability of MDX/OLAP solutions being a disadvantage. I think that's interesting and I didn't realize the MDX wasn't a standard. One more reason to think BI OLAP solutions will be a niche market for awhile.

    I did, however, agree with 4th point: MDX may be too complex for IT personnel to write or understand. I agree with this one and I completely believe this is a problem. I understand SQL pretty well, not like Itzik Ben-Gan, but I can think in sets. I have met many DBAs that couldn't, or struggled to understand set based queries that were anything but simple 2 or 3 table inner joins.

    However I think that MDX is much more complex and I don't know that most DBAs will learn to manipulate it well. New tools will help and they might extend the reach of OLAP type applications to more installations, but I still think a successful application needs people that understand it well, inside and out.

    Maybe I'm just too inexperienced, and I'll certainly admit that. At the Microsoft BI conference, I met a great many people who were working with some very complex OLAP solutions based on Analysis Services and I was surprised by what they'd done.

    I'm just not sure if they were the only 2000 people that knew Microsoft OLAP or they represent 200,000.

  • Don't believe there are many people out there with great MDX skills. Still a very specialised area. From my experience most BI developers do not have great MDX skills, and it is only the exceptional few that do. It is something that is growing though.

    Saying that there is no requirement for MDX skills to deliver a basic BI solution through SQL2005. BI is a very fast growing area and the majority of the large SQL database implementations I'm seeing these days are data warehouses in support of a BI platform. We're going to see more and more of it, and as the need for BI grows, so will the skills base.

    My current headache is trying to convince a client that they really shouldn't be running a SQL2000 AS Cube, side by side with a SQL2005 AS Cube, especially considering each Cube is 100GB+ ... and obviously I'm the person who has to fix it when it all falls over (t minus 1 week and counting)... but saying that, the clients need for BI is so great they don't want to wait a few weeks before the new servers arrive and run parallel environments...

  • We are starting to use BI here where I work and I am trying to explain the need for an OLAP system.  However, the learning curve in using MDX/OLAP is steep and I am trying.  There are not many training resources out there for it.

  • Thanks to all for your thoughts... I too wrestle with the complexities of my job and wonder if the need for some of the new technologies justifies the investment to see if it can be comprehended and applied in the real world.

    Time will tell... with the stuff that solves real world problems being with us for years to come:-)

  • SQL Portable?  Maybe for the GUI world but certainly not in the batch world.  For example, define some variables in SQL Server and do the same thing in Oracle... now, try to assign a value to one of more of the variables using either SET or SELECT... not portable folks.

    Create a trigger in SQL Server that affects more than one row... do the same in Oracle... not portable folks.

    And those aren't even the complex things... Like I said, maybe SQL can be made portable for GUI's, but it aint happenin' in the batch process world.  True code portability in SQL is a myth so far as batch processing goes.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I think that very little of SQL is portable these days, Jeff. The basic SELECT code might not be too bad, but I'm sure anything beyond a single statement requires some changing.

    PL/SQL and T-SQL seem so tweaked for platforms, I'm not sure Sybase T-SQL and SQL Server T-SQL are even that close! Makes me wonder if MDX is even recognizable among platforms

    I do think portability is over-rated. Most of us don't have an Oracle SAP system and a SQL Server SAP system, so we don't need to share code. And once we've decided on a platform, it's rare that you change. I guess that's why sales of the first system are important. I've rarely had shops change from *Nix to Windows or vice versa. You might get a couple boxes of the other platform installed, but you'll still focus on your primary area.

  • I've recently began researching OLAP in order to create some fast performing dashbaords for senior management at my company. At this point I am about to rip all of my hair out. The learning curve is much steeper than I anticipated and now I see why it is not mentioned as much as T-SQL, SSIS and SSRS. Does anyone know of any decent resources for SQL2005 Analysis Services training? I have the Wrox book but it is fairly confusing. Is it supposed to get better in SQL2008?

  • Kenneth,

    shameless plug, but my other company, End to End Training (www.endtoendtraining.com) does some in Orlando.

    You might want to put a note in the BI forums here on the site and you might get some good ideas.

  • Couldn't have said it better myself... thanks Steve.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I am using two books - the one from SAMS publishing and the one from McGraw Hill.  The SAMS one is highly technical where the other is more like a step-by-step book ("Delivering Business Intelligence with SQL Server 2005" by Brian Larson - http://www.mhprofessional.com/product.php?cat=112&isbn=0072260904&cat=112).

    I will look into those classes and thanks for the information!

Viewing 10 posts - 1 through 9 (of 9 total)

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