[firebase-br] SQL Elegante

Sex Jul 21 12:19:44 -03 2006

Só reforçando um pouco fran :)

Não é só questao de ser mais claro ou não é que "Apelidos" deixam a string 
menor e menos instafante ao meu ver

Sei que COD_CLIENTE seria muito mais claro que COD_CLI

Mas por exemplo, eu programa em PHP e ASP também e fica muito ruim escrever 
uma string de Select quando temos nomes de campos enormes

Ainda em PHP podemos quebrar a linha

Ex.
 $Sql = "SELECT
    COD_CLIENTE,
    NOME
 FROM TABELA";

Agora em ASP ja fica uma caca pois ele não permite quebra de linha sem aviso

Ex.

Sql = "SELECT COD_CLIENTE, NOME"

Se eu quebrar ou escrevo Sql = Sql+"" ou Sql = "" &_  <- quebra

Desta forma uma padronização deve se levar em conta com qual linguagem vc 
vai trabalhar também

Mas como uso o FB em ASP e Delphi então acho melhor o uso do bom senso

Mas valeu o tópico :)

----------------------
Marcelo Silva
(11) 9693-4251
(11) 6723-3106 - LESTCRED
MSN: marcvan em ig.com.br

----- 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

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.1/390 - Release Date: 17/07/2006