Foreign key and relationship in SSDS
- Is there a foreign key / relationship concept in SSDS?
For Foreign Key part, I can simply store the parent Entity Id in the records. But it makes me wonder how to manage cascade update / cascade delete? Are the features supported in SSDS, or I have to manage them myself?
One way to avoid cascade update is to assign a unique Id to entity which cannot be changed once inserted, e.g. Identity column in SQL Server 2005, or use GUID. This leads to another question, does SSDS support Identity / auto-numbering / GUID-generation as in SQL Server 2005? Or I have to assign my own GUID from client side?
解答
- You will have to generate your own IDs. There has been very little feedback on this item, it seems that most people are okay with generating GUIDs on the client side.
Tonyp- 已標示為解答c.c.chai Tuesday, 10 June, 2008 10:07
所有回覆
- Currently we do not support a schema for a container and as such there is no concept of a foreign key relationship or enforcement of relationships.
If schema support is a "must have" or even a "nice to have" for you please post note to the "feedback to SSDS team" thread with your requirements.
Our feature prioritization is based on customer feedback and request so put in your vote for the stuff you want :-)
Tonyp- 已提議為解答Tony PetrossianMSFT, 版主Sunday, 8 June, 2008 4:38
- So schema is not supported.
What about the second part of my question? Does SSDS able to auto-generate Entity Id for me? e.g. Identity column or NEWID() in SQL Server 2005. - You will have to generate your own IDs. There has been very little feedback on this item, it seems that most people are okay with generating GUIDs on the client side.
Tonyp- 已標示為解答c.c.chai Tuesday, 10 June, 2008 10:07
- Tony Petrossian said:
You will have to generate your own IDs. There has been very little feedback on this item, it seems that most people are okay with generating GUIDs on the client side.
Tonyp
I agree most people are ok to generate the GUIDS on the client side, but it will be really nice and make things a bit easier if the service can generate GUIDs. Anyone else wants this functionality?
.scottbee. - GUIDs aren't very performant when used for client-side (or server-side, for that matter) joins and they contribute substantial overhead to data upload and download compared to integers.
There is a rumor circulating that schemas will be introduced in a future sprint. Once you turn on schemas, it doesn't seem to me to be big step to implementing foreign key constraints.
--rj (OakLeaf Blog) - Since the Entities are returned in s:Id order right now, GUIDs are a non-starter.
Right now I use DateTime.UTCNow.Ticks to create a unqiue value for s:Id. I also worked up a pattern that uses the difference between the current date time and some (far out) future date as a way to create a *descending* order pattern where the most recent entries always appear at the top.
While this works when you always have code between the client and the SSDS data, they fail in cases where the SSDS data will be accessed directly. For that, we'll need some time of SSDS-side Id generation.
Mike Amundsen [http://amundsen.com/blog/]- 已編輯Mike Amundsen Saturday, 28 June, 2008 0:09fix spelling
