Any other DBAs or Systems folks tunned in? What do *you* think of Yukon? Where do we go from there?
DBAs!!!!!!!..............serenity now....serenity now
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...
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.
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 . 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
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!
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.
What would you want to read about in a Yukon developer title? Include priority and depth. I'm thinking really hard about doing it...
I hope you will only be exposing that stored procedure as a web service to internal (LAN) consumers...
i hope so too
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?
...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.
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.
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.
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.
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."
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.