问题描述
我需要在我正在从事的项目的Google App Engine中存储有关艺术家，专辑和歌曲的信息.该信息是从MP3目录(使用Python)获取的元数据，需要将其发送到App Engine才能显示给用户.除了元数据外，还需要存储歌曲的路径.
I need to store information on artists, albums and songs in Google App Engine for a project I'm working on. The information is meta data taken from a directory of MP3s (using Python) that needs to be sent to App Engine for display to users. Along with the meta data, the song's path will need to be stored.
当前，在扫描时，我将数据存储在名为Artists的词典列表中，每个歌手词典都有一个名称和一个专辑词典列表，每个Album词典都有一个名称和歌曲词典列表，然后每首歌曲都包含一些元数据和MP3的路径.
Currently while scanning I'm storing the data in an list of dictionaries named Artists, each artist dictionary has a name and a list of Album dictionaries and each Album dictionary has a name and list of song dictionaries, each song then contains some meta data and the path to the MP3.
我一直在考虑存储此数据的方法，并尝试将JSON格式的数据发送到App Engine，然后将其处理为三个模型:Artist，包含名称和每个专辑的重复KeyProperty，然后专辑具有每个歌曲的名称和重复的KeyProperty，并且歌曲包含其余的元数据.其中的每一个还将包含与它们所属的组相关的KeyProperty.
I've been thinking of ways to store this data and have tried sending the data in JSON format to App Engine, then processing this into three models: Artist, containing the name and a repeated KeyProperty for each Album, Album then has a name and a repeated KeyProperty for each song and the song contains the rest of the meta data. Each of these will also contain a KeyProperty related the the Group that they belong to.
与此相关的问题是:大量重复数据(组密钥)和处理数据不仅经常超出请求的截止期限，而且还使用了大量的数据存储写入.
The problems with this are: Lots of repeated data (Group Keys) and processing the data not only often exceeds the request deadline, but also uses an obscene amount of datastore writes.
我能想到的解决这些问题的唯一方法是将扫描后提供的JSON存储为JsonProperty，然后将其直接传递给用户，以使用JavaScript在客户端进行处理.我能看到的唯一问题是，我特别不想提供给用户的路径(因为这需要传递回去并对其进行操作).
The only way I could think of to get around these problems would be to store the JSON provided after the scan as a JsonProperty and then pass this directly to the user for processing on the client side using JavaScript. The only issue I could see with that is that I don't particularly want to provide the path to the user (as this will need to be passed back and actioned on).
是否有人有使用或存储此类数据的经验，或者可以提供任何现成的解决方案?
Does anyone have experience using or storing this kind of data, or can provide any outside the box solutions?
推荐答案
您可能想要的是一张很大的歌曲桌子，里面有所有东西.您的表格如下所示:
What you probably want is a big Songs table with everything in it. Your table would look something like:
Song | Artist | Album | Meta data | Track Number | Release Year | etc
不再将此视为关系数据库.而是将其视为您的用户将如何检索数据.您所有的搜索都将很有可能来自该主表.
Quit thinking of this as a relational database. Think of it instead as how your user is going to retrieve the data. All your searching is going to be from that main table, most likely.
您还将需要一个 Artist 表，但这可能只包含该艺术家及其个人简介.如果要查看他们的所有歌曲，只需按艺术家姓名或ID过滤歌曲表.如果要查看他们的专辑，可以执行相同的操作并使用distinct子句(或将它们全部塞入set).
You'll want an Artists table as well but that could just contain the artist and their bio. If you want to see all their songs, then just filter the Songs table by the artist name or ID. If you want to see their albums, you can do the same thing and use a distinct clause (or just stuff them all into a set).
专辑与艺术家非常相似，只是它可能具有自己的元数据.
Album is very similar to Artists except it might have its own metadata.
如果您想要代码，请尝试其他类似的问题.
If you want code, try this other similar question.
这篇关于在App Engine上存储歌曲，艺术家和专辑数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！