Duas tabelas ou uma tabela?

Question

uma pergunta rápida em relação ao design da tabela ..

Vamos dizer que estou projetando um banco de dados de pedido de empréstimo. Como é agora, vou ter 2 mesas ..

Requerente (ApplicantID, nome, sobrenome, CPF, e-mail ...) e

Co-Requerente (CoApplicantID, nome, sobrenome, CPF, e-mail .., ApplicantID)

Devo considerar ter apenas uma mesa, porque todos os campos são os mesmos .. ??

Person (PersonID, nome, sobrenome, CPF, e-mail ..., ParentID (Isto determina se é uma co-requerente))

Quais são os prós e contras dessas duas abordagens?

Answer 1

Eu sugiro o seguinte modelo de dados:

PERSON tabela

• PERSON_ID, pk

LOAN_APPLICATIONS tabela

• APPLICATION_ID, pk

APPLICANT_TYPE_CODE tabela

• APPLICANT_TYPE_CODE, pk
• APPLICANT_TYPE_CODE_DESCRIPTION

LOAN_APPLICANTS tabela

• APPLICATION_ID, pk, fk
• PERSON_ID, pk, fk
• APPLICANT_TYPE_CODE, fk

Pessoa (PersonID, nome, sobrenome, CPF, e-mail ..., ParentID (Isto determina se é uma co-requerente))

Isso funciona se a pessoa só vai nunca existir em seu sistema como quer um candidato ou de um co-requerente. Uma pessoa poderia ser um co-candidato a numerosos empréstimos e / ou um si requerente -. Você não quer ser re-introduzir os detalhes de cada vez

Este é o benefício de como e por que as coisas são normalizados. Com base nas regras de negócios e realidade inerente de uso, as mesas são configurados para que os dados parada redundantes sendo armazenado. Isto é para os seguintes motivos:

1. dados redundantes é um desperdício de espaço e recursos para apoiar e manter
2. A ação de duplicar os meios de dados também pode ser diferente em formas sutis - capitalizações, espaços, etc, que podem levar a complicações para isolar dados reais
3. Os dados armazenados incorretamente devido a supervisão ao criar o modelo de dados
4. Foresight e Flexibilidade. Atualmente não há qualquer opção diferente de candidato ou co-requerente de um valor APPLICANT_TYPE_CODE - que poderia ser um armazenados sem o uso de outra mesa e chave estrangeira. Mas essa configuração permite que o suporte para adicionar códigos diferentes candidatos no futuro, se necessário -., Sem qualquer dano para o modelo de dados

Não há nenhum benefício de desempenho quando você corre o risco dados errados. O que você faria, será comido pelos hacks você tem que executar para fazer as coisas para o trabalho.

Answer 2

Se o modelo de domínio determina que ambos os povos são candidatos e que estão relacionados, em seguida, eles pertencem à mesma tabela com uma chave foriegn auto-referencial.

Answer 3

Você pode querer ler sobre normalização de dados .

Eu acho que você deve ter duas tabelas, mas não aqueles dois. Ter uma tabela de "empréstimos" que tem chaves estrangeiras a uma tabela de candidatos, ou simplesmente ter registros em candidatos referência a mesma tabela.

Answer 4

As vantagens : - torna a pesquisa mais fácil: Se você tiver apenas um número de telefone ou um nome, você ainda pode procurar, em uma única tabela e encontrar a pessoa que corresponde independentemente de ele / ela ser um co-requerente ou um main-candidato. Caso contrário, você precisa usar uma construção UNION. (No entanto, quando você sabe que você procurar um determinado tipo de candidato, você adicionar um filtro do tipo e você só tem esses candidatos. - Geralmente mais fácil de manter. Say amanhã você precisa adicionar o ID de tweeter do requerente ;-), apenas um lugar para a mudança. - Também permite inputing pessoas com dizer um "/ open indefinido" tipo, e atribuir depois como requerente ou de outro, em uma data posterior. - Permite a introdução de novos tipos de candidatos (dizem que um fiador co-latteral ... o que for) ...

As desvantagens :

• com realmente enormes (registros de vários milhões de pessoas), há poderia ser um ganho de desempenho ligeiro com uma abordagem de duas tabelas (dependendo do índice e várias outras coisas
• consultas SQL podem ser pouco mais complicado, por exemplo, com dois separados junta-se à mesa de pessoa, uma para o candidato outra para o co-requerente. (Nada intratável, mas um pouco mais complexidade.

No conjunto, o design adequado é na maior probabilidade a um com uma única tabela . Só é possível excepção se ao longo do tempo a informação mantido para um tipo de recorrente estava a começar a divergir significativamente a partir de (s) outro tipo de recorrente. (E mesmo assim nós podemos lidar com esta situação de diferentes maneiras, incluindo a introdução de uma tabela relacionada para esses campos extras, como ele pode fazer mais sentido; Sim, um sistema de dois mesa novamente, mas onde os campos extras podem encaixar " naturalmente" em conjunto em termos de sua semântica, uso etc ...)

Answer 5

Ambos suas variantes têm uma desvantagem: qualquer pessoa pode ser um candidato e co-requerente duas vezes e muito mais. Portanto, você deve usar a tabela Pessoa (PersonID, nome, sobrenome, CPF, e-mail ...) e mesa Co-candidatos (PersonID como Requerente, PersonID como CoApplicant)

Answer 6

Que tal uma vez que cada candidato pode ter um co-candidato - basta ir com uma tabela no total. Então você teria Applicants, que tem um campo 'coapplicant' opcional de chave estrangeira (ou similar).

Answer 7

Se os campos entre o requerente e co-recorrente são idênticos, então eu sugiro que você colocá-los na mesma mesa e usar um campo "tipo de candidato" para indicar candidato principal ou co-. Se há alguns especial informações sobre o co-requerente (como relação com o requerente principal, números de telefone extras, outras coisas) que você pode querer normalizar a uma mesa separada e referem-se a partir daí de volta para o co-requerente (pelo (co-) ID candidato) na tabela requerente.

Answer 8

Mantenha o vidro Two> 1º Tipo de Usuário ID de código Nesta tabela u pode manter tipo de usuário ou seja applicat E Co requerente 2 tabela de usuário -> aqui u pode manter todo o campo com coloums semelhantes com código de tipo de usuário como chave foregin. Por isso, você pode facilmente distingush entre dois usuário.

Answer 9

Eu sei - eu sou muito tarde neste .... O pedido de empréstimo é a sua entidade principal. Você vai ter um ou mais candidatos para o empréstimo. Abandonar a idéia de Pessoa - você está criando algo que você não pode controlar. Eu estive lá, feito isso e tenho a t-shirt.