SQL Data Services database design guidelines

Question

I've been playing around lately with SQL Data Services. Although (or perhaps because) I can knock out a well-structured relational database in my sleep, I'm struggling to get my head round how to design a performant database in an environment that has (for example) no enforcement of referential integrity and no indexes on columns other than the primary key.

Does anyone know of any guidelines?

Maybe a place to start would be how to create a many-to-many join that can be traversed from either side in a performant manner, even with vast numbers of rows entities?

Answer 1

It seems the phrases that are being used are:

• Spread your data out amongst many containers for best performance

• Modeling your data via Entities

• Process your queries in parallel for best performance

• Caching data in the service hosted middle tier

This would imply that we have to start thinking like OO modellers rather than in a relational mind-set. Performance seems to rely on the ability to massively parallelise an object query in a smiliar way to creating a LINQ query that can take advantage of parallelisation.

Answer 2

Well, the solution I went for in the end was: stop using SQL Data Services. It's so half-baked that it's barely worth using at the moment anyway.