[firebase-br] Ref. Inserir registro na tabela filha

Sandro Souza escovadordebits em gmail.com
Qua Maio 6 15:06:11 -03 2009


Bom dia/tarde Omar.

Grande Omar, existem várias formas de se tomar Neston. :D

Necessariamente, você vai ter que criar uma chave estrangeira da tabela de
carros para a tabela de equipes pelo campo ID_EQUIPE.

Quanto à chave primária da tabela de carros, temos duas opções com seus prós
e contras:

1 - Criar uma chave primária simples, contendo apenas o campo
"ID_SEQUENCIAL_CARRO".

1.1 - Pró.

Gastaria menos espaço interno para armazenar os dados do índice criado pela
chave primária, pois trata-se apenas de um único campo.

1.2 - Contra.

Não permite reutilizar o mesmo valor (sequencial) para outra equipe, pois
como é uma chave primária, não pode repetir seus valores.

2 - Criar uma chave composta, contendo tanto o campo ID_EQUIPE quanto o
campo ID_SEQUENCIAL_CARRO (porque não apenas ID_CARRO?).

2.1 - Pró.

Permite que você possa reutilizar os mesmos sequenciais de carro para
equipes diferentes, por exemplo:
Equipe 1, carro 1.
Equipe 1, carro 2.
Equipe 2, carro 1.
Equipe 2, carro 2.

2.2 - Contra.

Gasta mais espaço interno para o armazenamento dos dados do índice da chave
primária, pois trata-se de mais de um campo.

Pelo que você citou em seu email, imagino que o melhor caso seja a chave
composta, pois assim você pode repetir o código/sequencial do carro para
outras equipes.

Aproveitando a oportunidade, vamos pensando em um caso de várias tabelas,
por exemplo, 26 tabelas (da tabela TAB_A até a tabela TAB_Z).

Vamos imaginar que a tabela TAB_A seja a principal/mestra, a tabela TAB_B
seja detalhe de TAB_A, a tabela TAB_C seja detalhe de TAB_B, e assim por
diante até o último nível (a tabela TAB_Z seja detalhe de TAB_Y).

Como seria melhor estruturar suas respectivas chaves primárias, pois
tratam-se de 25 dependências (1 mestra e 25 detalhes)?

Vamos supor que cada uma dessas 26 tabelas tenha um campo de código chamado
"CODIGO", e no caso das 25 tabelas detalhes, um campo de código "mestre"
chamado apenas de "MESTRE".

Fora as questões relativas ao gasto interno de espaço para armazenar os
dados dos respectivos índices (itens 1.1 e 2.2), vamos pensar no esforço
envolvido nas consultas que as aplicações devem fazer.

Se criarmos apenas chaves primárias simples, seriamos forçados a fazer JOINs
de todas as tabelas envolvidas nos N níveis de relacionamento.

Por exemplo, se desejamos obter uma informação da tabela TAB_A e outra
informação da tabela TAB_B, utilizaríamos um código parecido com o seguinte:

SELECT
  A.CAMPOA,
  B.CAMPOB
FROM
  TAB_A A,
  TAB_B B
WHERE
  B.MESTRE = A.CODIGO

Agora necessitamos de uma informação de TAB_A e outra de TAB_C:

SELECT
  A.CAMPOA,
  C.CAMPOC
FROM
  TAB_A A,
  TAB_B B,
  TAB_C C
WHERE
  (B.MESTRE = A.CODIGO)AND
  (C.MESTRE = B.CODIGO)

Já notaram que fomos forçados a fazer JOIN com a tabela TAB_B por causa dos
relacionamentos simples?

E que tal fazer de TAB_A até TAB_Z? :D

SELECT
  A.CAMPOA,
  Z.CAMPOZ
FROM
  TAB_A A,
  TAB_B B,
  TAB_C C,
  ...
  TAB_Z Z
WHERE
  (B.MESTRE = A.CODIGO)AND
  (C.MESTRE = B.CODIGO)AND
  ...
  (Z.MESTRE = Y.CODIGO)

Já pensaram no trabalho que o banco de dados vai ter para obter essas
informações?

Mesmo com as respectivas chaves primárias e chaves estrangeiras, tratam-se
de vários JOINs para se obter alguma informação dos extremos.

Agora, se criarmos o outro cenário, ou seja, chaves primárias compostas.

Vamos imaginar que a TAB_A teria o campo chave CODIGOA, a TAB_B teria os
campos chaves CODIGOA e CODIGOB, e assim por diante, até a TAB_Z que teria
26 campos chaves (de CODIGOA até CODIGOZ).

Com certeza, vai gastar mais espaço interno para armazenar os dados dos
índices das chaves primárias e estrangeiras, mas vamos reproduzir os mesmos
exemplos de pesquisa que fizemos no cenário anterior:

Uma informação da TAB_A e outra da TAB_B:

SELECT
  A.CAMPOA,
  B.CAMPOB
FROM
  TAB_A A,
  TAB_B B
WHERE
  B.CODIGOA = A.CODIGOA

Praticamente não houve qualquer mudança, a não ser os nomes dos campos
chaves.

Uma informação da TAB_A e outra da TAB_C:

SELECT
  A.CAMPOA,
  C.CAMPOC
FROM
  TAB_A A,
  TAB_C C
WHERE
  C.CODIGOA = A.CODIGOA

Agora sim vemos alguma mudança. Como a chave primária de TAB_C também contém
o CODIGOA, fica muito mais simples e já economizou um JOIN, e portanto,
teremos as informações desejadas acessando menos tabelas.

Uma informação da TAB_A e outra da TAB_Z:

SELECT
  A.CAMPOA,
  Z.CAMPOZ
FROM
  TAB_A A,
  TAB_Z Z
WHERE
  Z.CODIGOA = A.CODIGOA

Bom, compare esse último SELECT com o equivalente do cenário anterior.

Com isso, podemos perceber as situações em que seria melhor criar chaves
primárias simples ou compostas.

Você necessita acessar informações de tabelas diferentes, que estão
relacionadas entre si, e isso ocorre várias vezes e/ou a performance da
consulta não é satisfatória? Use chaves compostas, caso contrário, use
chaves simples.

Gostaria que vocês comentassem sobre esse assunto. Críticas e sugestões são
bem vindas.

Espero ter ajudado mais que atrapalhado. :D

2009/5/6 Omar Haddad <omarhaddadm em gmail.com>

> Boa tarde, amigos(as)....
>
> Gostaria, se possível, de uma orientação sobre a criação da chave primária
> de uma tabela-filha.
>
> Tabela Mestre: EQUIPE
>
> Tabela Filha: Carros
>
>
> Cada equipe pode ter um ou mais carros, ou seja, para um id da tabela
> equipe, tenho vários carros.
>
> Como faria para gerar a chave da tabela-filha, já que ela teria de ser
> composta por ID_EQUIPE, ID_SEQUENCIAL_CARRO, sendo que podem haver vários
> usuários lançando carros ao mesmo tempo e ele teria de pegar sempre o
> último
> registro  de ID_SEQUENCIAL_CARRO para o ID_EQUIPE mostrado ?
>
> Por favor, como poderia ser mais funcional, ter um PLAN rápido, consistente
> e satisfatório, independente da demanda ??
>
> Att.
>
> Omar Marques Haddad
> Analista de Sistemas Sênior
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



Mais detalhes sobre a lista de discussão lista