实体模型：
我已阅读有关创建的 AWS 指南在 DynamoDB 中建模关系数据 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html。我的访问模式非常混乱。
访问模式
+-------------------------------------------+------------+------------+
| Access Pattern | Params | Conditions |
+-------------------------------------------+------------+------------+
| Get TEST SUITE detail and check that |TestSuiteID | |
| USER_ID belongs to project has test suite | &UserId | |
+-------------------------------------------+------------+------------+
| Get TEST CASE detail and check that | TestCaseID | |
| USER_ID belongs to project has test case | &UserId | |
+-------------------------------------------+------------+------------+
| Remove PROJECT ID, all TEST SUITE | ProjectID | |
| AND TEST CASE also removed | &UserId | |
+-------------------------------------------+------------+------------+
因此，我对关系实体数据进行建模作为指导。
+-------------------------+---------------------------------+
| Primary Key | Attributes |
+-------------------------+ +
| PK | SK | |
+------------+------------+---------------------------------+
| user_1 | USER | FullName | |
+ + +----------------+----------------+
| | | John Doe | |
+ +------------+----------------+----------------+
| | prj_01 | JoinedDate | |
+ + +----------------+----------------+
| | | 2019-04-22 | |
+ +------------+----------------+----------------+
| | prj_02 | JoinedDate | |
+ + +----------------+----------------+
| | | 2019-05-26 | |
+------------+------------+----------------+----------------+
| user_2 | USER | FullName | |
+ + +----------------+----------------+
| | | Harry Potter | |
+ +------------+----------------+----------------+
| | prj_01 | JoinedDate | |
+ + +----------------+----------------+
| | | 2019-04-25 | |
+------------+------------+----------------+----------------+
| prj_01 | PROJECT | Name | Description |
+ + +----------------+----------------+
| | | Facebook Test | Do some stuffs |
+ +------------+----------------+----------------+
| | t_suite_01 | | |
+ + +----------------+----------------+
| | | | |
+------------+------------+----------------+----------------+
| prj_02 | PROJECT | Name | Description |
+ + +----------------+----------------+
| | | Instagram Test | ... |
+------------+------------+----------------+----------------+
| t_suite_01 | TEST_SUITE | Name | |
+ + +----------------+----------------+
| | | Test Suite 1 | |
+ +------------+----------------+----------------+
| | t_case_1 | | |
+ + +----------------+----------------+
| | | | |
+------------+------------+----------------+----------------+
| t_case_1 | TEST_CASE | Name | |
+ + +----------------+----------------+
| | | Test Case 1 | |
+------------+------------+----------------+----------------+
如果我只有 UserID 和 TestCaseId 作为参数，我如何获取 TestCase Detail 并验证 UserId 是否具有权限。
我考虑过在单个项目中存储复杂的分层数据。有东西喜欢这个
+------------+-------------------------+
| t_suite_01 | user_1#prj_1 |
+------------+-------------------------+
| t_suite_02 | user_1#prj_2 |
+------------+-------------------------+
| t_case_01 | user_1#prj_1#t_suite_01 |
+------------+-------------------------+
| t_case_02 | user_2#prj_1#t_suite_01 |
+------------+-------------------------+
问题：对于这种情况，最好的方法是什么？如果您能给我一些关于这种方法的建议，我将不胜感激（鞠躬）
我认为下面的架构可以满足您的需求。在“GSIPK”属性上创建仅分区键的GSI并查询如下：
获取测试套件详细信息并验证用户：查询 GSI - PK == ProjectId、FilterCondition [SK == TestSuiteId || PK==用户ID]
获取测试用例详细信息并验证用户：查询 GSI - PK == TestCaseId, FilterCondition [SK = TestSuiteId:TestCaseId || PK = 用户 ID]
删除项目：查询GSI - PK == ProjectId，删除所有返回的项目。
查询 1 和 2 返回 1 或 2 个项目。一是详细项，二是测试套件或测试用例的用户权限。如果仅返回一项，则其为详细项，并且用户无权访问。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
