Qual a melhor prática para modelagem de pessoa física e jurídica?

[Eduardo Alcântara 6]

Penso muito antes de iniciar um projeto de sistema, principalmente quanto à modelagem do banco de dados. Neste novo projeto, pretendo criar uma normalização que seja o conceito de todos os meus futuros projetos, até porque pretende fazer como que atuem como se fosse um único sistema, uma plataforma de aplicativos.

 

Dito isso, gostaria de dar as seguintes informações iniciais:

 

1. Haverá um cadastro de contatos;

2. Esses contatos poderão ser herdados de uma pessoa física ou jurídica;

3. Os contatos terão telefones, endereços físicos e e-mails à vontade;

4. Não serão permitidos cadastros repetidos de e-mail, telefone ou endereços;

 

Significa que escrevi as tabelas: emails, telefones, endereços.

 

Os cadastros das tabelas emails e telefones estarão ligadas aos contatos através de outras tabelas: telefones_dos_contatos e emails_dos_contatos, tendo basicamente as campos item_id e contato_id para unir os cadastros na hora de fazer uma query.

 

Minha dúvida está na hora de ligar estes dados aos contatos. As tabelas de contatos para pessoa física e jurídica serão alvo das duas outras tabelas paralelas, mas para identificar qual tabela (se física ou jurídica) está sendo apontada, terei de criar um terceiro campo tipo_pessoa, que pode complicar um pouco mais na frente.

 

Peço a opinião dos profissionais que já passaram por isso.

Devo manter esse esquema ou criar apenas uma tabela de pessoa para cadastrar tanto pessoas físicas como jurídicas? Se for dessa maneira, deverei usar cpf e cnpj separados ou apenas um campo (melhor para query)?

 

Grato,

Eduardo Alcântara

 

 

[Jorge Seiki Teruya 15]

Sim!

 

Utilize somente uma tabela para fazer o cadastro genérico dos dados.

 

Na aplicação você faz a divisão entre física e jurídica, fica mais fácil de fazer as consultas e otimizar também.

[Eduardo Alcântara 6]

Surgem então as questões:

 

1. Será que deveria criar um nome de campo que pudesse servir para CPF e CNPJ?
2. Colocar campos do tipo RG, Inscrição Estadual e Municipal, sabendo que alguns cadastros terão esses dados vazios?
3. Ou será que devo fazer uma sub-tabela apenas para esses registros e incluir logo coisas como CRM, CRO, CRC, OAB etc?

[Jorge Seiki Teruya 15]

Verifica até onde vai a sua aplicação.

 

Pois mesmo sendo boas práticas da normalização de dados fazer a separação de acordo com os dados que iremos armazenar, muitas vezes vale mais a pena ter campos vazios para economizar nos Joins dos select's depois.

 

E cada campo teria o seu próprio valor de cpf, cnpj, ie, rg..

 

E um campo booleano para identificar se é PF ou PJ

[Eduardo Alcântara 6]

Na verdade esse sistema será uma platafoma de aplicativos, onde o cadastro de pessoa será o básico e em cima dele haverão outras tabelas com dados dessas pessoas, de acordo com o que cada aplicativo precise. Mas todos irão acessar essa tabela básica.

create table if not exists plataforma.pessoa
(
  id int not null auto_increment primary key ,
  ut varchar(20) not null ,
  tp enum('PF','PJ') not null , -- tipo pessoa física ou jurídica
  nome varchar(99) not null , -- nome completo ou razão social 
  apelido varchar (99) null , -- apelido, nome artístico ou nome fantasia
  nasc date , -- data de nascimento da pessoa ou constituição da empresa
  nif varchar(15) not null , -- registro de cpf ou cnpj
  nie varchar(15) not null , -- registro de inscrição estadual
  nim varchar(15) not null , -- registro de inscrição municipal
  nrg varchar(15) not null , -- registro geral no caso de pessoa física
  dt date null , 
  ext text -- objeto de dados para extender informações da pessoa
)
engine = innodb;

 

Não quero fazer muitas alterações depois que ele estiver na codificação. Espero conseguir montar um padrão aceitável. Estou até resumindo os campos para não ficar muito exagerado nas queries, mas claro, com um dicionário de dados explicando tudo.

 

Obrigado pelas sugestões!

[Motta 645]

Como o sistema foi modelado ? UML ?

 

Como será o acesso ? Direto ou com uso de uma camada como hibernate ?

 

Lembre que modelagem física difere da lógica.

 

[Eduardo Alcântara 6]

Temos isso em mente Motta, na verdade a plataforma terá 3 interfaces possíveis dependendo da necessidade de cada aplicativo.

 

A interface principal será desenvolvida em Delphi, usando VCL e ZeosLib para interface com o banco de dados MySQL, além umas bibliotecas que eu fiz para facilitar a obtenção e gravação de dados. Também haverá a interface web para aplicativos que permitam acesso via tablets e smartphones, no caso de cadastros via web etc. Também tem pelo menos dois aplicativos para Android que usarão o banco de dados da plataforma.

 

Algumas tabelas terão um campo BLOB-TEXT para armazenar JSON ou XML com objetos de dados que irão complementar campos da tabela, isso é claro, somente nos casos de dados que não precisarão ser pesquisados via SELECT (usando where) e sim para elementos como configurações e coleções de multimídia por exemplo.

 

Só uso UML quando solicitado pelo cliente. Acho muito boring... Prefiro usar meus próprios princípios de modelagem, sem necessidade de curva de aprendizado para outros. ;-)

Decidi também que irei usar o campo direto na tabela de pessoas somente no caso do cpf e cnpj. Nos demais casos usarei uma outra tabela para colocar outros documentos como IE, RG, CRM etc.

É importante que o cadastro seja flexível, já que vários aplicativos irão utilizá-lo.