Lívia, Também prefiro usar as "tabelas de domínio", acho enumerator legal, mas devemos ser comedidos ao utilizar. Como trabalho em uma grande corporação que trata os dados como corporativos, temos a mania de tabelar quase tudo, aqui existe uma área de administração de dados que não deixa passar muita coisa.
Aqui as tabelas são compartilhadas entre as aplicações e para evitar o retrabalho centralizamos os dados e evitamos o máximo o uso de enumerator, arrays etc. Se precisamos preencher um "combobox", preenchemos a partir de uma ou mais tabelas. Imagine se o conteúdo estivesse em um enumerator? Teríamos que controlar isso em todas as aplicações. Outra coisa: o enumerator é unidimensional, ou seja, sua definição tem uma carga semântica que, se existir, fica explicita em outro lugar do projeto, talvez só na cabeça do analista. Atc, 2008/10/13 William Leite Araújo <[EMAIL PROTECTED]> > Nunca medi desempenho quanto a esse tipo de abordagem, mas já tive que > implementar ambas soluções. > > Tenho preferência pelas tabelas porque qualquer tipo de decisão de > acrescentar alguma coisa no tipo (agora o "chefe" quer que tenha uma opção > "Hermafrodita" no sexo) nada no sistema precisa ser alterado. > > 2008/10/8 Livia Santos <[EMAIL PROTECTED]> > >> Olá pessoal, >> >> Entrei nessa comunidade após participar da PGCon 2008, aqui na Unicamp >> (parabéns aos organizadores e envolvidos!). >> >> Aqui ainda uso DB2 devido aos sistemas legados e uma decisão da diretoria. >> Mesmo assim, acredito que vocês possam me ajudar num problema conceitual. >> Caso essa não seja a lista indicada, por favor desconsiderem a mensagem (e >> se puderem, me indiquem alguma outra lista :D ). >> >> Bom, a dúvida (briga) que temos com a pessoa responsável com os dados aqui >> é que nós sempre criamos tabelas, mesmo aquelas que convencionamos chamar de >> apoio Por exemplo, tabela de sexo, que só tem 3 registros (Feminino, >> Masculino, Indeterminado), ou tabela de tipos, tabela de profissões, tabela >> de níveis de escolaridade. São aquelas tabelas que quase nunca mudam. >> >> A "dona dos dados" acredita que devemos usar enumerações (hoje eles usam >> isso num ambiente mainframe ou na própria aplicação) e na base deve ser >> criado um campo com check constraint para aceitar apenas determinados >> valores. >> >> Nós achamos que os joins para esse tipo de tabela são tão mínimos em >> esforço que não compensa criar enumerações ou qualquer outro tipo de >> estrutura para lidar com esses dados. >> >> Gostaria da opinião de vocês: em suas experiências, quais foram as >> soluções utilizadas para esse tipo de problema? Será que joins nesses tipos >> de tabela realmente sobrecarrega o banco? Existe algo para otimizar esse >> tipo de pesquisa. >> >> Hoje ainda usamos DB2, mas existe a possibilidade de fazermos algumas >> coisas em PostgreSQL. Mas essas dúvidas permanecerão independente do banco >> (pelo menos aqui). >> >> Obrigada, >> >> -- >> Lívia Silva Santos >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > William Leite Araújo > Analista de Banco de Dados - QualiConsult > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Forte abraço, Aldemir Vieira
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
