Persistência de Objetos

Olá Johnny.

Esse é o trabalho dos SGBD's - Sistemas Gerenciadores de Banco de Dados. Através de uma linguagem própria - SQL, eles realizam consultas nos objetos armazenados, retornando as informações no formato solicitado pela aplicação, realizando junções de objetos (joins), cálculos (sum, avg), contagens (count) etc.

Sendo assim, se você tem um objeto Cliente persistido em sua base de dados, e sua aplicação solicita apenas o código de cada cliente, você envia essa instrução por SQL e o SGBD busca apenas o que for necessário para satisfazer sua aplicação.

Olá Luis!

Primeiramente quero agradecer pela contribuição. Acho que não fui muito claro na minha pergunta. Já utilizo banco de dados para fazer a inserção, atualização e seleção de dados, o que estou buscando é abstrair os comandos SQL através de uma "interface" em PHP. O que busco alcançar é o seguinte:

<?php

$Clientes = new Clientes;
$Clientes->total( 30 );
$Clientes->obter();

$Template = new ClientesView;
$Template->impLista( $Clientes );

para retornar

<ol>
  <li>Nome Cliente 1</li>
  <li>Nome Cliente 2</li>
  <li>Nome Cliente 3</li>
  ...
</ol>

Lógico que haverá código SQL dentro do objeto Clientes, mas o ponto no qual quero chegar é se imaginarmos que a tabela de clientes tiver 15 colunas, serão criados 30 objetos Clientes contento os valores das 15 colunas e talvez só utilize os dados de 2 delas. Selecionando apenas 30 clientes talvez não haja uma queda de performance muito grande, mas se imaginarmos um relatório com todos os clientes cadastrados isso pode ficar muito pesado não acha?

Também acho estranho criar um método para informar quais colunas desejo obter e receber uma lista de objetos Clientes incompleta, isso não parece errado?

Ola johnny, acho que entendi o que voce quis dizer.

Existem alguns padrões de desenvolvimento chamados VO (Value Object) e DTO (Data Transfer Object), depois da uma pesquisada, acho que pode te ajudar.

VO, ou DTO, são "Objetos" formados de acordo com a sua importância no contexto da aplicação. No seu caso, Você até poderia ter um Objeto Cliente com os 15 atributos, mas também poderia ter um Objeto clienteVO que possui apenas os atributos que têm importancia na sua aplicação. No caso do DTO, tem mais a ver com a transferencia desse objeto cliente, por exemplo: Se você possui um webService que precisa devolver apenas dois campos do cliente em XML (por exemplo, nome e usuario), você pode criar um objeto clienteDTO que possui apenas os dois campos exigidos pelo serviço.

Quanto ao acesso e recuperação dos dados, Existe uma camada de aplicação chamada DAO* [edited](Data Access Object), que basicamente possui as funções implementadas que seus objetos necessitam para serem recuperados da base de dados, sejam eles VO, DTO's, etc. Então você poderia ter uma função getClienteVO com a consulta apenas dos atributos daquele objeto, sem problema nenhum.

Mas basicamente, esse tipo de design não tem muita relação com desempenho, acredito que consultar 5.000 clientes com 2 colunas ou 15 colunas não influencie no desempenho, o que influencia no desempenho das consultas geralmente são os filtros, ordenações, junções, e etc.

Espero ter ajudado de alguma forma []'s

Olá Luis!

Não conhecia os padrões mencionados e sua explicação já me ajudou bastante, vou seguir seu conselho e pesquisar mais sobre o assunto. Obrigado.