我们的团队已经开始使用AWS，其中一个项目需要将各种建议的审批状态存储在一个表中。
有很多东西可以识别单个推荐，假设它们是:State, ApplicationDate, LocationID, and Phase。然后是一堆与推荐相对应的属性(标题，音量等)
用例通常需要抓取给定State和ApplicationDate的所有条目(然后我们将查看与之对应的所有LocationId和Phase项)，以便从UI进行审查。对于给定的Station, ApplicationDate, LocationId, Phase，每次一个项添加到表中，并经常更新。
State+ApplicationDate作为分区键，LocationId+Phase作为排序键。这两部分组合起来就是主键。我通常理解这一点，但如果我们开始为同一个主键获得多个推荐，那该如何工作呢?我想我们要么可以覆盖之前的内容，要么我们必须添加一些其他属性，以便我们可以多次为State+ApplicationDate/LocationId+Phase编写推荐并获得所有以前的值，如果我们需要……但这需要在主键上加一些东西，对吧?这是否类似于向排序键添加某种惟一值?或者，如果我们需要处理状态，并希望在不同的状态下记录不同的值，我们是否只需要将状态添加到排序键中?这听起来像一个合理的方法吗?还是我应该探索一个不同的NAWS产品来存储这些数据?
使用基于时间的id属性，例如uid或KSID。这将提供随机性以避免覆盖数据，但当用作排序键
的一部分时，还提供基于时间的数据排序。由于id值是随机的，您将希望将其添加到执行列表操作的表或索引的排序键中，并为可以精确指定的已知值保留pk。
听起来"状态"是一个可以改变的值。你不能在表中更新项目的键属性，所以如果需要列出数据，则更常见的是在GSI的键中使用这些属性。
鉴于上述情况，另一种设计是使用LocationId作为pk，随机id值作为sk，并使用GSI以'State'作为pk，随机id作为sk。或者，如果您想按State列出项目->阶段→此时，GSI sk可以是Phase和id属性的连接。以上模式使用LocationId +推荐创建时间的时间戳为您提供了另一种列表机制。