Relow! Relow! Relow! Redolfo.. Dg, Rodolfo

Como vão as coisas.. Espero que tudo bem!
>
>Venho faz algum tempo pensando uma maneira de ter apenas 1 projeto e deixá-lo funcionando com uma dessas bases de dados: DBF, SQL Server e Postgree!... Assim, o cliente pode escolher qual base usar, etc... Minhas dúvidas:

Isto é uma característica do novo "boom" em análise se sistema. Que é o N-tier (ou multi-camadas)

Aqui no nosso projeto atual (projeto da nova versão do nosso sistema de comércio) identificamos 4 camadas:

1. A interface do usuário (Forms, reports e objetos)
2. As regras de negócio (Calculos, Algoritimos e Validações de dados)
3. As regras do aplicativo (Preferencias de uso, regras de utilização de recursos)
4. O acesso a dados (Modificação nos dados, Regras em referência a dados, Querys)

>
>1) Segurança!
>
>Hoje uso DBC/DBF e faço tenho um cadastro de usuários do programa. Neste cadastro tenho nome/senha do usuário e o que ele pode (ou não) fazer. Por exemplo: Se pode consultar/incluir/alterar/excluir clientes / produtos / etc... Qual o desconto máximo permitido em uma venda... Qual condição de pagamento o usuário pode oferecer, etc...

Acredito que hoje voce utilize as regras de negócio dentro do DBC (não é isto ?).. Tire-as de lá ! Crie bibliotecas, Com objetos do tipo custom ! Adicione suas regras de negócio como metodos.. Organize-as mais ou menos assim:

Biblioteca: CRM_XX_TIER1.vcx (CRM=admnistração de relacionamentos com clientes, XX=inicias do seu sistema, TIER1=A interface do usuário)
Conteúdo:
. objetos tipos text, form, label, etc..

Biblioteca: CRM_XX_TIER2.vcx (TIER2=regras de negócio)
Conteúdo:
. objeto tipo custom, nome Validador_de_dados, metodos: validador_cgccpf, verifica_existencia, possue_vendas, etc..
. objeto tipo custom, nome Calculos, metodos: Curva_ABC_clientes, Estatistica_de_vendas, Calculo_digito, calculo_do_individamento, etc..

Biblioteca: CRM_XX_TIER3.vcx (TIER3=As regras do aplicativo)
Conteúdo:
. objeto tipo custom, nome Regras_do_aplicativo, metodos: Preferência_de_cor. Preferencias_de_pictures, Preferencia_tamanhos, etc..

Biblioteca: CRM_XX_TIER4.vcx (TIER4=O acesso a dados)
Conteúdo:
. objeto tipo custom, nome Bd_de_clientes, metodos: incluir_clientes, alterar, etc..

>
>Sei que o SQL / Postgree possui gerenciamento de segurança no próprio banco quanto ao tipo de instrução (Select/Insert/Update/Delete/StoredProc)... Até aí tudo bem... mas vamos imaginar que eu precise permitir um determinado usuário a deletar um "grupo" (inativos) de clientes, mas impedir que delete outro "grupo" (os ativos)...

Ai teremos os metodos de Acesso a dados perguntando aos metodos regras do aplicativo e regras de negócio a possibilidade de isto ser feito.. TODAS as regras de segurança (acesso a dados) não deverão estar mais no BD e sim nos metodos de seu aplicativo..

Até o N-tier, estas regras estariam no próprio BD.. Isto foi uma forma dos "Oracles e Sqls da vida" fidelizarem a sua clientela..

>
>No caso do desconto... Como falar para o banco que aquele usuário pode oferecer 5% e o outro 10%?

Pergunte a "turma das Regras de negócio" do seu aplicativo !

>
>Em DBC: Select Nome+Sobrenome From Clientes ou Update Clientes Set Nome = "Rodolfo" Where Codigo = "100" funcionaria sem problemas... mas sei que outros bancos a sintaxe é diferente... Como vocês tratam isso?

A "turma do acesso a dados" perguntará a "turma das regras do aplicativo" qual é o banco que esta no ar.. Verá o que lhe foi solicitado (inc;alt;del;con) e fará esta tarefa dentro da sintaxe necessária..
>
>3) Recursos do próprio banco:
>
Voce limitará ao máximo a utilização de quaisquer tipos de recursos do banco !

>Em DBC: Begin Transaction / End Transaction / Rollback ... em outros bancos Commit... - Como deixar o aplicativo pronto para gerenciar transações nos diversos bancos?

A turma do "Acesso a dados" deverá estar imcubida sempre de executar dentro da sintaxe necessária das funções que lhe forem ordenadas

>
>Views / Backup / Stored Procedures: Esses recursos são interessantes, melhoram desempenho / segurança... mas cada banco trata de um jeito.... Existe uma maneira de minimizar as diferenças?
>

Morreram !! Se a filosofia for N-tier !

A ideia é ser o menos fiel possivel ao gerenciador de banco de dados A, B ou C..



Espero ter colaborado


Claudio