Ao que parece pretende-se checar se o número de caracteres desse atributo é igual a 5 ou igual a 7 e se todos são caracteres do tipo numérico. Possivelmente pode-se fazer essa checagem de alguma forma no banco de dados (não sou profundamente conhecedor do Postgres). No entanto sei que, geralmente, um banco de dados está associado a alguma aplicação que fornece uma interface para entrada dos mesmos (linguagens tais como java/javaEE/JSP/JSF, C/C++, php, python etc). Sendo assim, poderia se considerar fazer essa checagem (validação) no programa, caso a interface ainda esteja em desenvolvimento. Acho que nem tudo precisa ser rigorosamente implementado no banco de dados. Por exemplo: validação de CPF pode ser colocada no próprio BD (já vi um código assim na internet), mas acho mais fácil implementar isso na aplicação
Em 24 de janeiro de 2017 22:48, Leandro Guimarães Faria Corcete DUTRA < [email protected]> escreveu: > Le mar. 24 janv. 2017 à 23:12, Marcio A. Sepp < > [email protected]> a écrit : > >> Peço desculpas, mas não consegui organizar o e-mail direito. >> > > Acontece. Só procure pensar em quem lerá. > > > O caso eh que tem um cadastro de itens onde o código do item pode vir com >> 5 ou com 7 dígitos. Quando o item eh de um determinado importador ele tem 5 >> dígitos e qdo eh do mercado interno ele tem 7. >> Exemplo d código d produto com 7 dígitos: 0012345. >> Exemplo d código d produto com 5 dígitos: 01234 >> >> O que eh melhor (ou mais correto a fazer neste caso): >> 1) crio um campo para identificar a origem (importador "xxx" ou mercado >> interno) e junto esse campo na chave. A chave seria composta pelo campo >> origem e o campo código do item (neste caso integer); >> > > Essa é uma solução interessante. Se o zero à esquerda não for > significativo, e se não for o caso de separar esse cadastro em duas > entidades, pode ser ideal. > > > 2) crio o campo código como sendo varchar(7); >> > > Se os zeros à esquerda forem significativos, por exemplo se essa lógica > que delineaste acima for não apenas incidental mas uma regra de negócio, > pode ser a solução ideal, já que nesse caso o atributo de origem se > depreenderia do tamanho da seqüência de caracteres. > > Mas, pensando melhor, do jeito que explicaste, parece ser uma > regra de negócio. Se não houver diferenças noutros atributos (atributos > preenchidos ou NULL de acordo com a origem, ou de significados dependentes > da origem), eu creio que manteria como seqüência de caracteres. Mas, se > houver diferenças noutros atributos, talvez fosse o caso de normalizar. De > qualquer maneira, sendo uma regra de negócio, um atributo origem explícito > seria redundante com o tamanho do código, não? Independente dele ser > armazenado como número ou seqüência de caracteres. > > É bem difícil aconselhar modelagem por correio eletrônico, costuma > faltar informação. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:[email protected] > +55 (61) 99302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:[email protected] > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Jorge Luiz
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
