Question

在您自己的视图中，您如何在逻辑上设计表格？特别是当表与其他表有一对多的关系时。

以下是给定的数据：

给定的是product表，其中包含PartitionKey和Rowkey 其中PartitionKey用作ID的{{1}}。

Owner (the owner of the product) plus the category

和i.e: hashedowneridstringtype_Cellphone用作Rowkey

unique id of the product.

这是azure表的现有设计，我必须在下面创建下表。由于我对如何在azure中反映它没有足够的想法，我不得不使用关系表来设计它：

产品可以有用户评论。

i.e: S6102DXMA2

用户可以评论评论。

----------------------------------------------------------------------------------
Review table

Fields:
    ReviewID    - long
    Title       - string
    Review      - string
    OwnerID     - long
    DatePosted  - Date
---------------------------------------------------------------------------------- 
ProductReview table

Fields:
    ProductID   - long
    ReviewID    - long
----------------------------------------------------------------------------------

用户可以对评论，评论和产品进行评分。

----------------------------------------------------------------------------------
Comment table

Fields:
    CommentID   - long
    Comment     - string
    OwnerID     - long
    CommentDate - date
    EmailUpdate - bool  
----------------------------------------------------------------------------------
    CommentReview table

Fields:
    ReviewID    - long
    CommentID   - long
----------------------------------------------------------------------------------

在azure中设计表格时，我应该考虑哪些事项？

Answer 1

在Azure中设计存储表时，您应该考虑预期针对Table运行的查询。您需要快速进行哪些查询，哪些查询速度较慢，执行频率，需要扩展程度等等。

假设一个频繁的查询是返回给定产品的时间排序的评论列表，我将首先构建您的评论表，如：

Review table

PartitionKey: ProductID
RowKey: InvertedDatePosted+ReviewID

Fields:
    ReviewID    - long
    Title       - string
    Review      - string
    DatePosted  - Date
    OwnerID     - long

如果按排名进行排序，那么您可能需要在RowKey中进行评级，如果您按照评级或日期排序，那么您可能需要有两个单独的评论表，一个按日期键入，另一个键入评价

鉴于表连接速度相对较慢，您应该尽量减少它们发生的频率。实现此目的的一种方法是对数据进行非规范化，例如，在每次审核中包括您的审核所有者名称和图片网址。这意味着获取评论列表的查询不必加入以获取评论者的详细信息，但是当评论者更改其名称时更新将会慢得多。

Review table

Fields:
    ReviewID    - long
    Title       - string
    Review      - string
    DatePosted  - Date
    OwnerID     - long
    OwnerName   - string
    OwnerImgUrl - string

作为替代方案，您可能还需要考虑使用联合Azure SQL数据库，该数据库可以围绕ProductID进行水平扩展。

天蓝色表中的逻辑表设计

1 个答案: