Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

SQLAndy

I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.

Thoughts on HTTP EndPoints, Schemas, and other niche features

Part of a conversation I had at the South Florida Code Camp was what I thought about various features that had been added in SQL 2005. I suspect I have an unusual view in some cases, but maybe not! In any case, here's a summary of that conversation:

  • HTTP EndPoints. These strike me as something that was added just to check off the SOA/Web Service item on the hot things we need for marketing checklist. Possibly a few people are using them, but in practice exposing a stored proc as a web service doesn't take a lot of code to start with, and we rarely want people connecting directly to the server (should be via some type of middle layer). I guess it's ok to put in the box and if someone uses it, good, and if not - well, it doesn't hurt other than maybe increasing the attack surface.
  • Schema. I like the change to bring us closer to ANSI compliance, and it cleans up the user owned ugliness. Still, so far I've not seen anyone that managed their security at any level by using schema. Life just doesn't usually fall into nice buckets like that! I would like to see SSMS altered to show schemas as folders under the object, that would make it much easier to see what was where, and it would let us stop naming table to get psuedo groups like TrainingAttendees, TrainingClasses because we would have a Training folder (schema) that would seem obvious. Should be in the box, but for most of us, a single DBO schema is the way to go.
  • Service Broker. I'm not a convert yet. I like that MS has moved from MSMQ to a native SQL based solution for things like updating subscribers, and many of us have used tables for informal queues for years. Do we need SB, does it save code, etc? So far I'm just not sure. I'm ok with leaving it in the box, for now!

I like that we get new features, but it's always hard to tell which ones will really matter when it's all said and done. It's also hard to know for those of us with limited training time/dollars to figure out which features we really need to learn, and which ones can wait until/if we need it. I'd like to see MS (or PASS) do a better job coaching on that.

Comments

Posted by Mike C on 10 February 2008

HTTP endpoints are actually pretty useful.  You're right that Web Services are pretty easy to create using .NET, but not everyone uses .NET :)  I've recently been put on a project that needs to use a lot of non-.NET development for an intranet and it needs to run off SQL Server.  HTTP endpoints are definitely the easiest way to go in this non-.NET multi-O/S shop.  I think the HTTP endpoints represent more of a replacement for equivalent SQLXML functionality than just a neat new acronym-laden feature :)

I haven't managed security on a schema level, but it sure does make it easier to group and manage related objects :)  I agree that SSMS should group objects together under schema folders (or at least provide the option). On another note, we've been having some problems getting the Microsoft-supplied JDBC drivers to properly report SQL 2005 schema information.  But that's another story :)

Posted by CGSJohnson on 17 April 2012

It's been a while SQLAndy.  Any updated thoughts on these?

Thanks...Chris

P.S.  A manager just brought up HTTP endpoints, so I am just now researching it.

P.P.S. I have used Service Broker for asynchronous messaging...works great, once you have it configured correctly.

Posted by CGSJohnson on 17 April 2012

Ha, ha!  Never mind...just saw that this was removed in SQL 2012.

Thanks...Chris

Leave a Comment

Please register or log in to leave a comment.