2007/9/10, Leonardo Cezar <[EMAIL PROTECTED]>:
> 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 ...
Estou usando aqui no sentido mais comum, creio.
> Os domínios conseguem de fato manter integridade sobre as operações?
Sim, de uma maneira muito simples: definem-se as restrições de
integridade (CONSTRAINTs) sobre os DOMAINs — NOT NULL, CHECK, mesmo
DEFAULT que não é uma restrição de integridade. Não lembro se cabe
FOREIGN KEY também.
> > > 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.
Correto — e é por isso que tento usar DOMAIN (palavra-chave ISO SQL),
não domínio (sentido matemático): porque o DOMAIN ISO SQL é apenas uma
aproximação grosseira dos domínios matemáticos. Mas assim como o
próprio SQL em relação ao modelo relacional, mesmo essa aproximação
grosseira é bem mais útil que nada.
> 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.
> ;-)
Que bom! :-)
> > Além disso, contenção conota resistir mais que restringir.
>
> Por que? Alguma regra? Todo mundo usa?
Me parece… pelo menos foi a impressão primeira que tive, e corroborada
por uma busca rápida no Google. Mas não leve a ferro e fogo.
> Não que esteja querendo ser chato, mas esse tipo de entendimento é
> importante inclusive para o nosso VP.
Vice‐presidente? ;-)
Fora a brincadeira, concordo em gênero, número e grau.
> > 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.
Claro, o SQL permite uma série de coisas que não deveria, e impede
muito que deveria permitir. Mas por enquanto, estamos condenados a
usá-lo da melhor maneira possível.
Me irrita um bocado quando vejo as pessoas fazendo malabarismos em
Java ou outras linguagens procedurais, duplicando trabalho &c quando
poderiam fazer as coisas mais simplesmente em SQL — é uma espécie de
patinho feio da programação, mas é útil e subutilizado.
> 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).
Claro.
> Alias, diga-se de passagem, sequer existe algum tipo de restrição para
> comparação entre tipos diferentes (e.g.: float, int, numeric ...).
Hm, na verdade o nosso elefante está ficando mais estrito, impedindo
operações que antes eram toleradas… o que ilustra como deve funcionar:
a restrição para comparação deveria ser implícita na própria definição
dos tipos.
> > 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.
Olha, talvez você tenha trabalhado com sistemas muito melhores
definidos que os meus — mas tenho casos legados de atributos VARCHAR
chamados de 'nume_qualquer_coisa', tenho coisas diferentes com mesmo
nome de atributo, o mesmo atributo com nomes diferentes, atributos que
numa tabela têm determinada restrição de integridade e noutras não
têm… em todas essas situações a disciplina de só definir atributos
sobre DOMAINs em vez de diretamente nos tipos de sistema teria
ajudado, e muito.
E lembre‐se, os nomes em si são importantes; até ajudam o programador
a ver o que é comparável ou não.
> 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 :-).
Você está falando do CREATE TYPE? Parabéns, nunca tinha visto ninguém utilizar.
Mas você cria um tipo para cada atributo?
> > 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 ??
Talvez só minha ignorância mesmo.
Aliás acabo de constatar que a implementação não é conforme ao padrão
— mas melhor que nada certamente!
Há algum tempo vi a documentação e me pareceu extremamente complicada.
Revi agora: ou fiquei menos burro, ou está mais simples mesmo. Mesmo
assim, não me pareceu prático o suficiente para uso generalizado;
talvez eu precisasse dum bom tutorial para ser iluminado.
Talvez você tenha exemplos melhores que a da documentação, com
restrições e tudo o mais? Ou realmente o caminho seria um combinação
de tipos e DOMAINs? Adoro como o ISO SQL confunde os conceitos… :-(
> > 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??
Sinto muito, só tenho por referência correspondência particular com o
Nathan Allan e os outros… a página deles (Database Consulting Group)
ainda não tem informações específicas.
--
+55 (11) 5685 2219 xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 5686 9607 ICQ/AIM: aim:GoIM?screenname=61287803
MSN: msnim:[EMAIL PROTECTED]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
