2009/1/15 Mozart Hasse <[email protected]>: > Candido, > >> > Alguém tem alguma experiência com esse tipo de situação? > > Bom, em todas as empresas que trabalhei nos últimos 15 anos, os clientes > sempre tiveram acesso total à estrutura do banco de dados deles. > > Aliás, normalmente o que ocorre no meu caso é que nós somos agraciados com > uma senha com poucas permissões para ter o privilégio de criar nossas > tabelas no espaço que o cliente alocar a gente (esses tempos tivemos um que > resolveu nos dar 5% da CPU do monstruoso servidor dele para cuidar do nosso > schema). O máximo que conseguimos é pedir ao cliente para ele não colocar > muitas tabelas e triggers no nosso schema senão complica nosso trabalho de > manutenção nas nossas tabelas devido à integridade referencial imprevista, > complicações na replicação e triggers inesperadas. Em empresas grandes > acho para lá de improvável que um fornecedor só consiga atender a todas as > necessidades de banco de dados de uma empresa, o que implica em integrações > e conviência com outros fornecedores de software, tornando assim praticamente > impossível trabalhar num ambiente em que o schema não seja público. > > Considerando o aspecto de distribuir a estrutura do banco de dados por aí, > estou convencido de que de tudo o que o cliente tem que lhe pareça valioso, a > estrutura provavelmente nem entra na lista. Deixar vazar o banco de dados com > os dados do cliente (como a carteira de clientes, volume de faturamento, a > lista de fornecedores ou meramente preços de custo ou venda) é um desastre > para qualquer empresa, e duvido muito que algum cliente queira perder tempo > tentando lucrar com a venda da estrutura expondo qualquer informação dessas. > Normalmente o cliente guarda a base a 7 chaves assim que consegue entender > para que ela serve e o que acontece se o concorrente dele fizer um SELECT lá > dentro. > > Ao menos no meu caso (ERP), o cliente por definição tem seu negócio no que > não é informática, e portanto entende muito pouco de SQL para saber como > tirar os dados sigilosos antes de distribuir a base por aí, mesmo que alguém > oferecesse dinheiro a ele para fazer isso. > > Além do mais, com mais de 800 tabelas e uns 95% de todos os cálculos de > negócio fora do banco, a utilidade da base para nossos concorrentes é tão > pequena que nem esquentamos a cabeça com isso. Acho que mesmo se alguém > projetasse toda a regra de negócio na base (a ponto dela por sí só > representar um percentual relevante da solução como um todo), via triggers, > sequences, functions e views, o trabalho que alguém teria montando um sistema > para se comunicar com essa parafernália toda seria tão grande que ninguém > perderia tempo com isso. >
Eu concordo com o Mozart. Os dados sempre são do cliente. Você vai sentir isso de formas diferentes em clientes diferentes com situações diferentes. * Se você faz o software e aloca este software num servidor seu e vende apenas o serviço para o cliente usar o seu software no seu servidor. Os dados ainda são do cliente. Você deveria mandar um dump periodicamente dos dados do cliente para ele. É claro que você não precisa mandar todas as suas funções em PL, mas os dados das tabelas sim. * Se você faz o software e aloca este software num servidor do cliente, os dados são do cliente. O cliente tem acesso ao servidor. Quem tem acesso ao servidor SEMPRE tem acesso a tudo. O que algumas pessoas fazem, no Oracle por exemplo, é criar PL/SQL criptografado para esconder uma parte das regras de negócio guardadas dentro do banco. O postgreSQL não tem suporte nativo para isso, motivo de algumas empresas torcerem o nariz para ele. Particularmente, eu acho que este tipo de coisa sempre cria um grande gargalo de performance. * Se a empresa é pequena e não tem uma infra de TI razoável, não vai ter analistas fazendo consultas direto no banco, mas vai ter um ou outro executivo que gostaria de poder se conectar via planilha ou um gerador de relatórios para poder explorar os dados. É de bom tom criar um usuário com permissão de leitura em algumas tabelas ou visões para estes usuários especiais. * Se a empresa é grande, ela terá um DBA próprio e o fornecedor é quem vai ter que se enquadrar nas regras do DBA. O DBA vai exigir a documentação da base, vai fazer a reversa dele e vão criar ETL para integrar esta aplicação com outras já existentes ou que venham a surgir. Quem fornece software para cliente grande, sabe que o nível de exigência é grande. Sempre que uma empresa grande se mete a comprar um pacote de um software de empresa pequena o fornecedor corre o risco de quebrar as pernas, pois vai encontrar uma tonelada de exigências que não está acostumado a ter. Mas senhores, estamos numa lista de software livre. Eu não apenas gosto do PostgreSQL, gosto da comunidade e gosto do fato dele ser livre. Eu sempre acho que o cliente deve poder mais. Não há como discutir se o cliente é ou não dono dos dados. Se ele romper o contrato e resolver utilizar outra aplicação, ele vai ter que importar estes dados. As informações são dele, não há como negar este direito. O que se deve evitar é que o cliente faça meleca na base dando privilégio para alterar tudo para qualquer um particularmente na base de produção. Deve sempre haver uma base de homologação e um contrato de suporte. Essa história de pacote que se compra sem serviço não existe, ou não deveria existir. O fornecedor tem que resguardar os direitos do cliente e além de tudo fornecer uma boa documentação das tabelas, gatilhos, roles, etc. O cliente tem o direito de interagir com os dados e tem o direito de querer integrar estes dados com outras aplicações. Tem gente que faz o absurdo de criar tabelas com nomes indecifráveis e até nome de campos assim. Há quem não utilize FK para dificultar ainda mais o uso de uma reversa no banco. Todas as vezes que eu encontrei isso na minha frente eu exigi a documentação pormenorizada de tudo o que eu precisava. E o fornecedor levou quase 2 anos para fazer isso nas suas mais de 2 mil tabelas, pois nem a documentação que eles tinham internamente eu considerei suficiente. Eles tiveram que começar a documentar tudo novamente... é claro que num contrato de manutenção de mais de 1 milhão por ano, você tem o direito de exigir algumas coisas. Enfim, você até pode colocar um montão de exigências para o cliente num contratão... que em geral servem para resguardar os direitos de (c) do fornecedor que tem a mente proprietária até o último fio de cabelo. Veja já é prática de muitas empresas grandes exigir o código fonte. Até a Microsoft abriu o código fonte para vários clientes. É claro que abrir != de liberar sobre licença livre. Mas já é um avanço para o cliente. Mas se um dia você for a justiça para brigar com o cliente, os dados sempre vão pertencer ao cliente. Não importa o que você coloque no contrato, a não ser que seja você que alimente os dados, e não o cliente. Mas aí já é o caso de quem vende informação e não sistemas. É o caso absurdo dos correios que vendem a base de CEP por exemplo. Bom, mas esta é uma outra história. Deixo a frase do Sr. Corinto Meffe para vocês: "O software é livre, mas as mentes ainda são proprietárias" Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
