Ir para conteúdo

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

ericmaicon

Antes de fazer uma boa modelagem!

Recommended Posts

Boa noite pessoal!!

 

Estou criando um programa que poderá ter um possível futuro. Não quero q ele tenha uma base fraca no início, logo estou apostando bastante na modelagem, até pq quero tratar minha regra de negócio no banco!

 

Tive algumas dúvidas e gostaria de perguntar ao senhores:

 

1 - Até que ponto é favorável utilizar uma tabela Entidade e dela desmembrar os usuários, clientes, fornecedores? Digo...sempre é bom até para sistemas pequenos ou só para ERPs da vida?

2 - Nesse ambiente citado acima, é bom criar uma tabela usuário por exemplo e uma cliente, que tem chaves estrangeiras de entidade....ou é melhor criar uma tabela chamada tipo, com registros de usuário, cliente e vincular à entidade?

3 - Existe algum padrão (como por exemplo camelcase em programação) para nomes de tabelas? algum link para indicar?

4 - existe atualmente algum aplicativo que possa nos dar um rumo relacionado ao teste do MER depois de pronto?

5 - Existe algum material que menciona melhores práticas?por exemplo: em um indicador é melhor utilizar um campo do tipo numeric por se consumir menos bytes do que um varchar2...

 

Obrigado galera!

Compartilhar este post


Link para o post
Compartilhar em outros sites

1 - Até que ponto é favorável utilizar uma tabela Entidade e dela desmembrar os usuários, clientes, fornecedores? Digo...sempre é bom até para sistemas pequenos ou só para ERPs da vida?

 

Como assim, você diz uma tabela chamada Entidade, onde clientes, usuários e fornecedores são distintos por enumeração?

 

Depende, mas na maioria das vezes é melhor uma tabela para cada tipo. Uma pra cliente, outra pra usuário e outra pra fornecedores.

 

 

 

2 - Nesse ambiente citado acima, é bom criar uma tabela usuário por exemplo e uma cliente, que tem chaves estrangeiras de entidade....ou é melhor criar uma tabela chamada tipo, com registros de usuário, cliente e vincular à entidade?

 

Bom se o cliente ou usuário só tem 1 entidade, então o tradicional é colocar a chave estrangeira da entidade nela.

 

 

3 - Existe algum padrão (como por exemplo camelcase em programação) para nomes de tabelas? algum link para indicar?

 

Não, faça o seu.

 

 

4 - existe atualmente algum aplicativo que possa nos dar um rumo relacionado ao teste do MER depois de pronto?

 

Não sei. Acho que isso depende também do SGBD.

 

 

5 - Existe algum material que menciona melhores práticas?por exemplo: em um indicador é melhor utilizar um campo do tipo numeric por se consumir menos bytes do que um varchar2...

 

Não sei. Normalmente a doc. do SGBD já resolve.

Compartilhar este post


Link para o post
Compartilhar em outros sites
2 - Nesse ambiente citado acima, é bom criar uma tabela usuário por exemplo e uma cliente, que tem chaves estrangeiras de entidade....ou é melhor criar uma tabela chamada tipo, com registros de usuário, cliente e vincular à entidade?

Existem 2 possibilidades que eu julgo melhor, vai depender do seu conjunto de dados.

 

Quantos atributos em comum tem usuários, clientes, fornecedores?

Existem muitos relacionamentos em comum a essas entidades?

Se for uma quantidade razoável (de um dos dois), vale a pena você criar uma tabela para conter esses atributos e utilizar de herança para as especializações.

Para isso, aí sim você cria uma tabela para cada tipo, uma usuario, uma cliente, uma fornecedor e relaciona os dados dessas tabelas com os dados da primeira por FK.

 

Se essa quantidade de atributos em comum for pequena, tal como o numero de relacionamentos em comum, vale apena separar de vez e criar uma tabela pra cada tipo, sem utilizar herança...

 

3 - Existe algum padrão (como por exemplo camelcase em programação) para nomes de tabelas? algum link para indicar?

Cara, o mais comum por aí é não usar camelCase, e sim lower_underscore_case.

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.