Fórum Select com where vem tudo? #45186

Vai trazer todos os campos(*) do(s) registro(s) em que o codigo seja igual à 1! :wink:

Entao a utilização da stored procedure em alguns casos seria apenas para organizar o banco de dados? ( Em alguns casos ), como esse por exemplo, seria bem mais facil utilizar

no cliente

select * from cliente
where codigo = 1

do que ter que criar a stored procedure para chamar ela...

CREATE PROCEDURE CHAMAR_CLIENTE (COD INTEGER)
RETURNS (CODIGO INTEGER,
NOME VARCHAR(40),
CIDADE VARCHAR(20),
ESTADO CHAR(2))
AS
begin
FOR SELECT CODIGO, NOME, CIDADE, ESTADO FROM CLIENTE
WHERE CODIGO = :cod INTO
:CODIGO, :NOME, :CIDADE, :ESTADO DO
suspend;
end

SELECT * FROM CHAMAR_CLIENTE (1)

Seria isso? neste caso a utilizacao dela nao teria nenhum outro beneficio a nao ser organizar o banco de dados?
E tipo por exemplo criei uma UDF que pega o primeiro nome ou seja, utilizaria assim

select * from Cliente
where nome = FUNCAO_UDF(nome)

se o nome que o cara colocar for JOAO DA SILVA , a function so vai pegar como JOAO, neste caso nao seria bem mais trabalhoso criar a udf e tal, do que utilizar recursos do delphi como chamar pelo cliente

select * from cliente
where nome = Copy(Nome, 1, pos(´ ´, nome)

Nao seria mais conveniente fazer isso e nao ter que fazer uma UDF, registrar ela e tal, ja que teoriacamente nao vai trazer beneficio a nao ser organizar o projeto, desculpe se entendi errado mas quero aprender como funciona isso em stored, cliente/servidor, os beneficios, estou fazendo um projeto e tudo esta sendo pelo servidor, mas conversando com amigos que mexe tao fazendo quase tudo pelo cliente, ai fiquei na duvida se estou trabalhando a toa... valeu....

Renato / SP

Trabalhar com Stored Procedures é bom UDF´s talvez tambem, mas não encare isto como uma regra.
Por exemplo esta Stored Procedure que você mostrou só server para organizar mesmo, nada além disso.
A sua UDF é interessante, mas não acho bom fazer assim! Você poderia modelar melhor o bando(se fosse o caso, criar 2 campos distintos para nome e sobrenome) ou simplesmente tratar isto no cliente. UDF´s exigem muito do Servidor! Elas atrasam o processamento, logo uma select sobre uma UDF que trata os registros, poderia demorar muito mais do que uma select que trata os registros no cliente.
E a menos que você fosse acessar esta base com ´multiplos sistemas clientes diferentes´, fazer todas esta programação no banco não é muito util.
Deixe para criar stored procedures mais específicas, que sirvam para tratar dados no servidor, como atualização de dados entre tabelas, etc e prefira sempre outras alternativas antes de correr e utilizar UDF´s...

|UDF´s exigem muito do Servidor! Elas atrasam o processamento, logo
|uma select sobre uma UDF que trata os registros, poderia demorar
|muito mais do que uma select que trata os registros no cliente.

UDFs são realmente o último caso em termos de processamento no servidor, mas ainda assim em muitos casos são melhores q fazer o processamento no cliente! E q casos são esses?? Principalmente os casos q envolvem grandes quantidades de registros!

Ainda sai mais ´barato´ processá-los todos no servidor (com UDF) que trazê-los todos pela rede (quanto menor a banda da rede, mais real é este problema)



T+

Concordo!
É claro que depende do caso, mas para o exemplo citado, por exemplo, não vejo a serventia da udf... :roll:

Valeu mesmo por terem me ajudado, os exemplos citados de udf etc foi apenas um exemplo, embora foi muito bom esse post para entender o porque e quando usar o servidor.

Porque pensava eu que somente as stored trazia o que vc quizesse e o select com where no cliente traria tudo e o cliente selecionava o que queria, nao sei de onde tirei isso..rsss :oops:
Entao na hora eu fiquei com muitas duvidas de quando é melhor utilizar a stored, e a udf, ou simplemente fazer pelo cliente !!!

Valeu :lol:

Esse negócio de SELECTs trazerem tudo e o cliente selecionar localmente é típico de banco de dados locais (Paradox).

Creio que tudo depende de análise caso a caso.

Se a stored procedure se compõe de apenas uma simples consulta, não faz diferença de uma query feita no cliente: Ambas serão processadas no banco e os registros selecionados serão enviados para o cliente pela rede. Não há ganho em nenhum caso.

Agora, se você precisa de uma ou mais instruções (por exemplo, vários updates, inserts, selects, etc) que trocam dados entre si, aí sim a stored será de grande valia pois tudo será feito internamente pelo banco, sem envio de dados pelo cliente.