Дизайн базы данных для хранения треков-записей танцевальных событий

Question

Я пишу простой интерфейс в 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 год: потребовалось бы перебирать таблицу «tracklists», чтобы получить каждый трек-лист исполнителя A, а затем посмотреть его в таблице «events» (который уже является болью, как сохранить список?)

• Поиск который художник играл трек Наиболее времен: проходную таблицы в целом «треклист» и получить какое-то счетчик, который выглядит для TrackID трекового

Это может стать немного запутанным, потому что я говорю о многом другом, но мне кажется, что моя база данных может быть спроектирована намного лучше или мне нужно использовать какой-то другой подход для решения этой программы по базе данных? Я ищу базовый старт-офф или подсказки/советы, чтобы получить эту базу данных намного эффективнее и лучше. Я знаю, что не каждый поиск может быть быстрым, но для меня это не кажется очень эффективным. Кроме того, есть ли лучший способ хранения списка в SQL-базе данных без необходимости их хранения в строках?

Answer 1

Я согласен с Jens Schauder в том, что вы хотите, чтобы СУБД беспокоиться о фильтрации и подсчете, но я должен не соглашаться с тем, что список таблиц в порядке, поскольку предложение OP не нормализуется. Это не является небольшой проблемой, поскольку это мешает СУБД выполнять свою работу.

Кроме того, важно не помнить, сколько раз воспроизводится трек, но записывать каждый раз, когда воспроизводится трек. Разница в том, что то, что вы хотите сохранить, - это история событий, а не сводка событий.

Что вы хотите таблицы, которые больше похожи на это:

структура

--- 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) и будет легко как написать и для запроса.

Answer 2

На первый взгляд база данных выглядит хорошо с единственным исключением, что вы не храните список идентификаторов в одной таблице, а ссылаетесь на эту таблицу из другой таблицы.

Циклическая вы описываете в 99% случаев, сделанных в базе данных, используя «количество» и «присоединиться»

Базы данных действительно хорошо и быстро при подсчете и глядя вверх.

Если вам нужна подробная помощь, как должны выглядеть ваши заявления SQL, задайте им новые вопросы.