Quero uma dica de boa prática de programação para Banco de Dados MySQL?
20/03/2016
0
Então, tenho uma tabela "usuarios" que registro o user_name de cada cliente, após cadastro, meu sistema gera uma tabela: username_cliente, username_fornecedores e libera o acesso e tal, enfim, a pessoa tem acesso ao controle daquelas tabelas.
Se tiver 2 cadastro, a e b, geraria as tabelas a_clientes e b_clientes. Mas o problema é que geralmente meus sistemas tem mais de 10 tabelas, a cada usuário se cadastra essas tabelas são multiplicadas, [b]atualmente SÓ EM um banco meu tem 6545 tabelas[/b]. Pensei em colocar os dados tudo na mesma tabela e utilizar uma chave em cada tabela para identificar o usuário, mas dessa forma seria muito fácil incluir um dado de 1 cliente em outro cliente por engano, ou mesmo listar dados de um cliente para outro.
Enfim, minha pergunta é até que ponto isso é tranquilo?
Supondo que almeje 2.000 clientes, e tenha uma média de tabelas de 15, isso daria 30 mil tabelas em um mesmo banco de dados, apesar que os dados contidos em cada uma são poucos. Isso faria diferença, se tivesse os mesmos dados, mas em um conjunto fixo de tabelas?
Qual melhor saída para mim não vir a ter dores de cabeça depois?
Rangel Alves
Post mais votado
20/03/2016
[url]https://www.devmedia.com.br/boas-praticas-na-modelagem-de-dados/30022[/url]
[url]https://jmmwrite.wordpress.com/2007/12/19/boas-praticas-em-sql-para-desenvolvedores/[/url]
Marilia Silva
Mais Posts
20/03/2016
William
Além das imobiliárias poderem cadastrar imóveis em seus administrativos, ainda é possível importar arquivos XML com mais de 1000 imóveis e identificar a imobiliária.
Chegamos nesse termo porque todas possuem o mesmo tipo de recurso, então não tinha sentido em criar bancos ou tabelas separadas.
20/03/2016
Marilia Silva
Espero que seja, pelo que estudei as melhores praticas devem começar na modelagem, é apartir desse momento que se deve saber se o banco será bom ou viverá de remendos.
20/03/2016
Rangel Alves
20/03/2016
William
Além das imobiliárias poderem cadastrar imóveis em seus administrativos, ainda é possível importar arquivos XML com mais de 1000 imóveis e identificar a imobiliária.
Chegamos nesse termo porque todas possuem o mesmo tipo de recurso, então não tinha sentido em criar bancos ou tabelas separadas.
Só prestar atenção no que está fazendo, minha tabela tem poucos registros 30.000 mas não dá problema.
No meu caso ainda tenho um agravante, tem que ser separado por imobiliária e por corretor, então o SELECT é mais criterioso ainda.
20/03/2016
Rangel Alves
Além das imobiliárias poderem cadastrar imóveis em seus administrativos, ainda é possível importar arquivos XML com mais de 1000 imóveis e identificar a imobiliária.
Chegamos nesse termo porque todas possuem o mesmo tipo de recurso, então não tinha sentido em criar bancos ou tabelas separadas.
Só prestar atenção no que está fazendo, minha tabela tem poucos registros 30.000 mas não dá problema.
No meu caso ainda tenho um agravante, tem que ser separado por imobiliária e por corretor, então o SELECT é mais criterioso ainda.
Certo, mas o problema é que já tenho muita coisa pronta e foi usado a lógica do prefixo da tabela, porque no inicio não era para vários clientes e sim cada um com uma instalação separada.
Então, bom, pelo vi é bom deixar uma key na tabela, seria mais recomendado. Mais minha pergunta é, se eu deixar do jeito que está e o banco crescer, vou ter problemas maiores que se colocasse em uma única tabela, é significativo a diferença entre ter vários dados em várias tabelas e ter vários dados na mesma tabela?
20/03/2016
William
20/03/2016
Rangel Alves
20/03/2016
William
Sinceramente eu acho um desperdício de espaço, ainda mais agora que vc falou que a escrita é muito pouca.
Você usa hospedagem ou servidor dedicado?
20/03/2016
Rangel Alves
Sinceramente eu acho um desperdício de espaço, ainda mais agora que vc falou que a escrita é muito pouca.
Você usa hospedagem ou servidor dedicado?
Entendi, sobre o espaço, estou mais tranquilo, pois este exemplo citado é um "serviço GRATIS" que fiz, coisa simples. Mas quando aos sistemas que estou fazendo agora serão serviços pagos, controles para empresas, lojas, enfim, todo meu acervo desktop em delphi, portanto se tiver 100 clientes pagantes em cada um, terei condições de contratar muito mais hospedagem, dividir os bancos em vários servidores, enfim, até de começar do zero tudo para otimizar.
Utilizo uma revenda! Sobre o tamanho, entendo que está pesado e assim que dêr, vou rescrever todos os códigos (se atingir uma meta de clientes). Mas minha dúvida é se vai atrapalhar desempenho e principalmente se corre algum risco de segurança de perder dados?
21/03/2016
Marcos P
A questão de "perda de dados" não tem relação alguma com o modelo de dados que você utiliza em seus sistemas, pois, "perda de dados", nesse cenário, ocorre através de problemas físicos relacionados ao banco de dados. Deixar os cadastrados separados em tabelas especificas ou trabalhar em um único conjunto de tabelas, não aumenta ou diminui esse risco.
Já do ponto de vista de funcionamento da aplicação, ambos dependem de implementar uma lógica especifica que permita isolar os clientes no modelo de dados.
Atualmente, você já tem uma lógica que trata disso em tabelas separadas, poderá trocar essa arquitetura por uma que isole os dados em tabelas únicas. Ambas, acabam sendo implementações válidas do ponto de vista de funcionamento do ambiente.
Quanto à sua pergunta original : qual a boa prática do lado do banco de dados, o modelo baseado em tabelas unificadas é melhor, pois :
> Reduz ( enormemente ) o número de tabelas no sistema
> Centraliza o throghput de dados pelo gerenciador
> Otimiza a utilização de metadados e o espaço usado nas tabelas
> Simplifica a atualização e utilização de estatísticas de índice
> Simplifica as rotinas de manutenção do banco de dados
21/03/2016
Marilia Silva
21/03/2016
Rangel Alves
A questão de "perda de dados" não tem relação alguma com o modelo de dados que você utiliza em seus sistemas, pois, "perda de dados", nesse cenário, ocorre através de problemas físicos relacionados ao banco de dados. Deixar os cadastrados separados em tabelas especificas ou trabalhar em um único conjunto de tabelas, não aumenta ou diminui esse risco.
Já do ponto de vista de funcionamento da aplicação, ambos dependem de implementar uma lógica especifica que permita isolar os clientes no modelo de dados.
Atualmente, você já tem uma lógica que trata disso em tabelas separadas, poderá trocar essa arquitetura por uma que isole os dados em tabelas únicas. Ambas, acabam sendo implementações válidas do ponto de vista de funcionamento do ambiente.
Quanto à sua pergunta original : qual a boa prática do lado do banco de dados, o modelo baseado em tabelas unificadas é melhor, pois :
> Reduz ( enormemente ) o número de tabelas no sistema
> Centraliza o throghput de dados pelo gerenciador
> Otimiza a utilização de metadados e o espaço usado nas tabelas
> Simplifica a atualização e utilização de estatísticas de índice
> Simplifica as rotinas de manutenção do banco de dados
Muito bem explicado. Então, posso deixar meu sistema rodando tranquilo do jeito que está, apesar de não ser o ideal, não vou ter problemas?
21/03/2016
Rangel Alves
A título de "melhores práticas", eu optaria por unificar as tabelas...
Certinho, vou fazer isso em próximas atualizações, mas é um sistema muito grande de é tudo integrado, por exemplo, tenho o modulo "caixa", ele é o mesmo em 10 sistemas diferentes, apenas com as configurações que mudam.
Clique aqui para fazer login e interagir na Comunidade :)
