É bem simples, quando vc "confia" na conevrsão implícita e
automatica, vc corre dois riscos :
1. a conversão TANTO pode ocorrer à esquerda ou à direita dum
operador de comparação, por exemplo imagine o código abaixo :
... WHERE colunanumérica = '45' ...
nesse caso o bd Oracle TANTO pode escolher converter a string '45'
para o número 45 e fazer a comparação com a coluna numérica ** OU **
pode optar por converter a coluna numérica para string,e aí comparar
string com string. O risco é que SE o banco optar por converter a
coluna numérica para string E haver um índice nela, obviamente o
índice contém NÚMEROS e não strings, pode não ser usado...
2. conversão implícita necessariamente ** UTILIZA ** as variáveis
de ambiente do cliente conectado no banco, que TRANQUILAMENTE podem
estar diferentes das do banco e/ou do assumido no programa. Imagine
que vc conecta no banco com um cliente configurado para datas no
formato DD/MM/YYYY e executa um SQL tipo :
... WHERE colunadate = '15/01/2007' ...
a query funcionará OK, mas se esse MESMO programa enviar esse MESMO
SQL a partir duma máquina-cliente setada com OUTRO formato default de
data (digamos, 'MM/DD/YYYY') o banco vai "achar" que '15' é o mês,
vai dar ERRO..... Programa que confia em defaults de ambiente CEDO ou
TARDE acaba "estourando", é uma prática COMUM e RECOMENDADA de
programação defensiva de escrever algo como :
... WHERE colunadate = to_date('15/01/2007', 'dd/mm/yyyy') ...
aí esse código NÃO falha seja qual for o default da sessão-cliente.
==>> essas questões NÂO foram inventadas por mim, no manual de SQL
Reference a Oracle o diz com todas as letras :
"Data Conversion
Generally an expression cannot contain values of different datatypes.
For example, an expression cannot multiply 5 by 10 and then
add 'JAMES'. However, Oracle supports both implicit and explicit
conversion of values from one datatype to another.
Implicit and Explicit Data Conversion
Oracle recommends that you specify explicit conversions, rather than
rely on implicit or automatic conversions, for these reasons:
SQL statements are easier to understand when you use explicit
datatype conversion functions.
Implicit datatype conversion can have a negative impact on
performance, especially if the datatype of a column value is
converted to that of a constant rather than the other way around.
Implicit conversion depends on the context in which it occurs and
may not work the same way in every case. For example, implicit
conversion from a datetime value to a VARCHAR2 value may return an
unexpected year depending on the value of the NLS_DATE_FORMAT
parameter.
Algorithms for implicit conversion are subject to change across
software releases and among Oracle products. Behavior of explicit
conversions is more predictable.
"
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Myria Salvino <[EMAIL PROTECTED]>
escreveu
>
> Ola Amigos
>
> Por favor que puder ajudar :
>
> Por que usar conversao implicita em pl/sql 'e uma pratica ruim
de programacao??
>
> Obrigada
>
> My
>
> Flickr agora em português. Você clica, todo mundo vê. Saiba
mais.
>
> [As partes desta mensagem que não continham texto foram removidas]
>
