Design de banco de dados ruim - minha tabela é muito grande?

Question

Eu tenho um banco de dados mal projetado. Uma das tabelas mais importantes tem mais de 11.000 entradas. Gostaríamos de expandir nosso sistema, e estou me perguntando se essa tabela cresceu para 5x do seu tamanho, isso seria um problema? É 15360 kb de tamanho ... se isso importa.

---

Estou usando o phpmyadmin, o servidor é uma caixa do Fedora Linux (nada extravagante), a carga é leve. Ele armazena quase tudo o que nosso sistema usa.

Answer 1

Entendo que você está preocupado se aumentar o número de registros para cerca de 55.000 em "Seu banco de dados mal projetado" afetará o desempenho.

Se você funcionará como esperado agora, acho que você deve ficar bem com 50.000 registros também, a menos que você já tenha alguns pequenos problemas de desempenho.

Como a maioria das pessoas mencionou que 50k registros é um número muito pequeno em relação ao tamanho da tabela do banco de dados e, mesmo com o banco de dados não normalizado, não deve haver problemas de desempenho.

Se você planeja expandir a funcionalidade do seu sistema, talvez seja um bom momento para olhar para o design do banco de dados, caso contrário, deve ser razoavelmente seguro deixá -lo como está.

Answer 2

O que DBMS? Qual servidor? Que carga? Qual aplicativo?

Além disso: 11.000 registros não são nada, realmente. Mesmo no acesso à MS. :-)

EDIT: Então, suponho que você use um MySQL bastante recente com as tabelas Myisam. Em teoria, você pode seguir em frente e preencher a mesa nos milhões de registros. Dependendo de como você trabalha com eles (muitas junções / ou não, muitas consultas / atualizações / exclusão / ou não), você não precisa fazer nada de especial. Coloque um índice adequado na tabela e você ficará bem.

Answer 3

Eu não acho que você está fornecendo informações suficientes para alguém dar uma resposta. Por que é mal projetado? Não é normalizado? Você não tem índices? Qual é o banco de dados? Em que sistema operacional está funcionando? Quanto tempo leva agora para consultar um registro da tabela em questão?

Answer 4

11k entradas não são tantas. 50k também não é grande.

Colocar os índices na tabela (otimizado para as consultas que você executará nela) permitirá um bom desempenho para quantidades muito maiores do que o que você está imaginando.

Se o design for ruim o suficiente, você poderá olhar para o custo de redesenho.

Answer 5

O que você quer dizer com um "banco de dados mal projetado"?

Se for mal projetado, redesenhe -o, arraste as informações para as tabelas atuais e preencha a nova.

Se você está preocupado com o desempenho, 11000 entradas não são grandes. Um banco de dados de 15 megabytes é extremamente pequeno, por padrões de banco de dados.

Answer 6

O tamanho de uma tabela não é muito importante. O design da chave, índices e relacionamentos tem muito mais a ver com a qualidade do design do que o tamanho dos dados contidos nele. Obviamente, existem advertências nisso; Mas otimizar o tamanho de uma tabela está perto da última coisa que faço ao trabalhar em um problema de desempenho ou design.

Você pode explicar mais sobre por que você acha que este é um banco de dados mal projetado e o que você pode (facilmente) fazer para corrigir os problemas. Junto com isso, você deve detalhar o tipo de DBMS e qual é o uso (aplicativo da web, aplicativo personalizado, relatórios etc.).

Answer 7

15 MB não é nada. 11k linhas também. Eu tenho bancos de dados com mais de 2 GB de dados, com algumas tabelas contendo mais de 1 milhão de linhas e considero que estar em algum lugar entre pequeno e médio tamanho.

Answer 8

Você realmente não deu nenhuma evidência para apoiar sua alegação de que este é um banco de dados mal projetado. O que o torna mal projetado? A tabela possui 876 colunas? As colunas são chamadas col1, col2, col3 ...? Ele usa um flutuador e um tempo de dados como uma chave primária composta? É mal normalizado? A única coisa que sabemos é a contagem de recordes.

Answer 9

11K registros geralmente não são nada em termos de banco de dados.

O que mais faz você pensar que o banco de dados é mal projetado, além do número de registros na tabela?

Answer 10

Você precisa fornecer muito mais informações sobre a estrutura da tabela.

Em geral, 15.000 linhas em uma tabela seriam consideradas pequenas, de fato tão pequenas, que alguns designers podem nem se incomodar em indexá -la.

Answer 11

Uma base ruim será o seu erro mais caro. Se a tabela for importante, você precisa decidir como é importante corrigi -la. A quantidade de linhas em uma tabela afeta apenas a velocidade na qual você pode extrair coisas dela. Mas, se você tiver um design de banco de dados ruim para começar, suas mãos ficarão amarradas em certos lugares no caminho.

Answer 12

Se você estiver falando sobre o SQL Server 2005, procure o SQL Server Profiler e use o Assistente de Tuning Index.

Também há suporte em alguns bancos de dados para fixação de tabela na memória, se você quiser um desempenho adicional.

Answer 13

O que um registro é composto pode importar mais do que quantos registros estão em uma tabela.

Onde eu trabalho, temos bancos de dados com inúmeras tabelas com contagens de registros nas dezenas de milhares ou centenas de milhares. Nossos bancos de dados são considerados pequenos, na maioria das vezes.

Answer 14

Se você vai expandir seu sistema, agora é a hora de redesenhar, se necessário. É muito menos doloroso redesenhar quando você tem 11.000 registros do que quando tem 10 milhões. No entanto, nada que você disse indica para mim que você precisa redesenhar. Não há nada inerentemente errado em ter junções (na verdade, um banco de dados bem projetado deve tê -los). Publique alguns detalhes sobre o Structure e podemos ajudá -lo a decidir se é necessário redesenho.

É possível que o problema seja que você e seus colegas simplesmente não tenham experiência no acesso ao banco de dados e não saibam como consultá -los de maneira eficaz e fácil. Ou o problema pode ser que o design seja ruim, sem detalhes da estrutura, é difícil dizer.