我需要在Google App Engine中存储有关艺术家，专辑和歌曲的信息，以便我正在开展的项目。该信息是从MP3目录（使用Python）获取的元数据，需要将其发送到App Engine以显示给用户。与元数据一起，歌曲的路径将需要存储。
目前在扫描我将数据存储在名为Artists的词典列表中时，每个艺术家词典都有一个名称和一个专辑词典列表，每个专辑词典都有一个名称和歌词列表，每首歌曲然后包含一些元数据和MP3的路径。
我一直在考虑存储这些数据的方法，并尝试将数据以JSON格式发送到App Engine，然后将其处理为三个模型：艺术家，包含每个相册的名称和重复的KeyProperty，相册然后为每首歌曲都有一个名称和一个重复的KeyProperty，歌曲包含其余的元数据。其中每个还包含与其所属的组相关的KeyProperty。
问题在于：大量重复数据（组密钥）和处理数据不仅经常超过请求截止日期，而且还使用了大量的数据存储区写入。
我能想到解决这些问题的唯一方法是将扫描后提供的JSON存储为JsonProperty，然后将其直接传递给用户，以便在客户端使用JavaScript进行处理。我能看到的唯一问题是我并不特别想为用户提供路径（因为这需要传回并采取行动）。
有没有人有使用或存储此类数据的经验，或者可以提供任何开箱即用的解决方案？
答案 0 :(得分：3)
你可能想要的是一个包含所有内容的大型歌曲表。你的表看起来像：
Song | Artist | Album | Meta data | Track Number | Release Year | etc
不要将此视为关系数据库。您可以将其视为用户检索数据的方式。您的所有搜索都将来自该主表，最有可能。
您还需要一个艺术家表格，但这可能只包含艺术家及其作品。如果您想查看他们的所有歌曲，只需按艺术家姓名或ID过滤歌曲表格。如果你想看他们的专辑，你可以做同样的事情并使用distinct条款（或者只是将它们全部填入set）。
相册与艺术家非常相似，但它可能有自己的元数据。
如果您需要代码，请尝试this other similar question。
答案 1 :(得分：0)
我会处理来自json的数据，并将其放在Model中。就架构而言，您实际上不必担心冗余，因为您无法将ndb视为关系数据库。因此，不要过多地关注规范化模式。
但是不要在客户端进行处理，这不是一个很好的方式来设计它。