2012-03-12 39 views
0

我正在为一个简单的数据库编写一个简单的Python接口。数据库是一个简单的数据库,它存储哪个特定曲目在哪个活动中以及由哪个艺术家播放。 Python中的接口还不是问题,尽管数据库的设计是。我想出了以下事情:用于舞蹈事件曲目列表存储的数据库设计

--- EVENTS --- 

CREATE TABLE events (
    id INTEGER PRIMARY KEY autoincrement, 
    event_name TEXT NOT NULL, 
    event_date TEXT NOT NULL, 
    <list of tracklist-ids - foreign key?> 
); 

--- TRACKLISTS --- 

CREATE TABLE tracklists (
id INTEGER PRIMARY KEY autoincrement, 
artist TEXT NOT NULL, 
<list of track-ids - foreign key?> 
); 

--- TRACKS --- 

CREATE TABLE tracks (
id INTEGER PRIMARY KEY autoincrement, 
trackartist TEXT NOT NULL, 
trackname TEXT NOT NULL, 
timesplayed INTEGER NOT NULL, 
); 

它只是不觉得逻辑对我来说,我需要的方式来许多操作得到一些简单的事情了数据库,几个例子:

  • 获取艺术家A在2006年至2009年期间播放的歌曲(曲目)列表:需要循环播放“曲目列表”以获取艺术家A的每个曲目组,然后在“活动”表中查找它(这已经很痛苦,如何存储清单?)

  • 查找该艺术家播放的曲目一个最次数:贯穿整个“tracklists”表循环,并得到某种计数器看起来对的TrackID曲目一

它可能会变得有点混乱,因为我说的关于很多不同的事情,但对我来说,似乎我的数据库可以设计得更好,或者我应该使用某种其他方法来以数据库方式处理这个程序?我正在寻找一个基本的起点或提示/技巧来让这个数据库更高效和更好。我知道不是每个查询都可以很快,但对我来说这似乎不是很有效。另外,有没有更好的方式将列表存储到SQL数据库中,而无需将它们存储到字符串中?

回答

2

我同意Jens Schauder的观点,你想让DBMS担心过滤和计算,但是我不同意表的列表没有问题,因为OP提议的内容没有被标准化。这不是一个小问题,因为它会阻止DBMS的工作。

此外,重要的是,这个想法并不是保持一个曲目播放多少次的运行轨迹,而是保持每次播放曲目的记录。不同的是,你想存储的是事件的历史,而不是事件的概要。

你想要什么表,看起来更像是这样的:

--- EVENTS --- 

CREATE TABLE events ( 
    id INTEGER PRIMARY KEY autoincrement, 
    event_name TEXT NOT NULL, 
    event_date TEXT NOT NULL, 
); 

--- ARTISTS --- 

CREATE TABLE artists (
    id INTEGER PRIMARY KEY autoincrement, 
    artist_name TEXT NOT NULL 
); 

--- TRACKS --- 

CREATE TABLE tracks ( 
id INTEGER PRIMARY KEY autoincrement, 
trackname TEXT NOT NULL, 
artist_id INTEGER, 
FOREIGN KEY(artist_id) REFERENCES artists(id) 
); 

--- PERFORMANCES --- 

CREATE TABLE performances (
    id INTEGER PRIMARY KEY autoincrement, 
    event_id INTEGER, 
    track_id INTEGER, 
    FOREIGN KEY (event_id) REFERENCES events(id), 
    FOREIGN KEY (track_id) REFERENCES tracks(id) 
); 

此表结构是第三范式(3NF)和将很容易都写入和查询。

+0

非常有趣,有些问题:如果我有10个同名的曲目和三个不同的艺术家,它仍然会在曲目表中创建10个条目?这不是浪费空间吗?其次;你链接的event_id <-> track_id,有这个特定的原因? – wvd 2012-03-12 15:53:09

+0

@wvd - 链接event_id和track_is就像是说“这个曲目是在这个活动中播放的”。关键是要记录事情发生的事实。你数了事后发生的事情,而不是在你录制它的时候。这是一个更好的方法,原因很多。关于你关于10首曲目和三位艺术家的问题,我不确定我是否跟着你。你的意思是三位艺术家合作了10首不同的歌曲,还是你的意思是说,来自3位不同艺术家的10首独立歌曲是在一个事件中进行的?你能举一个例子(甚至是一个化妆)吗? – 2012-03-12 19:46:15

+0

我明白你的想法。看起来很聪明。我在表格[这里](http://pastebin.com/uE2C1PtJ)写下了一些条目,唯一的问题是:艺术家可以制作和播放曲目。用你的方法,我永远不能说“艺术家X在大部分时间都演奏过A曲”。 – wvd 2012-03-12 20:41:58

0

乍一看,你的数据库看起来很好,只有一个例外,你不会在一个表中存储一个id列表,而是从另一个表中返回该表的引用。

的循环您介绍的就是在使用“计数”和“加入”

数据库是非常好,速度快,在计算和查找在数据库中完成99%的情况。

如果您需要详细的帮助,您的sql语句应该如何让他们看到新的问题。

+0

谢谢:),很高兴看到perfomance是否好得多,我认为它*可以*。 – wvd 2012-03-12 09:50:57