Microsoft Developer Network > 포럼 홈 > SQL Azure — Getting Started > Foreign key and relationship in SSDS
질문하기질문하기
 

답변됨Foreign key and relationship in SSDS

  • 2008년 6월 7일 토요일 오전 8:51c.c.chai 사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     
    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?

답변

  • 2008년 6월 10일 화요일 오전 4:07Tony PetrossianMSFT, 중재자사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     답변됨
    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 2008년 6월 10일 화요일 오전 10:07
    •  

모든 응답

  • 2008년 6월 8일 일요일 오전 4:38Tony PetrossianMSFT, 중재자사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     제안된 답변
    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
  • 2008년 6월 10일 화요일 오전 3:19c.c.chai 사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     
    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. 
  • 2008년 6월 10일 화요일 오전 4:07Tony PetrossianMSFT, 중재자사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     답변됨
    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 2008년 6월 10일 화요일 오전 10:07
    •  
  • 2008년 6월 27일 금요일 오후 4:43scottbee 사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     
    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.
  • 2008년 6월 27일 금요일 오후 5:58Roger Jennings 사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     
    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)
  • 2008년 6월 28일 토요일 오전 12:09Mike Amundsen 사용자 메달사용자 메달사용자 메달사용자 메달사용자 메달
     
    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 2008년 6월 28일 토요일 오전 12:09fix spelling
    •