Coffeehouse Thread

11 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

DBAs in the house?

Back to Forum: Coffeehouse
  • User profile image
    ktegels

    Any other DBAs or Systems folks tunned in? What do *you* think of Yukon? Where do we go from there?

  • User profile image
    harumscarum

    DBAs!!!!!!!..............serenity now....serenity now

    Smiley

  • User profile image
    spod

    i'm kinda a dba / systems person i suppose. I'm certainly interested in a yukon discussion. What specifically do you mean about yukon? xml support, clr integration, other stuff...

    cheers
    jeff

  • User profile image
    lars

    For me personally, it's the prospect of having the CLR and maybe a little bit of the framework available on the database server that gets my motor running.
    I've no idea how much of that stuff will be in the final product so I can only hope. I can hardly wait to get my hands on that baby and check it out for myself.

  • User profile image
    spod

    Hi Lars

    Yes the clr integration is certainly one of the coolest pieces and offers a lot of potential. I do worry a little about the high-end scalability aspects of including the entire managed stack, but this is complete speculation as i haven't measured it yet. I'm a bit of a dinosaur when it comes to databases, and have always had most success with internet-scale apps when using purely relational fetures ( for both oracle and sqlserver). That said a lot of people a lot smarter than me have been working on this, and they seem to have solved the big engineering problems extremely well...

    there are a lot of interesting scenarios having the clr available in sql, and it does open up database programming nicely to a new audience - with all the associated pros and cons Smiley. We are certainly tracking closely if when and how to migrate to yukon, and which features to use haevily in my group...

    If others are interested, the features i am really looking forward to having are:

    WITH clauses and recursive subqueries

    INDEX improvements, especially space improvements
    with composite indexes

    LOB and general blob, large image support

    Timestamps accurate to 100ns!

    XML indexes, and xpath support..

    CLR support, UDTs - object serialization etc


    cheers
    jeff






  • User profile image
    Sabot

    I'm getting my head round this SQLX at the mo! It's going to be good, there is an article in this months VSJ.

    Could you imagine putting <WebMethod> infront of your store procedure 'create procedure' statement to turn the thing into a XML Web Service ... now that would be cool!

    As for Yukon, sounds great, would kind of like to see 'partioning' and 'material views' to a la Oracle. Would be cooler as well if you didn't have to pay extra for it ... a la Oracle!

    What I would most like to see out of Yukom is performance. I would love to see this database be a real speed demon!

  • User profile image
    spod

    Hey sabot

    aren't horizontal partitioning and materialized views supported in sql 2000. yukon certainly doesn't take those away afaik, or do you mean something different?

    I hear you on the perf front, though a nicely designed sql 2000 implementation can really fly, and the shipping .net sql client is really cool perf wise in my experience, with its direct on tds implementation.


    cheers
    jeff

  • User profile image
    ktegels

    What would you want to read about in a Yukon developer title? Include priority and depth. I'm thinking really hard about doing it...

  • User profile image
    billy

    I hope you will only be exposing that stored procedure as a web service to internal (LAN) consumers...

  • User profile image
    spod

    Hi billy

    i hope so too Smiley

    This is probably a contentious viewpoint, but i've always thought features such as this; which promote the pushing of functionality down to the database as meant for small-scale, internal-only projects etc, and that internet-facing, or enterprise scale apps would do a more traditional n-tier thing. I can't think of many net admins that would let their databases inside the dmz with their web-servers for example.

    To move off topic a little, but it's been a while since i've had a chance to chat to external dbs, and i'm interested in what people think...

    I tend to be somewhat conservative in my designs involving databases, and leave most of the processing to the middle tier, with the db doing pretty much pure insert, update and select. The problem i've always had with pushing processing to the db ( through direct hosting of web-services, hosting of business logic etc ) is that the db machines can bewcome a big scalability barrier,and are much harder to scale out than web-servers,as they are expensive, and stateful..

    How do people see the future. Is it database servers directly exposed the internet through web-services running c# stored procs and talking xml directly, or is there a place for the middle tier still. How are yukon ( and java / oracle etc for that matter ) changing you way you design the applications you are responsible for?

    cheers
    jeff

  • User profile image
    ktegels

    spod wrote:
    ...small-scale, internal-only projects etc, and that internet-facing, or enterprise scale apps would do a more traditional n-tier thing
    I mostly agree. There will be cases where you have massive systems where developers have tried to do this that will push this, though.
    spod wrote:
    I can't think of many net admins that would let their databases inside the dmz with their web-servers for example.
    True, most of the time, it should be considered as a disposable resource if you going to put it in the DMZ.
    spod wrote:
    is that the db machines can bewcome a big scalability barrier,and are much harder to scale out than web-servers,as they are expensive, and stateful.
    Right. Microsoft has decided it seems to go with a scale-up solution. Oracle with 10g seems to have gone with a scale out solution. Both have benefits and issues.
    spod wrote:
    Is it database servers directly exposed the internet through web-services running c# stored procs and talking xml directly, or is there a place for the middle tier still.
    Absolutely. Although you can expose CLR-based objects it doesn't mean you should. The HTTP handler in Yukon isn't IIS so its too early IMHO to predict how well or poorly it will work for such applications. Then there are a whole host of memory managment, socket and thread (fiber) managment issues. Beta 2 should give us the opportunity to kick the tires. I'll still say that I'm relucant to do it from a security point of view, the Slammer scars are still fresh.
    spod wrote:
    How are yukon ( and java / oracle etc for that matter ) changing you way you design the applications you are responsible for?
    At this point, I see the CLR integration as "SQL Helper." Its good for doing things that T-SQL isn't. Its also helpful for defining new types, that's a good thing too. Much of the XML support is a function of having the CLR in-process and since XML is a good thing, that's a good thing. But I don't see us running out and making everything on SQL server. Partially for the issues you raise here, partially that its just too soon to know how that behaves in "the real world."

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.