Conception de classes d'accès à une BDD

Bonjour à tous !

J'ai un petit problème de conception qui me vexe, quelqu'un pourrait-il m'aider avant que je ne perde toute confiance en moi ?

J'ai du mal à concevoir mes classes d'accès à une base de données.

Il s'agit d'une petite application web essentiellement destinée à manipuler (CRUD) une unique structure de données stockée en base. Cette structure, "Edifice" est un peu compliquée : un "Edifice" comprend N "Batiment" comprenant eux-mêmes N "Elevation", N "Niveau" et 0 ou 1 "Logis". De plus, ces différentes ramifications de l'"Edifice" possèdent chacune des champs multivalués à renseigner grâce à des tables de thésaurus.
Bref, la structure est claire et plutôt bien définie, mais il y a un grand nombre de relations 1-plusieurs et donc de tables de liaison.

Une approche ORM artisanal me parait trop couteuse et multiplierait les requêtes de façon délirante, j'ai l'impression. A moins de pouvoir faire autre chose que requêter pour chaque Edifice les Batiment, pour chaque Batiment, les Elevation, etc.

Du coup, j'envisage de coder différentes méthodes pour charger les Edifice plus ou moins intégralement, selon les besoins, pour tel ou tel affichage. Par exemple, la liste des Edifice montrerait seulement quelques infos de base à propos de chacun des Batiment fils, ce que je peux ramener en une ou deux requêtes SQL, au lieu de N + 1 requêtes (N étant le nombre d'Edifice).

Si j'adoptais cette solution, il faudrait encore que je m'éclaircisse comment construire mes objets, plus ou moins remplis...

Quelqu'un a-t-il déjà été confronté à ce genre de problème ? Ce petit exposé est-il compréhensible ?

Merci pour vos réponses !!! =)

PS : le projet est à pondre en PHP, avec le Zend Framework éventuellement. Venant du monde Java, je patauge un peu ^^

Bonjour,
J'ai eu un problème semblable au tien: une donnée composée de n autres données elles-même composées de n autres autres données... Le code sur lequel je devais intervenir lisait les données linéairement, une table après l'autre, construisait les différentes strates d'objets et les reliait avec plus ou moins de bonheur entre eux. Bilan des courses: des chargements pouvant dépasser l'heure.
La solution que nous avions adopté a été de faire des méthodes de chargements plus intelligente en allant chercher les données jointées comme il faut pour obtenir tout dans un minimum de requêtes, quitte à gérer des objets 'partiels' dont on va chercher les infos uniquement au moment où on en a besoin. Donc à mon sens, c'est à privilégier. Les exemples typiques sont ceux où tu as des données qui conditionnent ton affichage et d'autre pas. Alors pourquoi charger celles-ci?
Par contre c'était dans le monde du C/C++, donc pour une implémentation spécifique PHP, à voir dans les forums spécialisés une fois ta conception fini ;-)