Autor Tópico: Formulário: Permissão condicionada para atualização da chave primária.  (Lida 1532 vezes)

jairo

  • Novato
  • *
  • Mensagens: 14
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
« Última modificação: Agosto 23, 2014, 03:07:33 am por jairo »

flaviomorais

  • Avançado
  • ****
  • Mensagens: 348
    • Email
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #1 Online: Agosto 22, 2014, 09:36:33 pm »
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.

jairo

  • Novato
  • *
  • Mensagens: 14
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #2 Online: Agosto 22, 2014, 10:05:31 pm »
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
« Última modificação: Agosto 22, 2014, 10:14:34 pm por jairo »

flaviomorais

  • Avançado
  • ****
  • Mensagens: 348
    • Email
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #3 Online: Agosto 22, 2014, 10:09:49 pm »
rs, não disse que eu não usa triggers e procedures e fks, só tenho o estilo mais ortodoxo para algumas coisas rs

jairo

  • Novato
  • *
  • Mensagens: 14
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #4 Online: Agosto 22, 2014, 10:24:28 pm »
Ok Flavio! rss.

Fico muito grato por seus comentários.

Abraço.

FredKeyster

  • Expert
  • *****
  • Mensagens: 1702
  • DEWENNINMEN
    • Email
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #5 Online: Agosto 22, 2014, 10:38:51 pm »
Citar
...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?
« Última modificação: Agosto 22, 2014, 10:55:32 pm por FredKeyster »
F. A.
Analista de Sistemas

jairo

  • Novato
  • *
  • Mensagens: 14
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #6 Online: Agosto 23, 2014, 02:05:32 am »
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
« Última modificação: Setembro 02, 2014, 01:39:03 am por jairo »

jairo

  • Novato
  • *
  • Mensagens: 14
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #7 Online: Agosto 23, 2014, 02:55:50 am »
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
« Última modificação: Agosto 23, 2014, 03:13:24 am por jairo »

Haroldo

  • Expert
  • *****
  • Mensagens: 6293
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #8 Online: Agosto 23, 2014, 08:53:59 am »
Discordo totalmente dessa sugestão.

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

FredKeyster

  • Expert
  • *****
  • Mensagens: 1702
  • DEWENNINMEN
    • Email
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #9 Online: Agosto 23, 2014, 09:58:02 am »
Citar
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.
F. A.
Analista de Sistemas

jairo

  • Novato
  • *
  • Mensagens: 14
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #10 Online: Agosto 23, 2014, 10:23:17 am »
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
« Última modificação: Agosto 24, 2014, 09:08:02 am por jairo »

Bernhard

  • Administrator
  • Expert
  • *****
  • Mensagens: 1619
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #11 Online: Agosto 26, 2014, 10:21:25 pm »
Boa noite,

Discutirei sua sugestão com nossa equipe.

att,
Bernhard Bernsmann

Haroldo

  • Expert
  • *****
  • Mensagens: 6293
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #12 Online: Agosto 26, 2014, 10:39:07 pm »
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.



jairo

  • Novato
  • *
  • Mensagens: 14
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #13 Online: Agosto 27, 2014, 05:17:12 am »
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
« Última modificação: Setembro 02, 2014, 01:46:54 am por jairo »

Haroldo

  • Expert
  • *****
  • Mensagens: 6293
  • Conhecimento diminui limitações.△TFA△
    • Infinitus Web Gestão Empresarial/Gestão ITIL/Consultoria Scriptcase
Re:Formulário: Permissão condicionada para atualização da chave primária.
« Responder #14 Online: Agosto 27, 2014, 08:56:32 am »
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.
« Última modificação: Agosto 27, 2014, 10:12:43 am por Haroldo »