Formulário: Permissão condicionada para atualização da chave primária.

Sugestões
#1

Adotar chave primária descritiva em minhas bases tem sido maravilhoso, pois obtive melhor compreensão dos dados, maior performance nas ordenações e maior simplicidade em minhas consultas. Porém, infelizmente, os usuários dos meus sistemas não estão podendo atualizar estes campos nos formulários.

Campos de chave primária ficam disponíveis para entrada de dados somente durante as inclusões, nas atualizações eles passam a ser somente de leitura.

Quando surge a necessidades de atualização de algum desses campos tenho que recorrer a um cliente para o MySQL como o MySQL Workbench. E ainda tenho que me explicar com meu cliente.

Uma sugestão, para uma implementação tranquila:

Na configuração do formulário poderia haver um novo atributo, como por exemplo: “Permitir atualizar a chave primária: ( ) Sim (X) Não”.
O valor padrão seria “Não” para evitar problemas com desenvolvedores desavisados.
E os desenvolvedores terão que alterar este atributo para “Sim” caso queiram permitir a atualização da chave primária, como no meu caso.

As regras para as atualizações que sejam críticas, serão discutidas entre o desenvolvedor e o seu cliente, se necessário.

O ScriptCase precisa atender tanto desenvolvedores iniciantes como profissionais.

Ficarei muito grato caso meu pedido possa ser atendido.

Abraço para toda a equipe.

Jairo N C Raiol
Desenvolvedor PHP
Especialista Internetworking e Data Center

jairoraiol@gmail.com

#2

Na minha opinião a chance disso gerar mais problemas que ser uma solução, principalmente se tem ligações com outras tabelas essa chave.

#3

Caro Flavio,

Não haverá problema algum se essas ligações forem feitas através do uso de chaves estrangeiras nas tabelas filhas, o que nos dá integridade referencial.

No passado eu não utilizava este recurso do banco de dados, por isso eu também pensava como você.

E também estou fazendo uso de stored procedure, triggers e tabelas transacionais, o que torna minhas bases mais confiáveis.

O ScriptCase precisa atender tanto desenvolvedores iniciantes como profissionais.

Grato.

Jairo Raiol

#4

rs, não disse que eu não usa triggers e procedures e fks, só tenho o estilo mais ortodoxo para algumas coisas rs

#5

Ok Flavio! rss.

Fico muito grato por seus comentários.

Abraço.

#6
...nas atualizações eles passam a ser somente de leitura.

Não entendo a lógica de querer fazer update em uma chave primária! Principalmente com o banco com tabelas relacionais! Esse pensamento não foge da regra de se ter um banco estruturado?

#7

Caro FredKeyster,

Vamos lá!

Realmente não se pode permitir a atualização de qualquer chave primária. Em uma tabela de “clientes” por exemplo, caso a chave primária seja um campo inteiro de auto incremento a atualização não deve ser permitida, mas caso o campo CNPJ esteja sendo usado como chave primária, o que ao meu ver é algo bem aceitável, a atualização pode vir a ser permitida respeitando politicas de autorizações da empresa usuária do sistema.

Um exemplo prático para o uso das chaves primárias atualizáveis seria algo semelhante ao esquema de diretórios, como no caso das tabelas “estados, cidades e bairros”:

/estado1
/estado1/cidade1
/estado1/cidade1/bairro1
/estado1/cidade1/bairro2

Mesmo que um DBMS não seja voltado para esquemas de diretórios, nada nos impede de adotarmos o modelo de diretórios em nossas bases. Trata-se apenas de mais uma forma de estruturarmos nossos dados. E neste caso não há a necessidade de criarmos campos específicos para a chave primária, visto que podemos utilizar as próprias descrições das entidades aqui mencionadas para obtermos as chaves primárias. E com uma simples consulta SQL obtemos uma listagem agradável, limpa e bem organizada, sem o uso da cláusula de junção.

Eu tenho utilizado este modelo para alguns grupos de tabelas, como foi no caso de um sistema para planos anuais de exames médicos, onde a estrutura ficou assim:

clientes
|
±— planos
|
±— setores
|
±— cargos
|
±— riscos
|
±— agentes
|
±— procedimentos

Somente a tabela “clientes” ficou com a chave primária na forma tradicional, ou seja, campo inteiro de auto-incremento, apesar de que poderia ter usado o campo CNPJ como chave primária.

Resolvi utilizar o modelo de diretórios porque quando meu cliente me mostrou suas listagens eu pensei comigo mesmo: “DIRETÓRIOS!!”. Assim foi feito, e fiquei muito satisfeito, e obviamente meu cliente também ficou, mas não pelos mesmos motivos que eu.

Para finalizar, preciso dizer também que ainda não conheço um DBMS que proíba a atualização da chave primária, isso deve ser um bom sinal. Não acha ?

Grato.

Jairo Raiol

#8

Olá Jailton!

Por existirem casos e mais casos, como você disse, é que sugeri apenas a inclusão de um novo atributo na configuração do formulário, simples assim. O que acredito ser o suficiente.

Só para lembrar da sugestão:

Na configuração do formulário poderia haver um novo atributo, como por exemplo: “Permitir atualizar a chave primária: ( ) Sim (X) Não”.
O valor padrão seria “Não” para evitar problemas com desenvolvedores desavisados.
E os desenvolvedores terão que alterar este atributo para “Sim” caso queiram permitir a atualização da chave primária, como no meu caso.

As regras para as atualizações que sejam críticas, serão discutidas entre o desenvolvedor e o seu cliente, se necessário.

Fico grato por seu comentário.

Abraço.

Jairo Raiol

#9

Discordo totalmente dessa sugestão.

Crie um indice para. Isso. Exclusivo ou nao e cheque voce se a alterçao.pode gerar duplicidade.

#10
Trata-se apenas de mais uma forma de estruturarmos nossos dados. E neste caso não há a necessidade de criarmos campos específicos para a chave primária...

Esse conceito pra mim é novo e não convincente!

Mas se resolve. Beleza! Agora eu acho indispensável o uso dos Joins em consultas principalmente quando é pra desenvolver relatórios pdf complexos e ate mesmo simples. Quem tem sistemas financeiros ou escolar que o digam.

#11

Olá gente!

Com relação ao JOIN, também considero muito importante o seu uso, caro FredKeyter, apenas não o utilizei no caso que explanei anteriormente, mas faço uso desta cláusula em outras situações com certeza.

Com relação ao comentário do colega Haroldo, tentei outras alternativas para lidar com este bloqueio que ocorre no ScriptCase, inclusive considerei utilizar índices únicos também, porém, neste caso, perderia o recurso de integridade referencial do banco de dados, o que só funciona com o uso de chaves primárias.

Portanto ainda não vejo uma outra solução.

Esta necessidade surgiu como consequência de uma reestruturação dos dados de alguns sistemas. Logo, não era a atualização da chave primária que eu estava buscando, mas preciso dela para que tudo ocorra como planejado.

Vale lembrar também que minhas bases são construídas com o uso de tabelas transacionais, stored procedures, triggers e integridade referencial. Portanto estas bases podem ser consideradas seguras, de alta performance e mais independentes das aplicações, e desejo que continuem assim.

Possivelmente, o que estou propondo aqui seja uma quebra de paradigma, por isso algumas pessoas ainda não estejam aptas e/ou seguras para concordarem com o que tenho dito neste tópico.

Quero também aproveitar para lembrar que o atributo sugerido para as aplicações de formulário, não irá afetar em nada as aplicações já desenvolvidas e as futuras aplicações, a ainda colocará o ScriptCase em concordância com os DBMSs que como já se sabe permitem a atualização da chave primária.

Fico grato por seus comentários.

Jairo Raiol

#12

Boa noite,

Discutirei sua sugestão com nossa equipe.

att,
Bernhard Bernsmann

#13

Não vejo sua sugestão como quebra de paradigmas e sim quebra de normas para uma boa modelagem.

Volto a afirmar:

PK -> campo do tipo inteiro autocomplete. (O próprio workbench sugere o primeiro campo com essa configura;áo)

Sua chave: do tipo Index

SC: Habilitar seu campo como chave exclusiva.

Poderá alterar a chave e o próprio SC verificará a existência se caso alterar para uma chave duplicada.

Uma registro deve nascer com pelo menos um índice exclusivo e esse deve permanecer como ponteiro para sua localização por toda sua existência, para isso usamos as PK, que também são referencias de relacionamento com outras tabelas.

1 Curtida
#14

Caro Haroldo,

Só para esclarecer melhor, a quebra de paradigma que mencionei se refere a como compor a estrutura de dados de alguns relacionamentos, veja bem, eu disse alguns relacionamentos, é isso que estou tentando deixar claro desde o inicio, pois até mesmo nestas soluções que me referi também utilizo PK inalterável em algumas tabelas.

Atualmente estou lidando com estruturas de dados em um outro nível. Para se ter uma ideia, até utilizo chaves primárias compostas, inclusive uma foi criada com 7 campos vinculados.

Chaves primárias do tipo inteiro e auto incremento são as chaves mais simples que existem e que todos estão mais habituados.

Chaves primárias compostas servem para soluções mais complexas por isso são menos utilizadas, como pode ser observado nos comentários deste tópico.

Haroldo, depois de um certo tempo percebi que nem toda estrutura de dados requer necessariamente uma chave primária inalterável. No banco de dados não estou encontrando impedimentos e as implementações estão ocorrendo sem problemas, inclusive tenho um sistema implementado desta forma e em funcionamento a mais de dois anos.

Como você já deve ter notado, estou falando de novas ideias para a estruturação de dados de algumas soluções, por isso que mencionei quebra de paradigma.

Acredito que a sugestão fará muito bem a ferramenta Scriptcase, pois a tornará mais flexível.

Que bom que minha sugestão será discutida pela equipe da NetMake.

Grato por seu comentário.

Jairo Raiol

#15

Eu trabalho em cima de um conceito;

Modelagem em banco de dados relacional com base na metodologia defendida por Carlos A. Heuser no livro cujo o título em português é"Projeto de Bando de Dados" .

Chaves compostas e alfanuméricas consomem mais processamento em inserções além de cair performance quando são utilizadas como chaves estrangeiras.

Quem estudou o conceito de índices arvore binária (b-tree) vai entender o que estou falando.

Jairo,

Boa sorte em sua empreitada, daqui para frente não posso ajudar mais.

  • Pela sua observação nós que usamos o modelagens com PK numéricas auto-incrementadas nossos sistemas são simples e não temos sistemas complexos?
  • Para toda e qualquer sugestão aqui sempre há uma postagem que será levado para discussão com a equipe de desenvolvimento, se realmente é discutido, ponderado e se será levado em frente para implementação nunca sabemos, então não se empolgue muito com isso.
#16
Chaves primárias compostas servem para soluções mais complexas por isso são menos utilizadas, como pode ser observado nos comentários deste tópico.

Isso me lembra as rotinas que eu estava estudando com Python! A chave primária é um MD5. O banco não é relacional como tradicionalmente vemos. Pensei que essa estrutura (Novo paradigma) era apenas feito em Python com framework Django.

No mais, com toda humildade e sinceridade não consegui entender o conceito do seu caso! Mas desejo que consiga resolver de acordo com seus preceitos.

Grande abraço.

#17

Indice com 7 chaves compostas… sei…

Os Sistemas Gerenciadores de Banco de Dados - SGBD - possuem estruturas que propiciam a localização e o acesso mais rápido a dados específicos dentro de uma tabela e, adicionalmente, contribuem nas consultas envolvendo ordenações, agrupamentos e junções. Essas estruturas são notoriamente conhecidas por índices.

Em contrapartida aos benefícios proporcionados nas buscas de dados, essas estruturas consomem espaço de armazenamento e geram impactos negativos em termos de desempenho e concorrência nas operações de atualização - update, delete e insert - das tabelas a qual estão associados.

Assim, os índices não podem ser criados aleatoriamente, sendo suas características e quantidade dependentes das expectativas dos usuários, do espaço de armazenamento disponível, do overhead da manutenção e administração e, principalmente, da finalidade do banco de dados; apoio a processos operacionais ou a processos de Business Intelligence. Tais pontos são considerados pela estratégia de indexação.

Índice de Árvore Binária

O índice B-Tree possui uma estrutura hierárquica que armazena ponteiros para as linhas de uma tabela – ver figura 2 –, sendo indicado para colunas chaves – coluna que faz parte de um índice – cujos valores apresentem muita distinção como, por exemplo, aqueles encontrados em uma coluna que será chave primária. Por outro lado, seu uso proporciona desempenho reduzido – se houver – para colunas com pouca diferença de valores como, por exemplo, nos casos de Unidade de Federação ou Sexo.


Figura 2 – Estrutura do índice B-Tree (Adaptado da Oracle)

Leia mais em: Estabelecendo uma estratégia para o uso efetivo de índices http://www.devmedia.com.br/estabelecendo-uma-estrategia-para-o-uso-efetivo-de-indices/8068#ixzz3BbY4yUR3

#18

Olá gente!

Mais facilidades durante o desenvolvimento, maior segurança no sistema e maior complexidade na estrutura de dados sempre irão exigir mais processamento e memória.

Por sorte, hoje em dia, podemos contar com muitas tecnologias avançadas de rede, armazenamento e processamento, que nos ajudam, e muito, nestas questões.

Por isso, ultimamente, não estou restringindo todo o meu trabalho por conta das características de certas técnicas. Mas levo estas características em consideração nos casos onde realmente há a necessidade do aumento de performance e não há recursos para o aumento do poder de processamento.

Não é minha intenção derrubar conceito algum, e sim mostrar que podemos nos deparar com muitas situações diferentes, e não precisamos lidar com todas essas situações sempre da mesma forma, afinal de contas é por isso que os SGBDs são bastante flexíveis, e assim eles conseguem atender uma grande variedade de casos. Cada um trabalha como mais lhe parece adequado a situação.

E o Scriptcase pode sim, ser bastante flexível também. Por quê não?

Jairo Raiol

#19

Olá gente!
Só para acrescentar.

Como já foi dito, para alguns relacionamentos adotei o seguinte:
Chaves primárias e estrangeiras compostas a partir de campos tipo texto contento dados como descrições ou nomes.

E dentre outras coisas, observei que:
1- A respeito do incremento no tempo de processamento com chaves primárias compostas durante as inserções, não obtive impacto humanamente perceptível mesmo em equipamentos modestos, e foi por esse motivo que na época da primeira implementação não encarei esta característica como impeditiva, e continuo não encarando.

2- Durante a formação dos relatórios de grandes volumes de dados com o uso de ordenações, quebras e resumos, percebi benefícios, pois o sistema utiliza os índices provenientes das chaves estrangeiras compostas. Isto ocorre porque o conteúdo dos campos que compõe estes índices são os mesmos dados exibidos nas consultas, e não códigos numéricos. Foi a respeito desta performance que me referi na abertura deste tópico.

3- Todos os conceitos são válidos, porém, tão importante quanto conhecer os conceitos é saber onde e quando aplicá-los.

Por enquanto é isso pessoal.

O Scriptcase melhorou muito nos últimos anos e espero vê-lo cada vez melhor.
Aproveito para agradecer a Bernhard Bernsmann e toda a equipe da NetMake pela atenção.

Jairo Raiol

OBS.: Algumas vezes já me senti engessado com o uso do Scriptcase, mas sempre consegui uma forma de contornar certas limitações, como foi com o fato das aplicações do Scriptcase não serem recursivas, o que me levou a aplicar o conceito da recursividade indireta, que funcionou muito bem. Mas desta vez nada posso fazer, dependo inteiramente da NetMake.

#20

Olá gente!

Testando a atualização da chave primária nas versões 7 e 8 do ScriptCase, obtive a seguinte mensagem:

ERRO
Erro ao alterar a base de dados - Registro inexistente

Acredito que isso acontece devido ao fato de os valores alterados dos campos da chave serem utilizados na cláusula WHERE, e não os valores originais dos campos da chave.
Então, me parece que a questão aqui é apenas de correção no comando UPDATE.

Ficarei imensamente grato com este ajuste.

Jairo Raiol