REGRAS DE NEGOCIO BANCO DE DADOS

Prezados,

Ainda inexperiente no SC e oriundo do Delphi, fiz algumas perguntas e tenho tido um excelente retorno dos colegas deste Fórum.
Entretanto peço a voce mais uma opinião. Eu tenho vários sistemas desenvolvidos em Delphi dos quais todos foram desenvolvidos no Firebird.
Neste anos de desenvolvimento, sempre coloquei determinadas regras de negócios e algumas funções dentro das Trigguers e Stored Procedures do FB.
Minha pergunta é: Vale a pena deixar as que já existem no Banco ou migrar para o Firebird?
E nos novos projetos, devo deixar as regras dentro do Banco ou já faço no FB?

Um grande abraço.

Cezar,

Minha opinião: deixe as regras no banco.

E nos novos projetos, devo deixar as regras dentro do Banco ou já faço no FB? Não seria a mesma coisa Banco e FB?
A pergunta não seria deixar no Próprio SC nos eventos ou no Banco do FB?
Eu no MySQL só uso Stored Procedures se vejo que tem alguma rotina, que vai ganhar velocidade extrema fazendo isso muitos registros,
caso contrário faço as regras nos eventos do SC mesmo, fica mais fácil para dar manutenção depois e seguir a lógica ‘regras do negócio’, porque
tem cliente que mesmo te passando as ‘regras do negócio’, daqui 3 anos vai te perguntar como funciona aquele ‘lançamento ali’ eheheh

Mas já vi um sistema que usava Firebird 2.01 que o sistema praticamente foi feito dentro do Firebird ai vivia corrompendo, era em Delphi sem ser essa versão nova.

Ai mudaram ano passado para C# usando Firebird 2.5 agora e as regras ficam em C# não mais no banco, ai tá rodando que é uma beleza, isso em rede local windows.

Pois é amigos…

Eu ainda não tenho uma opinião em relação ao SC.
Trabalhei 13 anos na área de teste de sistemas, mas com DB2 e Oracle. Optei pelo FB, pois a sintaxe dos comandos são idênticas ao do Oracle…
Ambos têm razão.
Eu gosto das regras no Banco pois, em uma eventual migração de ferramenta (PHP para C##) mudo muito pouco. O rendimento é melhor também em tabelas de grande volumes. O que não é meu caso.

Vamos convocar o pessoal para se manisfestar. rsrsrs
Obrigado a ambos. Obrigado mesmo!

Eu costumo deixar a regra de negócio na aplicação, e que nem o colega acima disse, utilizar procedure em rotinas muito pesadas para rodar direto no banco.
O por que de deixar na aplicação?
Como o scriptcase da a liberdade de utilizar várias distribuições de bancos, não deixamos engessada a aplicação.

Eu usei por muito tempo 90% das regras no banco de dados.
Mas hoje estou modificando meus sistemas e criando uma camada (webservice com classes php) só para as regras e deixando o banco de dados mais leve.

Prezado Haroldo.

Penso que o SC possa dar esta "liberdade"e confiabilidade para que as "regras’ fiquem nas camadas, conforme mencionou, Haroldo. Como eu havia comentado anteriormente, tenho que mudar minhas estratégias e “vícios” oriundas de um Delphi, para que possa ter esta clareza no SC.

Todas as manifestações foram e estão sendo extremamente positivas.

Muito obrigado a todos.

Rotinas pesadas é bom deixar no banco.
Até mesmo para alguns cálculos monetários é bom deixar o banco fazer.
Veja que o php não é muito bom para cálculos e apresenta os mesmos “bugs” de outras linguagens de programação.
Vide: https://groups.google.com/forum/#!msg/listaphp/WlTew8kR-KI/3wHFuLxwBLUJ
Então ou você sabe o que está fazendo (usa bcmath em determinados casos) ou deixa certos cálculos e rotinas no SGDB´s.
Por vezes o SGDB´S sabe fazer melhor os cálculos.
Fico meio atrás com este negócio de abstração na conexão de dados.
Se lembra do BDE, dbexpress, firedac…
A abstração do scriptcase é baseada no PDO. Se acontece algo com ele…
Eu uso as conexões nativas que o SC dispõe (php). Até porque elas permitem usar algumas funções específicas que as vezes não tem no PDO.

Bom eu já uso PDO, em todos os tipos de BANCO:
http://www.htmlstaff.org/ver.php?id=23128

Bem legal o artigo do Jailton. Não sabia desta possibilidade…
Eu tenho algumas reservas com relação a esta matéria. Mas é sempre válida.

Alexandre. Eu penso que no BD deva ter sim a maioria das “regras”. Principalmente em grandes volumes como estou acostumado a trabalhar.

Estou aprendendo muito. Obrigado a todos, sem exceção.

Abs

Jailton,
O link apresentado ressalta mais a questão de segurança que o PDO oferece.
Veja que o scriptcase não importando o driver de conexão já previu e oferece esta segurança!

http://www.scriptcase.com.br/blog/sql-injection/
"SQL Injection no Scriptcase

No Scriptcase todos os inputs de campos, seja na aplicação de formulário, na aplicação de controle, busca ou qualquer outro input
estão protegidos não apenas do SQL Injection como também ao JavaScript Injection e ainda protegido conta a manipulação do código
fonte para execução de comandos SQL."

Logo, tanto faz o driver de conexão que você usa no scriptcase. O scriptcase fornece a segurança.

Bem! Vamos ao que interessa.

Na minha opinião se você pretende:
. Ficar pulando de SGDB em SGDB para testes;
. Irá fazer um sistema que possa rodar em vários SGDB´s como várias soluções comerciais que vemos por ai;
. Ou tem certeza que irá mudar de banco mais tarde.
Então use e abuse do PDO e evite deixar regras no banco.
Pois, alguns SGDB´s tem recursos específicos, avançados e muitos úteis que facilitam nossa vida.
E deixando as regras no SGDB você teria que se preocupar em desenvolver em php e ainda fazer a DDL, DSQL, ESQL e etc dos SGDB´S compatíveis.
Ficando o uso do banco um “arroz com feijão”, somente o básico (select, insert, update, procedures e triggers básicas).

Se você quer:
. Usar recursos específicos e avançados de um SGDB;
. Ter um driver de conexão com melhor desempenho;
. Continuar indefinidamente com o mesmo SGDB.
Faça uso de um driver específico para seu SGDB como php_interbase, MySQLi, php_sqlite e etc e deixe as regras de negócio no banco.

Agora! Como o tipo de driver de conexão é uma questão de escolha pessoal e não devemos somente falar das coisa boas de um ou outro driver.
Eu fiz o texto abaixo com relação ao PDO quando eu STFW e RTFM.

Vamos as vantagens e desvantagens:

PDO (http://php.net/manual/pt_BR/book.pdo.php)

Vantangens:
a)Funciona com 12 drivers de bancos de dados diferentes (4D, MS SQL Server, Firebird/Interbase, MySQL, Oracle, ODBC/DB2, PostgreSQL, SQLite, Informix, IBM, CUBRID);
b) API Orientada a objetos;
c) Possui parâmetros nomeados;
d) Possui prepared statements do lado cliente;
e) Segurança contra injeção de SQL (o Mysqli também possui);
f) E quase tão veloz quanto MySQLi;
g) Facilita a mudança de SGDB mudando somente a conexão. Você somente teria que mexer nos SQL se tivesse algo especifico para determinado banco;
h) Fornece uma biblioteca limpa e consistente, para deixar unificadas as características das extensões que acessam os bancos de dados.

Desvantagens:
a) http://php.net/manual/pt_BR/intro.pdo.php -> O PDO fornece uma camada de abstração de acesso a dados, o que significa que, independentemente de qual banco de dados você está usando, você usa as mesmas funções para emitir consultas e buscar dados. O PDO não fornece uma abstração de banco de dados; não reescreve SQL ou emula características ausentes. Você deve usar uma camada de abstração desenvolvida completamente, se você precisa destas características;
b) Tanto PDO quanto MySQLi são bem rápidas, porém, MySQLi se sai mais rápida nos comparativos; ~2,5% para sentenças não preparadas e ~6,5% para as sentenças preparadas;
Porém, a extensão nativa do MySQL é ainda mais rápida que ambas;
c) Por padrão, ele simula prepared statements. Você pode ativar a versão nativa ao configurar a conexão dele com o banco, mas caso a versão nativa não funcione por algum motivo, ele volta a simular os prepared statements sem disparar erros ou avisos;
d) php_interbase (extensão para firebird e interbase) é mais antiga (1998 - php 3) e nasceu no core do php. Eu considero mais testada e estável.
PDO era uma PECL com primeira versão em 21/05/2004 sendo introduzida no core do php em 26/11/2005;
e) Não tem algumas funções especificas como o php_interbase (driver firebird/interbase) tem e que por vezes abreviam digitação. Você acaba tendo que digitar todo o sql no PDO.
Exemplos:

  • ibase_blob_info não tem equivalente no PDO.
  • Um simples incremento de generator no php_interbase
    ibase_gen_id (“GEN_NAME”,1);,
    ficaria no PDO
    SELECT GEN_ID( , 1 ) FROM RDB$DATABASE; ou
    SET GENERATOR TO ; ou
    SELECT NEXT VALUE FOR FROM RDB$DATABASE; ou
    ALTER SEQUENCE RESTART WITH ;
    f) Não efetua a leitura e tradução das instruções SQL, é apenas realizada a fusão dos métodos mandados para extensão respectiva.

Material extra:

Escolhendo qual API (PDO, Mysql, Mysqli) usar com o Mysql:
http://br2.php.net/mysqlinfo.api.choosing

Algumas fontes:
http://pt.stackoverflow.com/questions/8302/mysqli-vs-pdo-qual-o-mais-recomendado-para-usar
https://www.turbosite.com.br/blog/pdo-ou-mysqli-qual-usar/
http://forum.imasters.com.br/topic/438733-pdo-quando-e-por-que/
https://bugs.php.net/search.php?cmd=display&search_for=interbase+firebird&x=0&y=0
http://narinhachaves.blogspot.com.br/2013/10/pdo-php-data-objects-conexao-em.html

Alexandre.

Muito obrigado pelo retorno e pela “aula” e evidencias fortes. Eu vou ler, estudar e retorno minha opinião.
Muito obrigado a todos que até agora contribuíram com suas respostas.
Estou bem motivado com o grupo. Muito positivo.

Aguardo mais, pessoal.

Veja na Prática como o PDO ajuda mais.
http://www.scriptcase.com.br/forum/index.php/topic,13059.new.html#new

Ainda é questão de escolha pessoal. Igual a mulher, cerveja, religião, carro e etc.
Todos os drivers de conexão tem seus pontos fortes e fracos.