Gerando Arrays Profundos: Raso a Profundo, Profundo a Raso ou Má Idéia?

5

Estou trabalhando em uma estrutura de matriz que será usada como fonte de dados para um modelo de relatório em um aplicativo da web.

Os dados vêm de consultas SQL relativamente complexas que retornam uma ou mais linhas como matrizes associativas unidimensionais. No caso de muitos, eles são transformados em matriz bidimensional indexada.

Os dados são complexos e, em alguns casos, há muito disso. Para salvar viagens ao banco de dados (que são extremamente caras neste cenário), estou tentando obter todos os arrays básicos (dados de banco de dados brutos de dimensão 1 e 2) e colocá-los condicionalmente em um único array profundo de cinco níveis. Organizar os dados no PHP parece ser uma idéia melhor do que usar as instruções where no SQL.

Estrutura da matriz

    Array of years(
            year => array of types(
                            types => array of information(
                                                total => value,
                                                table => array of data(
                                                                index => db array
                                                                    )
                                                        )
                                )
                )

Minha primeira pergunta é: essa é uma má ideia. Matrizes como essa são apropriadas para essa situação?

Se isso funcionasse, como devo proceder para preenchê-lo? Meu pensamento inicial foi superficial a profundo, mas quanto mais eu trabalho nisso, mais eu percebo que seria muito difícil abstrair as condicionais que determinam onde cada item vai na matriz. Assim, parece que a partir dos dados mais profundamente aninhados pode estar a abordagem que devo seguir.

Se isso é abuso de matriz, que alternativas existem?

Editar

Eu fui em frente com esta abordagem, aprendendo e mudando as coisas como eu fui. Mas acabei com um array final similar. O que eu aprendi em relação ao enigma superficial para profundo foi isso.

Entrei no processo pensando nas matrizes externas como o maior de um conjunto de xícaras, contendo multidões de xícaras menores que por sua vez continham outra multidão de copo menor até o último conjunto que em minha mente era água (sendo este o matriz indexada de valores do banco de dados). Arrays não são copos ...

A ideia desmoronou quando eu comecei legitimamente a desenhar as estruturas da matriz e descobri que a base dessas matrizes, as xícaras cheias de água que eu imaginara, representava muito mais dados do que aquelas grandes xícaras. Isso me levou a ver essas matrizes profundamente aninhadas como torres, com os dados indexados representando uma base de tipos, afinando até a ponta, que era a matriz contendo.

A partir daí, descobri que a melhor maneira de processar os dados era reunir os dados de fundo, conectá-los à próxima camada e subir a torre conectando cada camada à próxima camada.

Não tenho certeza se estou certo, mas sinto que entendo mais as matrizes agora do que antes.

E, definitivamente, ainda não tenho certeza se essa é a melhor solução.

    
por Will Meldon 21.11.2012 / 22:18
fonte

3 respostas

1

Não sei se entendi o problema que você está tentando resolver. Você pode nos dar uma amostra de consulta SQL?

  • Você está participando de cinco tabelas diferentes usando relações 4+ para renderizar uma única consulta? Se assim for, eu recomendo tentar um ORM. Qualquer boa solução MVC para o seu idioma (por exemplo, CodeIgniter ) deve ter algo para você.
  • Você está tentando carregar o conteúdo completo de cinco tabelas na memória (no servidor PHP ou no cliente) para que você possa se juntar a elas à vontade assim que o usuário selecionar algo que descreva a união necessária? Se assim for (e assumindo que não há tantos dados), então você pode querer experimentar um ORM frontend baseado em Javascript, talvez usando algo tão simples como o Backbone. js .

Devo admitir que não estou inteiramente certo de que alguma das sugestões acima seja apropriada para o seu problema, conforme descrito. Eu adoraria mais detalhes.

    
por 04.12.2012 / 03:50
fonte
0

Como você dimensiona suas matrizes internas? Eu acho que você não sabe de antemão o tamanho de cada um deles.

Eu vejo três soluções possíveis:

  1. Se o banco de dados não for alterado com frequência, mas sim lido, você poderá indexar suas tabelas (internamente ou com o Lucene). Isso trará mais desempenho.

  2. Use uma B-Tree, porque ela também é amigável em relação ao "swap" do disco rígido (eu acho que você não quer manter tudo na memória).

  3. uma combinação de 1 e 2.

por 20.12.2012 / 12:01
fonte
0

Revelação completa: estou vindo de mais de um plano de fundo JSON, mas projetar com literais de objeto e matrizes é praticamente o mesmo problema.

Eu projetaria com os seguintes objetivos:

  • Sempre faça uma estrutura de dados o mais superficial possível até começar a duplicar desnecessariamente os valores em todo o lugar (ou seja, aplainar demais ao ponto de duplicar desnecessariamente conjuntos inteiros para teclas / partições diferentes). As pessoas tendem a aninhar as coisas apenas por causa do aninhamento ou porque parece que há muitos itens em um conjunto. Tudo o que importa é saber se tudo pertence a uma determinada categoria. Nota: com conjuntos de dados menores, às vezes achatando tudo para simplificar, é uma ótima ideia, mas isso não soa como um desses cenários.
  • Se a ordenação dos elementos não for crítica e um conjunto tiver um valor exclusivo confiável útil como chave, converta-o de indexado para associativo a esse valor exclusivo como chave. Ou seja, não dê um loop em algo e verifique o valor correto se você puder fazer referência direta pelo nome. Isso pode reduzir drasticamente a complexidade da sua funcionalidade de acesso.
  • No flipside, prefira indexar quando vários itens sem valor único confiável forem possíveis ou a ordem em que você vai percorrer esses itens é importante (talvez esse segundo ponto seja menos crítico no PHP).
  • Não formata condicionalmente. Aquela coisa com 1D quando é apenas um item ou indexado em 2D quando é muitos soa como uma receita para uma lógica sem sentido para mim. Loop sobre um array de um elemento, metade ou mesmo 75% do tempo, é muito menos crufty / frágil.
por 19.01.2013 / 20:14
fonte