2007/9/7, Leonardo Cezar <[EMAIL PROTECTED]>: > On 9/6/07, Leandro DUTRA <[EMAIL PROTECTED]> wrote: > > > > Então não entendi nada mesmo. Em qual situação os domínios SQL > > > contribuiriam no contexto da ferramenta em questão? > > > > Se eu entendi direito a ferramenta e lembro bem — já fazem algumas > > semanas que a vi — é um diagramador ER. Definem-se os DOMAINs, os > > quais se usam para definir as tabelas já com os tipos e restrições de > > atributo associadas, mantendo-se a consistência do modelo de dados. > > Você não entendeu. A "ferramenta em questão" é aquela enviada no link inicial.
Acho que entendi, mas não fui claro: o 'definem‐se' acima refere‐se ao que se faz em sistemas semelhantes. > > Mas que são uma aproximação razoável embora tosca de domínios > > definidos pelo usuário. > > Discordo com a idéia que nomear tipos agreguem valor à documentação. Minha experiência com Oracle e MySQL, que não suportam DOMAINs, me diz que agregam sim — a tendência é o mesmo tipo receber nomes diferentes em porções diferentes do modelo, confundindo quem o lê e usa e levando a inconsistências. Lembre‐se que não é só nomear, mas manter restrições de integridade consistentes também. > > Lembrando que um domínio é uma lista de valores aplicáveis a um > > atributo, variável &c, um DOMAIN te permite, via CHECK CONSTRAINT, > > definir uma tal lista ou aproximação dela. > > 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. > bastaria então > utilizar-se da cláusula CHECK, nativamente fornecida pela SQL. Não bastaria — primeiro, porque aí tem‐se de definir a restrição CHECK para cada atributo diretamente, em vez de apenas uma vez no DOMAIN; segundo, porque isso geralmente leva a inconsistências, em que nalguns atributos esquece-se a restrição ou i implementa‐se‐a incorretamente. Aliás, para dar um exemplo positivo além dos negativos costumeiros, estou lidando com um sistema Oracle diagramado em CA ERWin onde de fato não se usaram domínios, mas o simples fato de se poder nomear as restrições centralmente já ajudou a manter consistência, embora não perfeitamente. E olha que é um sistema herdado onde o que mais herdei foi dor de cabeça… > Mas e as contenções sobre operadores? Desculpe, não entendi ― pode explicar, por favor? > > 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… Contenção tem dois sentidos, luta (vide http://priberam.pt./dlpo/) e restrição. Acho restrição mais preciso, portanto. Além disso, contenção conota resistir mais que restringir. > > Como não? A gente documenta que determinados atributos são todos > > definidos no mesmo tipo, e tem restrições e comentários associados… > > ... e logo estará executando comparações de código de produtos com > identificadores de clientes, já que nenhum (???) SGBD implementa > *restrições* sobre operadores. > > e.g.: > DOMAIN cpf AS integer CHECK [...] > DOMAIN id_produto AS integer CHECK [...] > > TABLE clientes(cpf cpf, ...) > TABLE produto(id_produto id_produto, ... ) > > SELECT cliente.cpf =produto.id_produto; > > Embora logicamente não deva retornar nada, é conceitualmente inaceitável. 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. > > Aliás não tem ferramenta proprietária que se preze que não implemente > > — CA ERWin, IBM Data Architect, Embarcadero ER Studio… > > Infelizmente sou meio pobre, proprietariamente falando, mas me diga: > Estas ferramentas implementam domínios em sua totalidade? Se sim, como > estes resolvem a implementação física do modelo?? Claro que não — não teriam como se nem o padrão ISO SQL o faz nem o permite. 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). > Ainda não consegui visualizar onde os domínios vão ajudar, já que se > restringem apenas a tipos nativos. Acho que estamos precisando conversar isso em torno de uma cerveja ou guaraná… > Penso que uma forma mais elegante de se contornar a dificuldade da > SQL, seja utilizando tipos e operadores definidos pelo usuário, > característica que sobra em alguns SGBDs e falta em outros, mas não > sei como documentar essa característica nas ferramentas atuais. 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. 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. -- +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
