Inserir pelo delphi ou Stored?
Em um sistema ao fazer a parte de parcelas, o que seria melhor, usando stored procedure ou comandos delphi, um exemplo
var
x:integer;
begin
x:=0;
while x < parcelas do
begin
// comandos para inserir
inc( DataPagamento, 1);
valor := valor / parcela
// E outros comandos para manipular os dados e ir inserindo
end;
end;
ou seria melhor uma stored procedure
execute procedure Parcela ( codigo integer, Cliente varchar(50), etc etc
e na stored manipular a incrementacao da data de pagamento, e divisao dos valores e inserir
Pq no cadastro so sera colocado o valor total e o tanto de parcelas, entao posso dividir essas parcelas pelo delphi, e ir inserindo por um loop ou entao dividir na propria stored, qual é o mais recomendado e o mais rapido , e segura tbm.
Aproveitando ja faco outra pergunta, gostaria de saber se uma tabela com varios campos poderia atrapalhar em algo?, ou seja nesta mesma tabela ´parcelas´ seria conveniente salvar somente o codigo do cliente ou poderia tbm ja por o nome? quando digo muito campo me refiro a uma tabela com uns 30 campos (nao sei se 30 campos é muito.rsss), seria melhor so o campo codigo e quando precisar do nome do cliente chamar outra stored para procurar pelo codigo o cliente? ou para evitar isso ja salvo nome e codigo na tabela?
var
x:integer;
begin
x:=0;
while x < parcelas do
begin
// comandos para inserir
inc( DataPagamento, 1);
valor := valor / parcela
// E outros comandos para manipular os dados e ir inserindo
end;
end;
ou seria melhor uma stored procedure
execute procedure Parcela ( codigo integer, Cliente varchar(50), etc etc
e na stored manipular a incrementacao da data de pagamento, e divisao dos valores e inserir
Pq no cadastro so sera colocado o valor total e o tanto de parcelas, entao posso dividir essas parcelas pelo delphi, e ir inserindo por um loop ou entao dividir na propria stored, qual é o mais recomendado e o mais rapido , e segura tbm.
Aproveitando ja faco outra pergunta, gostaria de saber se uma tabela com varios campos poderia atrapalhar em algo?, ou seja nesta mesma tabela ´parcelas´ seria conveniente salvar somente o codigo do cliente ou poderia tbm ja por o nome? quando digo muito campo me refiro a uma tabela com uns 30 campos (nao sei se 30 campos é muito.rsss), seria melhor so o campo codigo e quando precisar do nome do cliente chamar outra stored para procurar pelo codigo o cliente? ou para evitar isso ja salvo nome e codigo na tabela?
Renato_sp
Curtidas 0
Respostas
Afarias
23/09/2004
|qual é o mais recomendado e o mais rapido , e segura tbm.
Não existe assim um ´mais recomendado´ ... eu particularmente dou preferência ao uso de procedimentos do banco (SP) -- sobe a ótica dos SGBDs esta é a solucão!
Mas... sobe as óticas do paradigma OO e/ou tb da programação em 3-camadas as regras devem ficar nos objetos (na aplicação) -- mas, seja rasoável e veja o q é melhor aplicável ao seu caso.
|gostaria de saber se uma tabela com varios campos poderia atrapalhar
|em algo?,
Não. mas evite ´select * from´ quando não precisar de todos os campos.
|ou seja nesta mesma tabela ´parcelas´ seria conveniente salvar
|somente o codigo do cliente ou poderia tbm ja por o nome?
o q for melhor para vc (sua aplicação). Sobe a ótica relacional, vc não deveria fazer isso (por o nome duplicado em outra tabela), mas -- em tudo temos q ser rasoáveis.
|quando digo muito campo me refiro a uma tabela com uns 30 campos
|(nao sei se 30 campos é muito.rsss),
para quem programa é :D mas para o SGBD não.
|seria melhor so o campo codigo e quando precisar do nome do cliente
|chamar outra stored para procurar pelo codigo o cliente?
Um JOIN resolve isso.
|ou para evitar isso ja salvo nome e codigo na tabela?
não precisa evitar um JOIN *em geral* -- procure ´duplicar informação´ APENAS quando se deparar com uma situação q realmente peça isso -- o q não me parece o caso.
T+
Não existe assim um ´mais recomendado´ ... eu particularmente dou preferência ao uso de procedimentos do banco (SP) -- sobe a ótica dos SGBDs esta é a solucão!
Mas... sobe as óticas do paradigma OO e/ou tb da programação em 3-camadas as regras devem ficar nos objetos (na aplicação) -- mas, seja rasoável e veja o q é melhor aplicável ao seu caso.
|gostaria de saber se uma tabela com varios campos poderia atrapalhar
|em algo?,
Não. mas evite ´select * from´ quando não precisar de todos os campos.
|ou seja nesta mesma tabela ´parcelas´ seria conveniente salvar
|somente o codigo do cliente ou poderia tbm ja por o nome?
o q for melhor para vc (sua aplicação). Sobe a ótica relacional, vc não deveria fazer isso (por o nome duplicado em outra tabela), mas -- em tudo temos q ser rasoáveis.
|quando digo muito campo me refiro a uma tabela com uns 30 campos
|(nao sei se 30 campos é muito.rsss),
para quem programa é :D mas para o SGBD não.
|seria melhor so o campo codigo e quando precisar do nome do cliente
|chamar outra stored para procurar pelo codigo o cliente?
Um JOIN resolve isso.
|ou para evitar isso ja salvo nome e codigo na tabela?
não precisa evitar um JOIN *em geral* -- procure ´duplicar informação´ APENAS quando se deparar com uma situação q realmente peça isso -- o q não me parece o caso.
T+
GOSTEI 0