[firebase-br] SQL Elegante

[Renan de Oliveira]

Caro Francisco,

Vamos supor o seguinte exemplo, de 2 tabelas
-nota_fiscal_entrada
 numero_nota_fiscal
 serie
 codigo_emiente

-item_nf_entrada
 numero_nota_fiscal
 serie
 codigo_emiente

nesse exemplo, as 2 tabelas tem essas chaves compostas, sendo uma pai e
outra filha.
nao entendo a utilidade de utilizar um id, pois caso fosse colocar um id
como chave da tabela nota_fiscal_entrada, facilitaria a ligacao entre as 2
tabelas, sem duvida alguma, porem, nao poderia usar como unique , no campo
numero_nota_fiscal, serie e codigo_emitente da tabela nota_fiscal_entrada,
pois pode haver a mesma nota, com a mesma serie, porem de um emitente
diferente. E outra coisa seria o seguinte, em diversos relatório onde apenas
a tabela item_nf_entrada é consultado, teria que fazer a ligação hoje
desnecessaria, da tabela pai, para obter os dados da nota.
gostaria que você me justificasse as vantagens, de acordo com o seu ponto de
vista que eu obteria atravez do uso de id, e de campos unique, conforme voce
citou no 1 email sobre "SQL Elegante"

obrigado.


Renan de Oliveira
Safetech Informática
(51) 3529-3870
----- Original Message ----- 
From: "francisco gamarra" <francisco.gamarra em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, July 21, 2006 10:51 AM
Subject: Re: [firebase-br] SQL Elegante


PUXA!!!
Estou Abrindo meu e-mail e vi q o negócio deu o q falar.

Bom, é claro q eu esperava q desse repercusão, mas não tanto.

Bem, vou fzr alguns comentários sobre os comentários:

Sobre o 1º Comentário do Magnun Oliveira:

- Sua inesperiência é evidente, vc acabou de falar,
  com todo respeito, uma das maiores besteiras da
  história da informática. Todos sabem q "gosto" não
  se aplica a área de de desenvolvimento, seja ela
  de soft ou bancos;

- Padronização é uma coisa q todos buscam, é claro q
  existem diferentes opniões sobre quais são as melhores;

- Com relação às 3 letras estas são realmente nescessárias
  pelo fato de que em aplicações podem haver centenas tipos
  de objetos, e nesses casos muitos podem estar apontando
  para um item comum. Ex. edt_nome, mem_nome, cmp_nome, etc.

- Vc disse q até agora não teve problemas, o q demostra q
  vc trabalha sozinho, ou seja, não faz parte de uma equipe e,
  portanto está fora do mercado de desenvolvimento. Provavelmente
  é um desenvolvedor solo. Vou me lembrar do seu nome qdo estiver
  selecionando currículos.


Sobre o Comentário do Bruno Ribeiro:

- Meus parabés!!! vc tem futuro! Consegue-se identificar alguém
  q tem uma alma profissional pelas suas sábias palavras.
  Vou me lembrar do seu nome qdo estiver selecionando currículos.


Sobre o 2º Comentário do Magnun Oliveira:

- A performace não cai utilizando o where, o q ocorre é q o banco
  antes de executar a consulta tem um pouco + de dificuldade para
  converter o where em join. Postei desta forma pois percebi q
  na lista nem todos dominam sql;


Sobre o Comentário do Renan de Oliveira:

- Caro Renan, compreendo seu ponto de vista, já tive ele tb há alguns
  anos atrás. Com relação ao campo id ser vago, de uma certa forma eu
  concordo com vc, mas nem por iço posso criar uma maneira diferente
  de trabalhar do que aquela q o mercado exije. Partircularmente, após
  conhecer a estrutura sql mais profundamente, comecei utilizando a
  mesma sistemática porém com o nome "cod" q acho q seja tb + elegante
  e + claro. Mas a padronização de grandes empresas exigem q nos adequemos
  a elas e, com certeza, qdo os "bancos de dados orientados a objetos"
  dominarem o mercado vc vai compreender melhor do q estou falado;

- com relação a chaves compostas, realmente não farei comentários sobre
  isso. tenho certeza q qdo vc estudar + vai chegar a essa conclusão
sozinho,
  ou, pode pular esta parte e conversar + na lista a respeito deste assunto.



Sobre o Comentário do Thiago:

- Seu conhecimento é evidente. Meus parabéns!!!


Sobre o 1° Comentário do Marcelo Silva:

- vc realmente acha q "COD_CLI" é + claro q "CLIENTE" ???;
- Para ver as tabelas q estão sendo utilizadas em um SQL basta ir até a
cláusula "from";
- Padrões sempre existem, acredite!!!


Sobre o Comentário do Francisco Thiago:

- Sobre o primeiro paragrafo : concordo, exceto o fato de "não importa
plural ou não";
- Sobre o segundo paragrafo : discordo, o campo "cod" da table "caixa" pode
ser acessado por
  "caixa.cod", é + legível além de aproximar o modo como a linguagem sql é
escrita das
  linguagens de acesso a este;
- Sobre o terceiro, quarto e quinto paragrafo : concordo;
- Sobre o sexto paragrafo : concordo, mas não em todos os casos;
- Sobre o sétimo paragrafo : discordo, acho desnecessário;


Sobre o 2° Comentário do Marcelo Silva:
- Dois problemas em usar chave string: O primeiro vc já citou, o segundo é a
despadronização;


Sobre o Comentário do Luis Carlos Quinhone:
- Acho desnecessário o uso do "tb" antes dos nomes das tables;
- Acho desnecessário o uso do identificador de tables antes do campo
("cli_");


Sobre o Comentário do Otto Fuchshuber:
- Concordo plenamente. è claro q ng é obrigado a seguir nada, exceto se
estiver
  em uma empresa q exija isso. Mas é claro q o caminho da padronização
  conduz a um melhor desenvolvimento e compreensão qdo se fala a respeito de
equipe.
  Sucesso!!!


Sobre o Comentário do Fábio:
- 1° Item : Concordo;
- 2° Item : Concordo;
- 3° Item : discordo plenamente! "não tem utilidade prática"???, analise
isto em um conceito referencial;
- 4° Item : Concordo em parte. "CodigoCliente" pra mim não reflete tão bem
como "cliente.cod";
- 5° Item : discordo, na minha primeira postagem vc vai entender porque;


Sobre o Comentário de João Luiz:
- Compensa! E muito! vc não está trocando o problema de lugar, de forma
nenhuma!
  vc está dividindo o problema, o que faz com q em uma consulta vc só
precise fazer
  metade das comparações;
- com relação ao uso de índices, não se preocupe com iço, apesar de muitos
não concordarem!
  Imagine vc utilizando campos compostos para fazer operações lógicas e
aritiméticas, comparações,
  joins e etc, vc teria problemas de performace. Aposto q suas consultas na
grande maioria
  utiliza joins, não é verdade? então, não seria mt + inteligente agilizar
esta consulta através de padrões?
  pense nisso!
- Sim, o campo "id" pode ser parente do "controle", mas iço pq é necessário
mesmo, e
  realmente é melhor. Imagine uma table cliente ond a key é o nome do
cliete. imagine agora
  uma referencia a esta tabela. agora imagine uma consulta onde vc não qr
fzr filtro algum
  q envolva o nome do cliente mas vc qr fzr referencia a ele. iço é um
desastre na performace.


 Bom, Espero q tenha sido construtivo para todos.
  Um Grande Abraço e até +
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa