Array
(
    [0] => stdClass Object
        (
            [Votos_Balanceados] => 1
            [id] => 549039
            [titulo] => Quero uma dica de boa prática de programação para Banco de Dados MySQL?
            [dataCadastro] => DateTime Object
                (
                    [date] => 2016-03-20 13:39:26
                    [timezone_type] => 3
                    [timezone] => America/Sao_Paulo
                )

            [isFirstPost] => -1
            [idUsuario] => 392972
            [status] => A
            [isExample] => 
            [NomeUsuario] => Marilia Silva
            [Apelido] => 
            [Foto] => 392972_20141027151306.jpg
            [Conteudo] => Li e entendi um pouco, pela minha pouca experiencia, achei os seguintes links, espero que ajude de verdade:

[url]http://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] ) )

Quero uma dica de boa prática de programação para Banco de Dados MySQL?

Rangel Alves
   - 20 mar 2016

Vou tentar ser bem simples e direto em meu objetivo, estou fazendo migrando todos meus programas desktop em Delphi para versões online em PHP, cada usuário cadastra e tem seu sistema pronto de controle, para fins de exemplo, vamos supor um sisteminha muito simples, o produto é cadastro de clientes e fornecedores.
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, atualmente SÓ EM um banco meu tem 6545 tabelas. 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?

Post mais votado

Marilia Silva
   - 20 mar 2016

Li e entendi um pouco, pela minha pouca experiencia, achei os seguintes links, espero que ajude de verdade:

http://www.devmedia.com.br/boas-praticas-na-modelagem-de-dados/30022

https://jmmwrite.wordpress.com/2007/12/19/boas-praticas-em-sql-para-desenvolvedores/

1
|
0

William (devwilliam)
   - 20 mar 2016

Olá Rangel, administro um sistema imobiliário WEB onde 10 imobiliárias compartilham 20 tabelas, simplesmente identifico qual o código da imobiliária nos cadastros, funciona muito bem.

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.

0
|
0

Alan Mario
   - 20 mar 2016

Qual a seria a boa pratica? alguma fonte senhores?

0
|
0

Alan Mario
   - 20 mar 2016

Deve ser um dos caminhos para estudar Marilia.

0
|
0

Marilia Silva
   - 20 mar 2016


Citação:
Deve ser um dos caminhos para estudar Marilia.


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.

0
|
0

Rangel Alves
   - 20 mar 2016

Bem são muitos legais os artigos, mas já pratico tudo isso com tabelas, minha dúvida não é quanto a estrutura e padronização das tabelas, mas especificamente o seguinte: do ponto de vista do código, é mais fácil utilizar 1 tabela para cada empresa diferente, pois facilita backups, exclusões, etc. Mas minha real dúvida é, isso é prejudicial para o banco de dados, seria realmente melhor utilizar um conjunto fixo de tabelas e utilizar uma key para identificar e separar cada key. Porque veja bem, se eu fizer isso, cada select vai ter um especificidade, cada vez que excluir um registro, preciso fazer uma pré verificação se aquele registro é daquela empresa, no geral, usar a mesma tabela abriria brechas e faria com que, um usuário pode explorar para prejudicar outros.

1
|
0

William (devwilliam)
   - 20 mar 2016


Citação:
Olá Rangel, administro um sistema imobiliário WEB onde 10 imobiliárias compartilham 20 tabelas, simplesmente identifico qual o código da imobiliária nos cadastros, funciona muito bem.

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.

0
|
0

Rangel Alves
   - 20 mar 2016


Citação:

Citação:
Olá Rangel, administro um sistema imobiliário WEB onde 10 imobiliárias compartilham 20 tabelas, simplesmente identifico qual o código da imobiliária nos cadastros, funciona muito bem.

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?

0
|
0

William (devwilliam)
   - 20 mar 2016

Já trabalhei com MySQL rodando 86 milhões de registro, indexando os campos certos não dá problema na consulta, quanto ao tamanho do banco é relativo, tem que ver quantos campos tem em cada tabela, qual o tamanho dos índices e qual a proporção de crescimento desse banco mensalmente.

0
|
0

Rangel Alves
   - 20 mar 2016

Tenho um sistema com 3.107 clientes cadastrados, isso gerou 24.856 tabelas. Mas é um sistema simples, apenas configurações, os dados da tabela muda pouco, a maioria os dados estão em no máximo 10 registro, ele só muda não acrescenta, só 2 tabelas realmente pega uns dados a mais, mas muita gente cadastra e não usa, coisinha simples, o banco tá com 296.86 MB.

0
|
0

William (devwilliam)
   - 20 mar 2016

Uma continha básica com suposições, se vc aumentar seus clientes para 9.000, seu banco vai chegar em algo perto de 1GB.

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?

0
|
0

Rangel Alves
   - 20 mar 2016


Citação:
Uma continha básica com suposições, se vc aumentar seus clientes para 9.000, seu banco vai chegar em algo perto de 1GB.

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?

0
|
0

Marcos P
   - 21 mar 2016

Rangel,

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

1
|
0

Marilia Silva
   - 21 mar 2016

OK Rangel Alves, estava pensando que esses artigos era o que estava procurando. :-).

0
|
0

Rangel Alves
   - 21 mar 2016


Citação:
Rangel,

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?

0
|
0

Marcos P
   - 21 mar 2016

Funcionalmente, nenhum problema em deixar como está !

A título de "melhores práticas", eu optaria por unificar as tabelas...

0
|
0

Rangel Alves
   - 21 mar 2016


Citação:
Funcionalmente, nenhum problema em deixar como está !

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.

0
|
0