Início / dba / Perguntas / 279133
Accepted
LBJ33
Asked: 2020-11-04 09:31:35 +0800 CST

Otimização do MySQL - mais tabelas vs mais colunas/linhas

  • 772

Sou novo em SQL e estou procurando construir um banco de dados. Como exemplo do que estou tentando fazer é ter um banco de dados com cerca de 5000 cotações de ações. Cada ticker terá cerca de 35 data-points, correspondentes a datas específicas. Todos os dados serão INT ou uma pequena string.

Eu estou querendo saber se é melhor ter cada ticker representando uma tabela, com todos os seus pontos de dados dentro da tabela (cerca de 15 colunas e 20 linhas), ou devo colocar tudo isso em uma tabela, com o índice sendo o símbolo do ticker , então tendo um monte de colunas.

Parece mais fácil fazer uma nova tabela para cada ticker, pois posso colocar os títulos das colunas como datas e os títulos das linhas como o que os dados representam, mas não tenho certeza se isso está otimizado ou causaria problemas com várias pessoas pesquisando tabelas diferentes.

Obrigado!

EDIT: Aqui está um exemplo da tabela que estou procurando criar, é possível ter índices de 2 linhas?

insira a descrição da imagem aqui

mysql python

1 respostas

  1. Best Answer

    Uma mesa. Período. Ponto final.

    Uma regra geral é não ter várias tabelas "idênticas". É um problema de manutenção e provavelmente será mais lento. (A exceção comum é SaaS, como WordPress, onde eles simplesmente vivem com muitas bases de dados com as 'mesmas' 20 tabelas.)

    "35 datapoints ... datas" -- estou confuso. Ou você tem informações sobre uma ação ou tem preços diários de anos atrás. Você está economizando apenas 5 semanas de dados? Ou o que você quer dizer?

    5 mil linhas em uma tabela são "pequenas" conforme os conjuntos de dados.

    Isso também tem preços de ações para cada dia? Com isso, você chega a milhões ou talvez bilhões de linhas de cerca de 6 colunas. Mais uma vez, recomendo fortemente uma única mesa para todos os preços. (Além de uma tabela para todos os tickers - novamente 5 mil linhas de 30 colunas.)

    Eu lidei com esses conjuntos de dados, então pergunte. Ou olhe ao redor; Eu respondi perguntas como esta neste fórum e também em stackoverflow.com

    A tabela de preços teria algo como

    stock_id MEDIUMINT UNSIGNED -- 2 bytes
dy DATE  -- 3 bytes
open, high, low, close   -- see below

    Os preços ficam complicados.

    FLOAT -- ~7 significant digits, 4 bytes; maybe good enough, might have roundoff
DECIMAL -- but how many decimal places; potentially bulky
INT -- not good enough
DOUBLE -- 8 bytes; overkill

    A indexação será importante, mas primeiro, descubra como são as inserções e seleções. Estes podem ser ideais:

    PRIMARY KEY(stock_id, dy)
INDEX(dy, stock_id)

    Por um lado stock_id, haverá muitas linhas. Não use 'muitas' colunas para um "array"; isso é muito chato. Talvez suas datas sejam "trimestrais", como nos relatórios da empresa, e não "diárias", como nas ações?

    5.000 empresas com 8 anos de relatórios trimestrais, em uma linha cada == 160 mil linhas na tabela única. Isso ainda é uma mesa "pequena".

    Mais outra tabela com 5000 linhas, uma por empresa, com nome, endereço, etc. Ou seja, atributos que não mudam.

    Sim, renda, saldo, fluxo de caixa, etc devem ser colunas separadas na tabela. Supondo que esses valores venham de um relatório trimestral, eles estariam na tabela de 160 mil linhas que discuti acima.

    Uma tabela com algumas dezenas de colunas e alguns milhões de linhas não é problema (em geral). Se você chegar a 100 colunas ou um bilhão de linhas, poderá encontrar problemas não triviais.

    • 2

relate perguntas