WG
Adianti Studio: AUTO_INCREMENT na geração de SQL de modelo XMI
Fechado
Boa noite pessoal.
Como faço para que o Adianti Studio Pro ao gerar o sql de um banco a partir de modelo XMI, gere também o AUTO_INCREMENT das chaves primárias ?
Como faço para que o Adianti Studio Pro ao gerar o sql de um banco a partir de modelo XMI, gere também o AUTO_INCREMENT das chaves primárias ?
Boa tarde,
Sempre inclui manualmente, se tiver outra forma também fico no aguardo de uma resposta.
Fica como sugestão para o Pablo de criar uma opção para definir as chaves primárias como Auto Numeração na geração do código.
+ TODO list ;-)
Valeu! Isso é interessante!
Um outro ponto que me surgiu hoje.
Estava trabalhando num diagrama de classes de Produtos, seguindo a nova lei de informação de tributos (De Olho no Imposto) onde todas as notas fiscais por lei agora devem informar a carga tributária total estimada, através do código NCM (Nomenclatura Comum do Mercosul), e então pensei: Se já tem o código NCM, por que usar o ID como chave nas relações; não teria como na importação ter uma opção para escolher qual será campo que irá compor Chave Primária(NCM em vez de id) e Chave Estrangeira(classe_NCM em vez de classe_id)?
Pensando nessa forma, por questão de padrões, acaba tendo redundância de campos, pois já teria um campo único que seria um forte candidato a chave primária, mas mesmo assim obrigaria o uso de outro campo id para compor a chave!
Oi Wemerson,
Pois é, em alguns casos podemos abrir exceções. Se bem que em teoria não deveríamos usar uma informação que possui significado no mundo real como chave primária, pois não temos controle sobre essa informação, ou seja, ficamos nas mãos do governo nessa situação. A utilização do ID surrogate nos liberta nesse sentido.
Abraços,
Pablo
Além disso, o NCM pode ser marcado com o "unique index" para garantir unicidade, além de NOT NULL.
Cara, sobre essa questão de ficar nas mãos do governo, o caso é sério pois não ficamos nem na mão do governo brasileiro e sim na mão de vários governos, no caso os países do Mercosul todo, hehehehe!
Acabei de descobrir que produtos que simplesmente mudam de código por vários motivos, como adequação na sua classificação. Também tem casos estranhos como o suco de laranja que tem mais de um código, onde congelado é 20091100 e descongelado é 20091200 além de um terceiro código 20091900 que caracteriza outros estados que não vou entrar em mais detalhes aqui porque não vem ao caso! Enfim, o que interessa é que quando você falou sobre usar informação com significado no mundo real eu fui pesquisar um pouco sobre o NCM e encontrei o caso do suco e alguns mais, o que realmente inviabiliza usá-lo como chave primária.
Mas o ponto que eu queria chegar nessa thread é justamente ter opção de sair fora da caixa, ou melhor, do gesso que muitas vezes os frameworks nos obrigam a seguir. Na maioria dos casos é ótimo seguir os padrões, mas em algumas poucas exceções precisamos ter flexibilidade. Suponhamos que fosse o NCM não tivesse essas duplicidades, o framework permite usar outros campos como chave primária ou está "travado" no ID