locked
Consultoria sobre DB (migração, implementação...) RRS feed

  • Pergunta

  •  

    Adir,

     

    Visualize o seguinte cenário :

     

    Base de dados SQL + Interface Web + Linguagem

     

     

    Esse é o cenário para qualquer aplicação que deseje ser competitiva no mercado de software pelos próximos 15 anos.O usuário deseja ter o que chamamos de MOBILIDADE, acessar seu sistema em qualquer lugar (casa,escritório,lan house, viajando) e de qualquer dispositivo (desktop,notebook,palmtop,celular, handheld). Com o avanço rápido e consistente da internet no mundo, cada dia que passa mais e mais pessoas estão tendo acesso on-line a internet. As pessoas estão ficando 24 horas por dia conectadas. Penso que em 10 anos teremos de alguma forma o mundo todo conectado em uma única rede de computadores, a INTERNET.

     

    Nesse cenário, vamos colocar nossas opções.

     

    Base de dados SQL, o padrão de SGBD tornou-se SQL. Por mais que se diga que existem outras formas de armazenar dados (arquivo nativo COBOL, Access, Pervasive) o que virou padrão é SQL. O fabricante do SGBD SQL é opcional porque como em COBOL o SQL tem o padrão de linguagem e os add-on do fabricante. Então a escolha do fabricante do SQL é uma analise individual de cada pessoa considerando gosto técnico pessoal e disponibilidade de recurso financeiro. Existem varias opções MS-SQL, Oracle, Pervasive,Mysql, Firebird, Interbase que são os mais conhecidos.

    Minha escolha é para MS-SQL, porque possui a maior fonte de conhecimento, e desta forma é mais fácil conseguir informações. Existe a opção comercial e a opção free que atende a todas as necessidades.

     

    Interface Web, com a internet sendo o pondo de concentração e união das pessoas no mundo, o browser (programa de acesso a paginas na internet) é a interface padrão desse ponto de concentração. Desta maneira qualquer aplicativo que se proponha a ter MOBILIDADE deve ser desenvolvido para ser executado no browser.Existem diversas formas de acesso a um aplicativo através da internet (TS, VNC,VMWARE, mas com certeza são formas que necessitam de alguma configuração que torna-se muito mais difícil para um usuário comum que pelo seu dia-dia sabe apenas utilizar o browser para acessar paginas na internet. E com esse conhecimento esse usuário teria total condição de acessar o sistema aplicativo através da interface web sem nenhuma dificuldade.

    Existem duas opções principais utilizar ASP ou PHP. Prefiro ASP por possuir um fornecedor solido por trás, a Microsoft.

     

    Linguagem, aqui estamos em casa, COBOL sem duvida. A linguagem possui 50 anos de experiência, é solida, rápida na execução, e resume-se em : funciona. O COBOL possui todos os recursos para trabalhar com SGBD SQL e com interface Web. Atualmente o mundo COBOL esta centralizado em dois fabricante Fujitsu e Micro Focus. Outros fabricantes acabaram. Acucobol e RMCOBOL foram comprados nos últimos anos pela Micro Focus. Por mais que os usuários que gostam desses ex-fornecedores digam que a Micro Focus vai manter ou aproveitar os recursos desses fornecedores adquiridos, eu particularmente penso que não. Uma empresa compra a outra por dois motivos : eliminar a concorrência ou adquiri know-how. O produtos Micro Focus sempre teve recursos interessantes e não vejo onde pode ser beneficiado em adquirir know-how. Para eliminar a concorrência é a opção mais coerente.

    Fujitsu é a escolha certeira para participar desse cenário. Fujitsu é líder mundial em diversos segmentos de tecnologia e possui uma divisão de software COBOL com sede em Tokyo-Japao que mantém o produto atualizado e competitivo.

    Muitos usuários, principalmente os pequenos, reclamam dos preços cobrados pela Micro-Focus que alem de cobrar em media US$ 9,000.00 por uma licença do desenvolvedor do produto COBOL cobram RunTime de US$ 4,000.00 por 10 usuários. Essa reclamação não é valida porque existem opções. Fujitsu cobra US$ 5,000.00 por uma licença do desenvolvedor e não cobra RunTime. Uma diferença muito significativa.

     

    1.     Propriedade Intelectual da Estrutura do Banco de Dados e Dados:

    2.     Camada de Segurança:

    Nesses pontos você pode instalar o BD de forma silenciosa colocando a senha do System Administrator que seja apenas do seu conhecimento. Assim qualquer tentativa de acesso ao BD será necessário conhecer essa senha e assim as informações sobre estrutura de tabelas, dados e caso ocorra roubo do BD as informações estarão protegidas.

     

    Espero que esses conceitos possam ajudar em sua escolha do melhor caminho a ser seguido e que grandes negócios você possa fechar para continuar sempre crescendo. Voce pode contar com a Fujitsu Projetos Especiais que desde o ano passado estão totalmente ligadas e unificadas para ajudar a comunidade COBOL. As equipes de desenvolvimento no Brasil podem prestar um bom serviço a você.

     

    Qualquer duvida estamos a disposição.

     

    Abraços

     

    Gilberto Junior
    Authorized Reseller of Fujitsu Computer Systems Corporation
    http://www.projetosespeciais.com.br
    Participe : COBOL no MSDN - Microsoft Developer Network
    http://forums.microsoft.com/MSDN-BR/ShowForum.aspx?ForumID=1735&SiteID=21

     

     

     

    De: Adir Dagostin

    Enviada em: quinta-feira, 8 de janeiro de 2009 13:34
    Para: Gilberto Junior
    Assunto: Re: Consultoria sobre DB (migração, implementação...)

     

    Gilberto,

     

        Fico feliz com sua resposta. Acho que vai ficar um pouco extenso mas vou tentar te posicionar em detalhes nossa situação.

     

        Assim, temos as bases de dados dos nossos clientes todas em arquivos indexados padrão MF-Cobol. Como já haviamos conversado, o ideal seria migrar de aplicação Windows para .NET bem como arquivos para Banco de Dados.

     

        Desenvolvemos um programa que trata de pegar o sinal de cada Read, Write e Rewrite (disparados atualmente nos nossos programas Netexpress) e disparar um Select, Insert e Update no banco de dados (rotina desenvolvida no Net Cobol) e ao contrário também para facilitar nosso processo de migração e não ter de desenvolver tudo para somente após o Sistema completamente pronto iniciarmos o processo de migração em nossos clientes.

        Em nossos testes, tudo funcionando muito bem, compatível com a realidade (tempo de processamento), segurança das informações. Desenvolvemos nosso parkway por ex.

     

        Chegamos então num ponto onde poderiamos estar iniciando o processo de publicação de parte do nosso sistema e ai começaram os problemas.

     

        Efetuamos testes com o Firebird e com o SQL Server 2008 Express Edition, isso porque centralizamos nossas forças em Gerenciadores de Banco de dados que sejam free (a exemplo da hostória do RunTime que você já conhece). O Firebird em função de já termos alguma coisa desenvolvida em Delphi e usar o mesmo como SGDB. SQL Server em função de ser pleno a .Net e ser uma ferramenta Microsoft.

     

    Pontos de dúvidas ou críticos:

     

    1. Firebird:

        Pontos fracos:

            Projeto Open Source - Facilidade no desenvolvimento de rotinas para manipular dados do BD;

            Não possui nível de segurança algum ou ainda, muito falho e fácil de ser burlado;

            Necessita de Servidor dada arquitetura;

            Necessita ter seu Serviço "Startado" o que demanda de configurações de Firewall etc;

            Não é Microsoft ou parceiro direto;

            Requer um DBA ou ao menos alguém que entenda mínimamente de informática para dar manutenção in loco...

     

        Pontos fortes:

            É leve;

            Dispõe Provider para .Net;

            É de fácil operação;

            É simples.

            Free com limitações de suporte...

     

    2. SQL Server Express Edition:

        Pontos fracos:

            Relação de pré-requisitos é muito grande;

            Demanda de conhecimento intermediário para processo de intalação;

            Demanda de muito tempo para implantação/instalação;

            Requer diversos tipos de downloads conforme cada versão de OS, Framework, Linguagem etc...

            Requer equipamentos mais poderosos...

            Nível de complexidade alto para suporte via help-desk;       

            Requer um DBA com conhecimentos mais apurados para manutenção...

           

        Pontos fortes:

            Full .Net;

            Fácil desenvolvimento e documentação;

            Diversos softwares de apoio como por ex. monitoramento, despempenho etc...

            Microsoft;

            Free porém com limitações de processadores, tamanho do BD, memória...

     

     

        Em ambos, ainda teriamos vários pontos a serem discutidos:

     

    1. Propriedade Intelectual da Estrutura do Banco de Dados e Dados:

        Hoje, nossas FDs estão todas internas nos programas. O usuário não sabe o que é cada arquivo nem muito menos sabe sobre a estrutura desses arquivos/tabelas.

        No banco de dados, ao usarmos um IBExpert (Firebird) ou mesmo um SQL Mananger (SQL Server), temos facilmente acesso as tabelas, estruturas, dados inclusive com possibilidade de podermos alterar os dados e "comitá-los". Já pensou alguém do depto. financeiro ter acesso as contas a receber da empresa e poder manipulá-las conforme quiser através destas ferramentas?

     

    2. Camada de Segurança:

        Hoje, nossos clientes colocam suas bases de dados (arquivos indexados) numa pasta onde compartilham os dados com diversos micros. Se, por ventura algum "roubar" esses arquivos, não fará acesso as informações pois estas somente tem seu acesso descriptografado através do login no sistema.

        Com o banco de dados, ai esboçamos ainda mais nossa ingenuidade no assunto, deve-se protejer o servidor da empresa permitindo que, somente o DBA tenha acesso ao mesmo e, caso seja necessário informações do Banco de Dados, este é feito através de serviços de requisição e não de compartilhamento de arquivos.

     

        Como gerenciar isso uma vez que não temos DBAs em nossos clientes, não gostariamos de abrir a estrutura/dados para acesso sem que fosse logado pelo nosso sistema (tirar da jogada IBExpert, SQL Manager etc...)?

     

     

        Bom, para não alongar ainda mais as coisas, é mais ou menos nesse cenário que nos encontramos.

        Em maio/2009 estarei nos Estados Unidos na Tech-ed 2009 North América (Los Angeles - CA), gostaria de saber se existe algum escritório da Fijitsu que dá abertuda para visitação, quem sabe algum curso-bate-papo, sobre os produtos e tecnologias.

     

     

     

        Aguardo seu parecer para coordenarmos algum encontro.

     

     

    Um abraço,

     

     

    Adir Dagostin

     

    domingo, 18 de janeiro de 2009 16:47