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

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,
); 

Мне просто не логично, мне нужно много операций, чтобы извлечь из баз данных несколько простых вещей, несколько примеров:

• Получить список песен (треков), сыгранных исполнителем А в 2006–2009 годах: потребовалось бы пройтись по таблице «списков треков», чтобы получить все треклисты исполнителя А, затем просмотретьв таблице «событий» (что уже является проблемой, как сохранить список?)

• Поиск исполнителя, который воспроизводил трек A большую часть времени: цикл по целым «треклистам»таблицы и получить какой-то счетчик, который ищет трекид трека A

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

Answer 1

Я согласен с Йенсом Шаудером в том, что вы хотите позволить СУБД беспокоиться о фильтрации и подсчете, но я вынужден не согласиться с тем, что список таблиц хорош, поскольку то, что предлагает 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% случаев, выполняемых базой данных с использованием 'count' и 'join'

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

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