instal - sqlite website

Esquema de la base de datos para organizar los datos históricos de stock

Question

Estoy creando un esquema de base de datos para almacenar datos de stock históricos. Actualmente tengo un esquema como se muestra a continuación.

Mis requisitos son almacenar "datos de barras" (fecha, apertura, alta, baja, cerrar volumen) para múltiples símbolos de stock. Cada símbolo también puede tener múltiples marcos temporales (por ejemplo, las barras Google Weekly y las barras Google Daily).

Mi esquema actual coloca la mayor parte de los datos en la tabla OHLCV. Estoy lejos de ser un experto en bases de datos y tengo curiosidad si esto es demasiado ingenuo. La entrada constructiva es muy bienvenida.

CREATE TABLE Exchange (exchange TEXT UNIQUE NOT NULL);

CREATE TABLE Symbol (symbol TEXT UNIQUE NOT NULL, exchangeID INTEGER NOT NULL);

CREATE TABLE Timeframe (timeframe TEXT NOT NULL, symbolID INTEGER NOT NULL);

CREATE TABLE OHLCV (date TEXT NOT NULL CHECK (date LIKE ''____-__-__ __:__:__''),
    open REAL NOT NULL,
    high REAL NOT NULL,
    low REAL NOT NULL,
    close REAL NOT NULL,
    volume INTEGER NOT NULL,
    timeframeID INTEGER NOT NULL);

Esto significa que mis consultas actualmente son más o menos así: encuentre el timeframeID para un símbolo / marco de tiempo dado, luego haga una selección en la tabla OHLCV donde el timeframeID coincida.

Answer 1

Bueno, en el lado positivo, tienes el buen sentido de pedir ayuda primero. Eso lo pone por delante del 90% de las personas que no están familiarizadas con el diseño de la base de datos.

• No hay relaciones clave extranjeras claras. Lo tomo timeframeID relaciona con symbolID ?
• No está claro cómo podrías encontrar algo de esta manera. Leer las claves externas antes mencionadas debería mejorar su comprensión tremendamente con poco esfuerzo.
• Está almacenando datos de marcos de tiempo como TEXT . Desde el punto de vista del rendimiento y de la usabilidad, eso es un no-no.
• Su esquema actual no puede acomodar divisiones de acciones, lo que eventualmente ocurrirá. Es mejor agregar una capa adicional de direccionamiento indirecto entre la tabla de datos de precios y el Símbolo
• open precios open , high , low y close se almacenan mejor como tipos decimales o de divisas, o, preferiblemente, como un campo INTEGER con un campo INTEGER separado que almacena el divisor, como la fracción de precio más pequeña (centavos, ochos de un dólar, etc.) permitido varía por intercambio.
• Dado que admite múltiples intercambios, debe admitir varias monedas.

Me disculpo si todo esto no parece demasiado ''constructivo'', especialmente porque ahora tengo demasiado sueño para sugerir una alternativa más útil. Espero que lo anterior sea suficiente para encaminarte.

Answer 2

Intentamos encontrar una estructura de base de datos adecuada para almacenar gran cantidad de datos durante mucho tiempo. La solución a continuación es el resultado de más de 6 años de experiencia. Ahora está funcionando sin problemas para nuestro análisis cuantitativo.

Hemos podido almacenar cientos de gigabytes de datos diarios y diarios utilizando este esquema en SQL Server:

 Symbol -  char 6
 Date -  date
 Time -  time
 Open -  decimal 18, 4
 High -  decimal 18, 4
 Low -  decimal 18, 4
 Close -  decimal 18, 4
 Volume -  int

Todos los instrumentos de negociación se almacenan en una sola tabla. También tenemos un índice agrupado en columnas de símbolos, fecha y hora.

Para datos diarios, tenemos una tabla separada y no utilizamos la columna Hora. Volume datatype también es bigint en lugar de int.

¿El desempeño? Podemos sacar datos del servidor en cuestión de milisegundos. Recuerde, el tamaño de la base de datos es de casi 1 terabyte.

Compramos todos nuestros datos históricos del mercado desde el sitio web de Kibot: http://www.kibot.com/

Answer 3

No estoy seguro de qué valor se agrega por Timeframe , parece una complicación innecesaria, pero podría ser algo que no entiendo ;-) ¿Puede un Timeframe tener más de un OHLCV? Si no, entonces sugeriría que se fusionen.

También señalaría que los tickers de valores cambian de vez en cuando por varias razones. No es un evento frecuente, pero sucede. Si está pensando en trabajar con sus datos como series de tiempo, debe tener en cuenta el problema para poder manejarlo cuando se trata, si no antes. Si no realiza un seguimiento de las existencias (puede estar trabajando en una aplicación de futuros, por ejemplo), entonces este consejo puede tomarse con la cantidad apropiada de sal.

Una vez más relevante para las acciones, las divisiones se han mencionado en otros lugares y es posible que desee considerar los dividendos: el precio de una acción caerá típicamente por el monto del dividendo (o más exactamente el valor actual de la misma) en la fecha ex dividendo, que puede malinterpretarse si usted no sabe que un flujo de efectivo futuro confirmado fue la razón. Los problemas de derechos también pueden ser divertidos.

Si planeas buscar series de datos para un símbolo en particular, te sugiero que estudies qué tipo de rendimiento vas a obtener. Por lo menos, asegúrese de tener un índice apropiado en su lugar.