Discussion :

[voyageur]

Bonsoir,

Je dois developper un logiciel client/serveur de gestion qui fais des traitement ( ajout/modification/suppression) sur une base de données Sql server.
J'essaye de reflechir pour concevoir au maximum d'une facon objet pour la modularité du code coté applicatif.

Par exemple je veux mapper toutes mes lignes qui sont dans ma base de données pour pouvoir les manipuler sous forme d'objet dans mon application.
Comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
ligne 1 de la table --> Personne = new Personne (champs1, champs2 ......)
ligne 2 --> Personne = new Personne (champs1, champs2 ....)
..........................................................
ligne n --> Personne = new Personne (champs1, champs2 ....)

Le probleme en faisant de cette facon je risque de consommer enormement de memoire si ma base de donnees est volumineuse.
1000 000 lignes = 1000 000 d'objet en memoires !!!!

J'aimerai donc savoir si c'est une bonne methode de conception, si non comment procederiez vous pour garder au maximum l'esprit objet du code applicatif ?

merci

[Fabien Celaia]

Le mappage pur objet, ca part vite à veau-l'eau !
imaginez l'inmpact qu'aura une grosse table sur vos instantiations...

[voyageur]

Quel sont vos arguments ?
Avez vous des experiences sur ces technlogies ?
Quel sont vos conclusions sur l'emploi de ces technlogies de mapping objet/relationel tel que hibernate ?

merci des reponses.

[fsmrel]

Bonjour Voyageur,

Personnellement, je n’ai pas d’expérience dans cette histoire de mapping Objet/Relationnel. A défaut, au-delà des techniques, la remarque de Fadace me paraît pleine de bon sens. Commencer par vouloir charger en mémoire un million d’objets (un milliard demain ?), occupant chacun disons mille ou dix-mille ou cent-mille octets, pour finalement n’y rechercher peut-être que quelques uns d’entre eux est une approche ni viable ni raisonnable. Pourriez-vous exposer les motifs strictement fonctionnels (et non pas techniques, du genre "impedance mismatch") vous conduisant à utiliser une approche si peu économe des ressources ?

[voyageur]

Je ne cherche pas a avoir des performances à l'extreme , c'est une petite base de données d'environ 50 tables avec au maximum 20 champs par tables ( de int et de string), et 15 utilisateurs.
En utilisant le mapping relationnel/objet je pense economiser enormement de temps de developpement pour me consacrer plus au fonctionnel.

De plus la maintenance et l'evolutivité est beaucoup plus facile avec des objets.

[fsmrel]

Bonsoir Voyageur,

Puisque vous êtes sûr de votre fait, pourquoi poser des questions ?

Par ailleurs, votre discours n’est pas très consistant : vous parlez d’abord de gérer des tables d’un million de lignes, ce qui commence à devenir intéressant, puis finalement vous dites que votre base de données est une petite base, mais sans en préciser pour autant la volumétrie en termes de lignes, ou mieux, de gigaoctets. Personnellement, si je suis face à 50 tables de cent millions de lignes chacune, je suis un peu plus stressé que face à 50 tables de 1000 lignes.

Peu importe. Je dirai quand même que le but de la manoeuvre n'est effectivement pas d'avoir des "performances à l'extrême", pas plus que développer en un temps record n’offre d’intérêt, sinon financier ou sportif. J'espère simplement pour vous que le résultat sera valide et pérenne. Combien ai-je vu de projets développés très vite, mais bâtis en paille plutôt qu’en pierre et ne supportant pas l’épreuve du terrain et du temps...

Good luck, et n’oubliez pas la 5e forme normale, même si le mapping relationnel/objet ne vous est en l’occurrence d’aucun secours...

[Yanika_bzh]

bonjour,

j'approuve ce que dit fsmrel.

J'aimerai bien savoir comment vous allez gérer la cohérence de vos données (entre celles en base et celles instanciées).
Vous pouvez tout aussi bien utiliser l'objet sans avoir a instancier toutes vos lignes de tables (interfacage de fonctions nécessaires à votre application).

Bon courage

[voyageur]

Bonsoir Voyageur,

Puisque vous êtes sûr de votre fait, pourquoi poser des questions ?

Par ailleurs, votre discours n’est pas très consistant : vous parlez d’abord de gérer des tables d’un million de lignes, ce qui commence à devenir intéressant, puis finalement vous dites que votre base de données est une petite base, mais sans en préciser pour autant la volumétrie en termes de lignes, ou mieux, de gigaoctets. Personnellement, si je suis face à 50 tables de cent millions de lignes chacune, je suis un peu plus stressé que face à 50 tables de 1000 lignes.

Peu importe. Je dirai quand même que le but de la manoeuvre n'est effectivement pas d'avoir des "performances à l'extrême", pas plus que développer en un temps record n’offre d’intérêt, sinon financier ou sportif. J'espère simplement pour vous que le résultat sera valide et pérenne. Combien ai-je vu de projets développés très vite, mais bâtis en paille plutôt qu’en pierre et ne supportant pas l’épreuve du terrain et du temps...

Good luck, et n’oubliez pas la 5e forme normale, même si le mapping relationnel/objet ne vous est en l’occurrence d’aucun secours...

Je demande juste des conseils et une direction, je suis loin d'etre expert dans le domaine.
Ma base contient 50 tables avec au plus 100 000 lignes par tables ( je n'ai pas regardé la volumetrie en terme de gigaoctets ).
fsmrel, j'aimerai avoir egalement votre avis sur les regles de conception metiers, est t'il preferable de les coder coté applicatif ou laisser le SGBDR les gerer ( triggers, contraintes referencielles, procedures stockées ) ?

[fsmrel]

[

Ma base contient 50 tables avec au plus 100 000 lignes par tables (je n'ai pas regardé la volumetrie en terme de gigaoctets ).

Faites les calculs. Même si au niveau de la conception ça n’est le plus urgent, ça revête une grosse importance par la suite et ça oriente votre prototypage (tests significatifs avec des brouillons des transactions que vous subodorez les plus utilisées, en consultation et en mise-à-jour et test de performance des traitements batch, des sauvegardes, réorganisations et autres unload/reload des tables).

j'aimerai avoir egalement votre avis sur les regles de conception metiers, est t'il preferable de les coder coté applicatif ou laisser le SGBDR les gerer ( triggers, contraintes referencielles, procedures stockées ) ?

Je rougis de confusion quand je compare les algorithmes sur lesquels je m’appuyais et ceux qui sont mis en œuvre par mon SGBDR (DB2 for Z/os), lequel est incomparablement plus raffiné et percutant à ce sujet. En plus, je plains ceux qui doivent maintenir le code développé par leurs petits copains, lesquels sont partis planter leurs choux ailleurs depuis belle lurette. Autrement dit, sous-traitez au maximum à votre SGBDR, mettez en un maximum sous le capot, pour éviter de devoir pédaler avec peine et d’être confronté à des anomalies. Par exemple, avec les contraintes référentielles, il n’y a pas photo, si on les programme soi-même, quoi qu’on fasse à un moment donné elles sont violées.

Je vous conseille de réfléchir à partir d’une discussion ouverte par Franck_P, "SI & SGBD : comment/où gérer les règles métier ?"
http://www.developpez.net/forums/sho...d.php?t=252568

[voyageur]

Bonjour,

Finalement j'ai abandonné le mapping objet/relationnel, je me suis rendu compte au fur et à mesure que ca devenait ingérable.
Avec des relations entre tables par dizaines et des fichiers de mapping en n'en plus finir.
Je prefere rester prudent et utiliser le relationnel, avec le langage SQL qui me premet de faire tout ce que je veux rapidement et lisiblement

Le mapping objet/relationnel est à reserver sur les base de données peu complexes.

[fsmrel]

Bonjour Voyageur,


En tout cas, c’était bien d’avoir exploré le sujet. Peut-être Gyles pourra-t-il vous éclairer ? L’objet c’est son rayon. Par contre, l’objet/relationnel ne semble pas l’emballer outre mesure :

L'intégration de l'objet dans le relationnel répond à une demande et donc à un besoin. Je ne discuterai pas de l'intérêt d'intégrer l'objet dans le relationnel, je préfère conserver des produits qui soient spécialisé chacun dans son domaine, du relationnel pour le relationnel et de l'objet pour l'objet. Le relationnel étendu se veut être un pont vers les technologies objets.

Cf. http://www.developpez.net/forums/sho...d.php?t=266029
http://www.developpez.net/forums/sho...d.php?t=251004