Why should I use SDS instead of Azure tables?

Question

Someone asked me this yesterday and, even though I've been using SDS for a few months, I couldn't come up with a persuasive answer. Both offer partitioning for scale-out, just in slightly different ways.

The only differentiator I see in v1 is that SDS will allow us to pick which geo-location our data resides at.


I know that SDS will, one day, include a lot more functionality which I'm supposing means full-text indexing/searching, data mining, schemas but is there anything else in there TODAY that differentiates it from Azure tables? I'm finding it hard to do the sell on it.

cheers
Jamie

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 1

Hi

these site will be helpfull for you http://www.shanmcarthur.net/cloud-services/design-strategies-for-Azure-and-SDS

you can browse http://oakleafblog.blogspot.com/2008/11/azure-storage-services-test-harness.html.

also you can see this thread http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7b901abe-9050-4e1a-83c4-f7e564561ef3/

Regards

Kapil M Gupta

Answer 2

Jamie,

They are very close today but some things that we offer they don't presently include:

1) Joins (these are supported in Azure tables)
2) Support for STS as a authn mechanism for SOAP clients.

These are likely the two biggest differences between the two services with Joins being the more important (IMO) of the two.

Hope it helps,

--Jeff--

Answer 3

jcurrier said:

Jamie,

They are very close today but some things that we offer they don't presently include:

1) Joins (these are supported in Azure tables)
2) Support for STS as a authn mechanism for SOAP clients.

These are likely the two biggest differences between the two services with Joins being the more important (IMO) of the two.

Hope it helps,

--Jeff--

Thanks guys.

Jeff, your 2 comments that I've highlighted above appear to contradict each other. Could you elaborate quickly? Thanks.

-Jamie

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 4

I won't try to speak for Jeff, but I am guessing he was trying to write that joins were not supported in Windows Azure storage and just missed the 'not' in his second statement to that effect.  Joins are NOT supported (at least today) in Windows Azure.  Simple predicates and filtering are supported however.

I don't want to get into a feature by feature checklist, but rather instead say:  ultimately, the trajectory of SDS has been to move more and relational features into the service.  We have announced that we will be getting to schemas and constraints in the future at PDC.  To this end, if you believe that you need relational features in your application - aggregates, joins, projection, etc. - you should probably continue to follow SDS.  Conversely, if you do not need these features (and lots of apps don't), then Windows Azure is a perfectly fine (great) choice for you as well.  I think over time the capabilities of these two services will diverge more and it will become much easier to see when to choose which.

---

Ryan Dunn -- Co-Author, The .NET Developer's Guide to Directory Services Programming -- SQL Services Evangelist

Answer 5

dunnry said:

I won't try to speak for Jeff, but I am guessing he was trying to write that joins were not supported in Windows Azure storage and just missed the 'not' in his second statement to that effect.  Joins are NOT supported (at least today) in Windows Azure.  Simple predicates and filtering are supported however.

I don't want to get into a feature by feature checklist, but rather instead say:  ultimately, the trajectory of SDS has been to move more and relational features into the service.  We have announced that we will be getting to schemas and constraints in the future at PDC.  To this end, if you believe that you need relational features in your application - aggregates, joins, projection, etc. - you should probably continue to follow SDS.  Conversely, if you do not need these features (and lots of apps don't), then Windows Azure is a perfectly fine (great) choice for you as well.  I think over time the capabilities of these two services will diverge more and it will become much easier to see when to choose which.

---

Ryan Dunn -- Co-Author, The .NET Developer's Guide to Directory Services Programming -- SQL Services Evangelist

Great answer, thank you Ryan.

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 6

Ryan,
Would you mind if I re-posted this on my blog?

(Listened to your interview on SQL Down Under on the way in this morning by the way, good stuff.)

-Jamie

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 7

No, I don't mind.  You can quote me on that one.  :)

The interview was fun, glad you liked it.

---

Ryan Dunn -- Co-Author, The .NET Developer's Guide to Directory Services Programming -- SQL Services Evangelist

Answer 8

dunnry said:

No, I don't mind.  You can quote me on that one.  :)

The interview was fun, glad you liked it.

---

Ryan Dunn -- Co-Author, The .NET Developer's Guide to Directory Services Programming -- SQL Services Evangelist

Thanks Ryan. Done:

What’s the difference between SQL Data Services (SDS) and Azure tables?
(http://blogs.conchango.com/jamiethomson/archive/2008/12/12/what-s-the-difference-between-sql-data-services-sds-and-azure-tables.aspx)

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson