Em 14 de outubro de 2011 16:55, Shander Lyrio <[email protected]> escreveu: > > Aí é onde quero chegar, a sigla do estado nada mais é do que um id > (intrínseco já que estamos acostumados). O mesmo para regiões, ao invés > de usar um id 1, 2, 3, usamos um NE, SE que é mais representativo.
Mas tem gente que acha que mesmo assim é preciso um "id_estado integer" (ou serial) como PK. > >> M e F podem não apenas ser mostrados ao usuário: eles não requerem um >> JOIN para saber o sexo. > > Os seus clientes, os meus clientes ou qualquer cliente? Não existe > verdade absoluta, e eu já tive cliente, Banco inclusive, que queria "M - > Masculino" no relatório. Obviamente isto não serve de nada, não agrega e > ainda gasta tonner, mas o cliente pagou para ser feito deste jeito. Ah, > já ia esquecendo, ele também pediu uma tela para cadastro de Sexos. Estou falando que sou contra uma tabela assim: CREATE TABLE sexo (id_sexo integer primary key, desc_sexo text); Mas não sou contra uma tabela assim: CREATE TABLE sexo (id_sexo char(1) primary key, desc_sexo text); Aqui um CREATE DOMAIN ou um CHECK poderia ajudar. Veja que no segundo caso, acima, o seu cliente poderia ser atendido perfeitamente sem a criação de uma chave artificial numérica e sua respectiva SEQUENCE. > Esse tipo de afirmação demonstra o maior defeito dos sistemas de hoje > em dia. Eles são feito por programadores para programadores e não para > usuários. Eu entendo da mesma forma que você disse, mas acredite quando > digo nem todos os usuários finais de sistema entenderiam. Nunca > subestime a ignorância de um usuário. A ignorância do usuário, por mais infinita que seja, deve afetar no máximo a UI -- nunca o modelo. Não aconselho ninguém a deixar que seus clientes interfiram na sua modelagem. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
