> 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
