Obrigado Flavio. -----Mensagem original----- De: [email protected] [mailto:[email protected]] Em nome de Flavio Henrique Araque Gurgel Enviada em: segunda-feira, 10 de outubro de 2011 13:13 Para: [email protected]; Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Duvida com Modelagem: Array Multidimensional ou campos
> Estamos enfrentado um dilema aqui na equipe, eu estou propondo o uso > de array multidimensional para criar a seguinte situação: > > Requisito: "Criar um repositório onde constará as localidades e os > ciclos de visitas sendo composto de até 4 semamas e cada ciclo poderá ter 7 dias". > > Resumo da ópera: Ciclo - pode ser de 1 a 4 ou todos, sendo que cada um > dele poderá ter até 7 componentes, assim > Ex.: > Ciclo 1 - D S T Q Q S S > ... > Ciclo 3 - T Q > ... Problema comum por aí. > Cenário: > Ambiente de teste : PostgreSQL 8.4.1, compiled by Visual C++ build > 1400, 32-bit No seu cenário o desenho do banco independe da versão. Mas... sugiro atualizar para a última versão da série, sempre, no seu caso 8.4.9. Tem centenas de bugs corrigidos. > > create table foo ( > localidade varchar(60), > ciclo int [][]); > > Dúvida: > > Alguns programadores <OP, Python, C++> daqui são contra trabalhar > com array e mais ainda com array multimensional, porque dizem dentre > outras coisas que não está em conformidade com SQL (92,99,2003), não é > indexável, difícil de se manipular etc. Realmente buscas em arrays podem ser não indexáveis, mas o resto dos argumentos é pura preguiça de programador. > Do meu ponto de vista simplista, não vejo dificuldades em trabalhar > com arrays mas eles argumentam o contrário na hora de dedilhar linhas > de códigos. > Eles propõem criar a entidade foo com 32 campos (localidade, > ciclo1,ciclo2..., d1,s1...) <loucura!?>, daí eu juntei a equipe e > fomos para discussão com a chefia para ver o que podemos fazer. > Argumentos em pauta, o que vocês acham? > Será que eles estão com razão e devemos esquecer arrays? Com duas ou três tabelas relacionadas você normaliza a "loucura" que você citou acima, com extremos ganhos em performance, consumo de espaço em disco, entre outras vantagens da normalização. Assim, por exemplo: Tabela 1: ciclos Colunas: id_ciclo, nome_ciclo Tabela 2: localidades Colunas: id_localidade, nome_localidade Tabela 3: visitas Colunas: id_ciclo, id_localidade, dia_semana Relacionamentos: visitas.id_ciclo -> ciclos.id_ciclo visitas.id_localidade -> localidades.id_localidade Restrições (com índices implícitos e prontos para usar): ciclos_pk: ciclos.id_ciclo localidades_pk: localidades.id_localidade visitas_pk: visitas.id_ciclo + visitas.id_localidade Mostre isso aos seus programadores e veja se eles não vão gostar mais. E você como DBA também deveria gostar mais. []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
