在 App Engine 上存储歌曲、艺术家和专辑数据 [英] Storing song, artist and album data on App Engine

问题描述

我需要在 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 的词典列表中，每个艺术家词典都有一个名称和一个专辑词典列表，每个专辑词典都有一个名称和歌曲词典列表，然后每首歌曲包含一些元数据和 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，然后将其处理为三个模型:艺术家，包含每个专辑的名称和重复的 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:

歌曲|艺术家 |专辑 |元数据 |跟踪号 |发布年份 |等

不要将其视为关系数据库.而是将其视为您的用户将如何检索数据.您的所有搜索很可能都来自该主表.

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.

您还需要一个艺术家表，但它可能只包含艺术家及其个人简介.如果您想查看他们的所有歌曲，只需按艺术家姓名或 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 上存储歌曲、艺术家和专辑数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！