On 9/8/07, Leandro DUTRA <[EMAIL PROTECTED]> wrote: > Lembre‐se que não é só nomear, mas manter restrições de integridade > consistentes também.
Vou precisar rever meus conceitos do termo integridade também ... Os domínios conseguem de fato manter integridade sobre as operações? > > Se a idéia fosse definir um "domínio de valores" > > Existe outro tipo de domínio? Desculpe, não estou sendo irônico, é > que sou ignorante em Matemática mesmo. Corrigindo: Se a idéia fosse *apenas* definir um [...] > > Mas e as contenções sobre operadores? > > Desculpe, não entendi ― pode explicar, por favor? As restrições sobre operações. AFAIK, domínios deveriam restringir comparações ilegais entre entidades, para impedir irregularidades nas operações. Em outras palavras especificando a cláusula OPERATOR (vide Tutorial D || Introduction DB Systems) na construção do dominio. > > > Aliás intereßante — você usa 'contenção' como tradução de CONSTRAINT? > > > Sempre usei restrição… > > > > Hmm ... verdade, acho que a tradução literal é restrição, embora > > contenção parece semanticamente correto. > > Interessante… esta é outra discussão, mas não costumo resistir a > discussões, então… Pensei a mesma coisa, mas ... > Contenção tem dois sentidos, luta (vide http://priberam.pt./dlpo/) e > restrição. Acho restrição mais preciso, portanto. Contenção: Ato de conter(-se); Conter: Manter dentro de certos limites; Origem: Novo Aurélio Século XXI - Ed. Nova Fronteira - 85-209-1010-6 Por curiosidade em latim parece significar exatamente a mesma coisa que restrição. ;-) > Além disso, contenção conota resistir mais que restringir. Por que? Alguma regra? Todo mundo usa? Não que esteja querendo ser chato, mas esse tipo de entendimento é importante inclusive para o nosso VP. > Não entendi o que você quis dizer, creio — o que leio nesse exemplo é > uma burrada do programador onde DOMAINs não ajudam nem atrapalham > diretamente, mas, pensando num contexto maior, ajudam a documentar > para o programador que ele fez bobagem. A "burrada" não foi o programador quem inventou, foi a IBM quando instituiu a SQL. O que tentei demonstrar, de forma infeliz, foi que domínios verdadeiramente relacionais seriam uteis para inibir "burradas" do tipo comparações ilegais entre tipos (leia-se dominio). Alias, diga-se de passagem, sequer existe algum tipo de restrição para comparação entre tipos diferentes (e.g.: float, int, numeric ...). > O que estamos falando é sempre no contexto de documentação e > consistência dentro dos limites de documentação, diagramas ER e > DOMAINs SQL, não com verdadeiros tipos (vulgo tipos abstratos de dados > — ADTs ―, ou tipos definidos pelo usuário — UDTs). Então continuo sem saber (não se preocupe se não quiser insistir) qual o propósito e os limites do uso de Domains SQL na documentação, uma vez que a única característica que eu -- em minha assumida ignorancia em tal assunto -- imagino que exista nos dominios, que é manter a integridade entre valores e operações, são completamente desconsideradas nas versoes ISO SQL. Pra ser sincero concordei quando vc citou a questão do erro na hora de se construir um CHECK para cada atributo. Isso seria, no mínimo "burro", mas existem UDTs pra solucionar isso, e normalmente eu resolvo assim e de quebra ganho composição de valores, abstração e (adivinha!) integridade sobre meus operadores, salvo algo realmente simples. Já na questão da documentação (através do nome intuitivo do dominio), confesso que uma boa dicionarização resolve o caso, e/ou UDTs :-). > Acho que estamos precisando conversar isso em torno de uma cerveja ou guaraná… De fato, precisei de um momento como esse com meu professor da disciplina de Banco de dados da faculdade para entender e continuar discordando de certos conceitos :-), vide discussão OODBM. > Sobra mesmo? Eu nem sei de nenhum que tenha isso de forma elegante e > utilizável por pobres ignaros como eu… fora o meu exemplo de sempre, o > Alphora Dataphor que infelizmente é proprietário e não trabalha com > nosso caro Dumbo e &c & tal. Qual o problema com a implementação do PostgreSQL em relação a UDT ?? > Aliás, se me permitem o ensejo de um fora‐de‐tópico, os arquitetos do > Dataphor saíram da Alphora e, enquanto mantém o suporte ao Dataphor > como consultores à Alphora, planejam construir um produto sucedâneo > alternativo e livre, talvez ainda mais relacional. Isso de fato é interessante. Referencias?? Um abraço! -Leo -- Leonardo Cezar http://www.postgresql.org.br _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
