Как настроить ключ и индексы для базы данных SQLite, хранящей данные о ценах на акции

#database #sqlite #stock #price

#База данных #sqlite #акции #Цена

Вопрос:

У меня есть база данных SQLite, в которой хранятся сведения о компании и истории цен на акции с использованием двух таблиц. Схема выглядит следующим образом:

 CREATE TABLE details (
epic     CHAR (4),
name     VARCHAR (30),
exchange CHAR (6),
sector   VARCHAR (20),
CONSTRAINT PK_details PRIMARY KEY (
    epic ASC
)
ON CONFLICT ROLLBACK
);

CREATE TABLE data (
epic   CHAR (4),
date   DATE (10),
open   DECIMAL (6, 2),
high   DECIMAL (6, 2),
low    DECIMAL (6, 2),
close  DECIMAL (6, 2),
volume INTEGER (10),
CONSTRAINT PK_data PRIMARY KEY (
    epic ASC,
    date ASC
)
ON CONFLICT ROLLBACK
);
  

Когда я удаляю компанию из таблицы сведений, я хотел бы, если возможно, чтобы процесс удаления был каскадным и удалял все соответствующие записи в таблице данных.

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

Будем признательны за любую помощь или комментарии о том, как улучшить приведенную выше схему.

Я немного больше прочитал и добавил внешний ключ в таблицу данных.

 ON CONFLICT ROLLBACK,
CONSTRAINT epic_FK FOREIGN KEY (
    epic
)
REFERENCES details (epic) ON DELETE CASCADE
);
  

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

Кроме того, я добавил уникальный индекс в столбец epic в таблице данных с сортировкой, установленной на ASC, и другой уникальный индекс в столбцы epic и names таблицы details, опять же с сортировкой, установленной на ASC.

Не уверен, что вышеуказанные изменения являются лучшим решением.

Комментарии:

1. Все это есть на странице sqlite , включая примеры для CREATE INDEX (глава index) и cascade ON DELETE (в главе foreign key).

2. Я бы прочитал sqlite.org/datatype3.html и придерживайтесь использования обычных типов sqlite для ваших столбцов. По крайней мере, убедитесь, что вы понимаете, как обрабатываются те, которые вы используете сейчас.

3. С первичным ключом в epic дата в таблице данных у вас уже есть объединенный индекс для этих двух столбцов. Поскольку epic является первым столбцом в этом индексе, этого должно быть достаточно для извлечения записей данных в соединении с таблицей сведений. Ваше решение должно работать. Количество записей (500 компаний х 360 дней х 2 года) составляет всего несколько сотен тысяч записей. SQLite должен довольно легко обрабатывать эту сумму.

4. @Oliver Jakoubek Дополнительные уникальные отсортированные индексы для имен epic и epic теперь избыточны?

5. @w2kpro Эти дополнительные индексы не должны иметь никакого значения — для производительности. У вас могут быть уникальные ограничения для некоторых столбцов только ради обеспечения уникальных значений. Как я уже сказал, производительность не должна быть проблемой для этих нескольких записей.