FRIHOSTFORUMSSEARCHFAQTOSBLOGSCOMPETITIONS
You are invited to Log in or Register a free Frihost Account!


MySql: Mais Tabelas e Menos Campos, ou vice-versa???





Aidmar
Olá a todos!!!

Eu preciso fazer um banco de dados para cadastrar 1.000 usuarios com aproximadamente 70 informações cada. O fica mais rápido: Fazer uma tabela para cada usuário e armazenar cada informação em um registro separado, ficando cada tabela com 3 campos no máximo, ou fazer uma única tabela com 70 campos e 1.000 registros, contendo todos os dados desses usuários???

Obrigado!!!
Deline
Isso depende do modo como você vai consultar seus dados, não? Dependendo pra você pode ser mais prestativo cada usuário com sua tabela...
D'Artagnan
Aidmar wrote:
Olá a todos!!!

Eu preciso fazer um banco de dados para cadastrar 1.000 usuarios com aproximadamente 70 informações cada. O fica mais rápido: Fazer uma tabela para cada usuário e armazenar cada informação em um registro separado, ficando cada tabela com 3 campos no máximo, ou fazer uma única tabela com 70 campos e 1.000 registros, contendo todos os dados desses usuários???

Obrigado!!!

aid eu não entendi, porque nas tabelas separadas (1000 tabelas , uma por usuario) as tabelas iriam ter 3 colunas e na tabela com 1000 registros haveriam 70 colunas?
como você pretenden acessar os dados no metodo com um usuario por tabela?


O correto pela normalização de dados é que exista um tabela de USUARIOS, com colunas para cada dado do usuario (NOME, EMAIL, TELEFONE) e linhas para cada usuario cadastrado exemplo

TABELA USUARIO

NOME | EMAIL | TELEFONE
joao | j@ao.c | 1414
carl | j@ao.c | 1334
jose | j@ko.c | 1455
joao | i@ao.c | 2214

creio que seria mais rapido e facil seguindo o padrao porque o mysql ja esta preparado para isso, não sei como seria ele tentando abrir uma tabela para cada consulta, no caso de uma listagem das 1000 tabelas.
mariohs
Não sei para que tipo de aplicação você vai usar esses dados, mas provavelmente vai ser melhor a idéia do D'Artagnan. Crie um registro para cada usuário, isso te dará escalabilidade. Assim, quando entrarem 200 usuários novos, não será necessário criar 200 tabelas, e sim, adicionar 200 registros.
Aidmar
Bem, a idéia é fazer um jogo estilo OGAME (www.ogame.com.br) e afins (eu sei, sei que já estou falando disso há MUITO tempo, mas tive que parar com o projeto por motivos de força maior...). O bd já está até pronto com uma única tabela com 70 campos, já que cada jogador terá que armazenar diversas informações como quantidade de recursos, nível das construções e edifícios construídos, pesquisas realizadas, etc. Então surgiu a idéia de fazer uma tabela para cada jogador. O nome da tabela seria o login do jogador, no primeiro campo eu armazenaria o nome da informação a ser gravada, no segundo seria o valor referente aquela informação, e talvez um terceiro campo com um índice, auto incremento, seilá... O caso é que eu tive a informação de que tabelas com muitos campos acabam tornando mais lentas as consultas, e como esta tem 70 campos, pensei em dividir isso de alguma forma. Esses 70 campos se tornariam 70 registros em uma tabela de 2 ou 3 campos. Só não sei se é viável...
D'Artagnan
No teu caso o jogo vai precisar de uma boa base de banco de dados é melhor usar o modelo normalizado ... até mesmo porque como você acessaria os dados de cada jogador? sendo que os jogadores vão se cadastrar gradativamente e cada um vai ter sua tabela... pode ser feito mas vc vai ter um belo trabalho para fazer isso.

Realmente fica lento acessar um tabela de 70 colunas com 10000 registros, mas acredito que vai ser bem mais rapido que pedir para o mysql abrir 10000 tabelas...

quando você for acessar os dados deum jogador especifico o esquema de 'uma tabela um jogador' vai funcionar legal, mas quando vc for listar os jogadores???

Quote:

70 campos se tornariam 70 registros em uma tabela de 2 ou 3 campos.


continuo sem entender, se sua tabela de usuarios atual vai conter 70 colunas como vc vai transformar essas colunas em 70 registro de uma tabela?


se eu fosse fazer um ogame da vida eu iria preferir ter um modelo de banco de dados forte e analizar o desempenho na hora de programar, já que a maioria dos gargalos de desempenho estão na consulta a banco e na execução do seu script.

vlw
mariohs
Eu faria algo diferente:
Criaria uma tabela de usuário com dados básicos (nome, email, etc) e criaria uma tabela de atributos, com as colunas: id do usuário, tipo, valor. Assim isso te dá uma escalabilidade tanto em número de atributos quanto em número de usuários. Não vai ser necessário criar uma nova coluna se existir um atributo novo. As colunas "id do usuário" e "tipo" deveriam ser indexadas, para melhor performance.

Mais uma vez, não sei qual o seu modelo de dados e nem a aplicação, para poder dar uma dica com maior embasamento.
Related topics
A solução do mundo?
Quais são os sites mais bonitos e funcionais?
MAC OSX - X86
Virus no msn
Preço do Petróleo
PROGRAMAÇÃO
Que livro você está lendo ou leu recentemente?
Qual é o melhor Sistema Operacional ?
Aonde vamos parar ?
Teste psicológico de Carl Jung
Você gosta de Carnaval , Responda o porque ?
Você já sentiu vontade de escrever (ou escreveu) um livro?
O quanto vc gosta de futebol? SPFC campeão 2008
[ notícia ] Michael Jackson morre aos 50 anos
Reply to topic    Frihost Forum Index -> Language Forums -> Portuguese

FRIHOST HOME | FAQ | TOS | ABOUT US | CONTACT US | SITE MAP
© 2005-2011 Frihost, forums powered by phpBB.