Uma única tabela para cliente, fornecedor etc ou uma tabela para cada?

Banco de Dados
#1

Bom dia,
Iniciei minha atividade de hobista em programação e com banco de dados em 1992 com dbase III.
De la para cá muita coisa mudou. E comecei a práticar meu hobby com SGDB´s de verdade, não considero DBF como SGDB.
Mas vi duas práticas:

  1. Alguns criam tabelas para cada situação: fornecedor, clientes, prestados de serviço, transportadora.
    Neste sistema se uma PJ é fornecedor e cliente ao mesmo tempo haverá dois cadastros.
  2. Outros preferem deixar tudo numa mesma tabela e so adicionam campos para marcar se são clientem, fornecedores e etc.
    Neste sistema se uma PJ é fornecedor e cliente ao mesmo tempo haverá somente um cadastro e basta marcar nos campos apropriados da tabela o que a pessoa jurídica é.
    Qual a vantagem de cada sistema? Em que caso pode-se aplicar cada um? Em um sistema multiempresa é vantagem ter qual dos sistemas? Para databases que ficarão enormes é vantagem usar a escolha 2?
    Estou numa empreitada com um projeto de software-livre e opensource e desejo respostas antes de prosseguir.
    Como disse sou hobbista tenho poucos trabalhos renumerados neste setor. Logo, conto com a resposta de mais experientes.
    Página do projeto: http://codigolivre.org.br/projects/brasillivre/
    Obrigado

PS: Irei usar o SC neste rojeto.

#2

Alê,

Seguinte… o grande sucesso de um sistema está na modelagem do seu DB… há situações em que um banco extremamente normalizado seja de grande valia (80% dos casos) isso porque você evita o re-trabalho e consequentemente diminuem-se as chances de erros. Muitos DBA´s defendem essa tese.

Mas nem tudo são flores - normalização excesiva tem um custo muito alto… são muitas requisições ao banco, consequentemente muita memória e muito rocessador… há também que se ter um forte conhecimento em SQL, coisa que a maioria dos desenvolvedores não têm pois são tarefas muito próprias de DBA´s - e, de um modo geral, tudo que é normalizado precisa ser desnormalizado em algum momento. Então o ideal é um meio termo.

Existem situações em que a desnormalização é extremamente necessária - são os casos dos DWs e BIs… e todo sistema bem montado deverá contemplar pelo menos uma dessas ferramentas gerenciais.

Meu conselho: defina corretamente os objetivos do seu sistema, a que ele se propõe, tenha uma correta definição dos estudos de casos. Feito isso escolha o que é melhor… a decisão é sua.

Conheço sistemas que foram muito bem modelados, bastante normalizados e quando entraram em produção o banco não aguentava.

Forte abraço.

#3

Está aí um assunto que gosto de discutir.

Vamos lá.

Primeiro eu me baseio em normas de modelagem, e a que sigo é modelagem em banco de dados relacional com base na metodologia defendida por Carlos A. Heuser no livro “Projeto de Bando de Dados”.

Costumo usar o brModelo (software livre, impressionantemente pequeno em bytes, desenvolvido por um universitário para defender a tese acima).

Fornecedor é uma entidade, Clientes é outra entidade, só por aí já esta claro que devem ser tabelas diferentes, existem atributos em clientes que não são necessários em fornecedores, assim como contas a pagar e contas a receber pertencem a uma mesma espécia: Títulos, nada impede de ser numa mesma tabela ou não, mas os campos serão os mesmos para os dois tipos, a receber e a pagar, e como fica o relacionamento com fornecedores e clientes caso titulos seja uma única tabela, aí entram as views, e assim vai.

Usar o BRModelo, e conhecer essa metodologia, faz a diferença na modelagem de um banco de dados.

#4

Obrigado pelas respostas Haroldo e Jovito

#5

Alexandre,

Penso que isso é uma questão mais de gosto do que técnica. Eu sempre me via neste tipo de dilema quando estava começando a modelar banco de dados. Com a experiência, aprendi que sempre que você tem duas tabelas que podem ser uma, faça uma. Ou seja, se vc tem duas tabelas com poucos campos que não estão contidos em uma ou outra tabela, prefira fazer uma. Com os SGBDs atuais o tamanho do banco é a capacidade do sistema em que está instalado. Se vai ser multiempresa, é apenas mais um campo na tabela que identifica o registro. Vai fazer pouquíssima diferença.

O que deve ser observado, é o tipo de dados certo para o campo. Se vc tem um dados varchar 30, não deve setar o campo com varchar 255. Outra coisa importante são os índices da tabela.

Uma solução hipotética seria vc fazer uma tabela para os dois casos e criar uma view para cada caso. Numa pesquisa por fornecedor vc consome dados da view fornecedor, se for cliente consome da cliente. Isso se essa tabela for realmente muito grande.

#6

Também gosto deste assunto…

Fornecedor é uma entidade e Cliente é outra se assim for desenhado. Se eu tenho uma regra que define que um registro pode ser cliente ou fornecedor é uma questão de escolha criar ou não duas entidades. E como vou tomar a decisão? Baseado na quantidade de atributos diferentes que uma tem em relação a outra e no relacionamento com outras entidades. Colocando na balança, se eu tenho mais atributos iguais do que diferentes, estas duas entidades podem ser uma. Nunca “devem ser” e sempre “podem ser” uma.

Sobre a normalização o Jovito falou pouco mais falou bonito. rsrsrs
Eu só normalizo o que necessariamente tem que ser normalizado. Principalmente se a camada de aplicação for desenvolvida em SC.

#7

No meu campo de visão, a normalização deve ser aplicada em 100% da modelagem, mas porque?

Porque não sou detentor do código e único mantenedor dele, eu penso sempre em desenvolver para que qualquer um da minha equipe possa entender e manter, sendo assim, todos da equipe seguimos uma mesma metodologia e aplicamos 100% dela, para não ficar nada pessoal.

Mas se for apenas você que vai mexer por toda a vida no aplicativo, a forma que adotar só vai interferir em performance e custo em disco, pois o conceito estará em sua própria memória e não terá dificuldade para entender a modelagem depois de meses ou anos da sua criação.

#8

A própria normalização é subjetiva. Um pode normalizar de acordo com sua visão, outro pode normalizar diferente. Aplicar normalização em 100% da modelagem não garante que um entenda o projeto do outro. O que garante isso, como vc citou é metodologia, sintonia da equipe e documentação.

#9

se a equipe for treinada num mesmo método, o entendimento de como fazer será mais parecido , semelhante do que cada um não usar método algum, e é para isso que normas são criadas, para que se desenvolvam num padrão. Por isso existem os ISOs, ITILs, e diversas outras siglas.

http://sis4.com/brModelo/

#10

Normalização neste caso é diretamente ligado ao conceito de relacionamento. Deve ser aplicado conforme o objetivo. É preciso ter mais desempenho no banco ou na aplicação? A normalização deve ser usada respondendo a primeira ou a segunda pergunta e é por isso que existem mais de uma forma normal. Ainda, atualmente trabalhamos até a terceira forma normal, mas na pré-história dos SGBDs existiam formas normais, hoje em desuso. Agora é claro que existem padrões de projeto que devem ser seguidos e se o trabalho é feito em equipe, a equipe define a metodologia e pau na brasa.

Normalização é tão útil quanto desnecessária. Tanto é que a moda agora é banco de dados Non-SQL, banco de dados não relacionais, como por exemplo o MongoDB.

Também uso o brModelo.

#11

Acho que uma tabela relacional que defina quem é o que mata o assunto.
Acho que como já foi dito, é mais uma questão de gosto e experiência do que de melhor ou pior maneira.

Eu trabalho com desenvolvimento web faz uns 8 anos, focava na parte de programação e não me preocupava muito com banco, ou as melhores práticas de design de banco. Hoje eu vejo que um banco de dados bem elaborado, e mais ainda, elaborado de uma forma fácil de entender economiza cerca de 40% do tempo de desenvolvimento, se não mais que isso!!

O projeto a que me dedico a cerca de 2 anos já teve várias alterações nas tabelas porque encontrei maneiras mais rápidas de fazer determinadas coisas, mas como o Jovito mesmo disse, nesse meio tempo aprendi que a normatização por si só trás mais dores de cabeça para desenvolvedores autônomos como eu do que facilitam a vida.

#12

Eu comecei em 1980, com cobol de mainframe, não tinha acesso a modelagem, era uma equipe (elitizada) que só mexia com isso, e nós programadores, eramos apenas os extratores de dados, cujo os programas só seriam publicados com a autorização e homologação deles. Com o tempo o programador começou a se tornar analista, e a fazer os dois ao mesmo tempo, hoje temos o conceito de dba, onde um especialista constrói e otimiza as bases. O que vem primeiro é o banco de dados, a aplicação é uma das camadas, então um conjunto de regras para tornar esse banco rápido ao mesmo tempo prático, e com o menor custo de disco possível, é a visão perfeita, mas o equilíbrio entre praticidade e performance deve ser considerado.

#13

Partilho da ideia do Haroldo gostei muito dos argumento levantados por todos nessa discussão, mas a modelagem é essencial, eu sou um programador novo, só tenho 05 anos de experiência, onde 2 foram com sites, e 3 em sistemas web, que é o segmento que trabalho hoje, à 2 anos atras eu comecei a estudar modelagem por conta própria em artigos no livro citado pelo Haroldo, “Projeto de Banco de Dados” nos primeiros posts, e o brModelo é um software incrível eu nunca vi um software tão pequeno capaz de tanta coisa.

Eu deixei de trabalhar como programador php, onde eu só controlava código php de um biblioteca pronta, de uma área pré determinada, e recentemente fui contratado como desenvolvedor e para trabalhar com ScriptCase, eu não tenho nem um mês de ferramenta ainda mas já posso ver que é muito boa, meu primeiro projeto é um Control Center completo baseado no ITIL, e eu acho que se não fosse a modelagem e o TDD, o software não teria a qualidade que se espera de um Control Center.

Concluindo, Fornecer e Clientes na mesma tabela são para os antigos ERPs mal estruturados e que precisam de suporte 24h sem documentação… grrrr que me da um nervosoooo.

Bom essa é a minha opnião.

#14

Pessoal,

Esse é um tema realmente muito gostoso…
Eu entendo que o que discutimos aqui são as melhores práticas, pq a concepção de certo ou errado praticamente não existe… e pra enriquecer um pouco mais a discussão…

Embora conheça o “Projeto de Bando de Dados” (é como uma bíblia no meio acadêmico) eu não uso o brModelo, mas já que vcs falaram tão bem eu vou dar umas mexidas…

Acho que eu e o SDHPU somos os vovôs desse pessoal aqui… e nessas andanças observei algumas coisas:

a) Muitos desenvolvedores não têm conhecimento de modelagem (alguns sequer conhecem realmente o SGDBs que tem nas mãos) … alguns fazem alguma coisa, mas tudo muito empírico, sem conhecimento de causa, sem estudo… vê os outros fazendo e fazem e funciona… (pode não ser da melhor forma, mas funciona).

b) A quase totalidade dos desenvolvedores não documentam patavina de nada. Esse é um grande problema… muitos tem alguma dificuldade com relação a isso, porque não conseguem concatenar direito as idéias.

Entendo que a modelagem é uma decisão de projeto… cada projeto tem as suas particularidades. Como eu ando em vôo solo, toda modelagem minha estabelece um determinado padrão… o que nem sempre é bom.

Em uma equipe de desenvolvimento a figura do DBA acho que seja fundamental importância, porque a administração do DB é algo simplesmente fantástico.

Abraço a todos.

#15

Nunca pensei que este tópico tivesse respostas tão enriquecedoras.
Obrigado por compartilhar a experiência de vocês.

#16

PessoALL,

Tenho um amigo, analista de sistemas, que me disse uma coisa e eu coloco para reflexão de todos.

Certa feita ele me pediu que analizasse sua base de dados e sistema… depois da análise (superficial) eu apresentei pra ele as minhas considerações e ele me saiu com a seguinte máxima:

“Eu tenho certeza que faço duas coisas na vida (sistemas): a) Tudo ERRADO; b) Atendo bem o meu cliente. Então quando eu coloco as duas coisas na balança o bom atendimento ao cliente é MUITO mais importante do que fazer as coisas certas…”

Pensem nisso.

Vamo-que-vamo.

#17

Risos.

A tempos atrás eu fui comprar um celular xing ling no mercado livre, fui super bem atendido pelo vendedor, com retorno, maravilha, fiquei muito orgulhoso com o atendimento. O Celular não durou 1 semana.

Para mim bom atendimento é que que não precisamos atender, é aquele que o cliente não liga para reclamar, só para pedir novas funcionalidades, e depois que implantamos, o cliente não liga mais. Por que está satisfeito com o trabalho e com a qualidade do mesmo.

#18

SDHPU,

+1 ponto pra vc…
O interessante disso tudo é que boa parte dos clientes não sabe lhufas do que está por trás disso tudo… e não tá nem aí… contanto que ele tenha seus problemas resolvidos, está tudo bem.

Então a máxima do meu amigo é que está certa.

#19

Mas eu tenho um grande defeito MQEAJ,

Sou perfeccionista e sistemático.

Por isso geralmente aqui levamos muito mais tempo para realizar algumas coisas que podem até ser simples, pois sempre fazemos análise de impacto e a homologação é rígida, por outro lado, é raro o telefone tocar.

Não seria bom não precisar ligar para o suporte SM, ou não precisar enviar emails para bugs@netmake.com.br?

É claro que não existe perfeição, e no caso do produto Scriptcase, é algo por demais complexo, por isso antes de cada release: backup do banco de dados e da pasta de instação, testa nova release, deu problema, restaura a release anterior.

#20

É véio.

Eu também tenho o defeito da perfeição… Eu passo um ano pra entregar um SISTEMA (tenho um que já está com um ano e meio, daqui pra setembro eu completo ele), quem quiser queira… e não tem esse lance de: - deixa eu ficar testando pra ver como é…
E o pior de tudo é que existem uns zérruela que não dão a mínima pra isso.