Discussion :

[champomy62]

Bonjour,

J'ai une base de données contenant plusieurs tables. Chacunes d'entre-elles contiennent environ 50 champs.

J'aurai voulu savoir si je dois créer autant de champs dans ma classe que j'en ai dans ma table ?

J'aimerai créer le pattern active record... Est-ce convenable ?

Convenable dans le sens, consommation mémoire...

Merci.

[tomlev]

Déjà, si tu as 50 colonnes dans chaque table, il faudrait peut-être envisager de revoir le modèle de données pour le rendre plus pratique à utiliser... tu as probablement beaucoup de données redondantes, ce serait plus propre en séparant en plusieurs tables avec des jointures.

D'autre part, si tu veux mapper tes classes sur les tables, oui, bien sûr, il faut autant de champs (ou plutôt de propriétés) que de colonnes, sinon comment accèderais-tu aux données de ces colonnes ?

Pour ce qui est de la consommation de mémoire, le pattern Active Record n'est pas intrinsèquement meilleur ou pire que les autres, tout dépend de la façon dont tu l'utilises...

[champomy62]

Merci de ta réponse.

Effectivement la base de données est très mal conçues...
Des tables qui contiennent énormement de champs avec des informations redondantes. Des tables qui n'ont pas de clés primaires, très peu de contraites étrangères et qui n'ont d'index que les clés primaires. Les types de données utilisés le sont à mauvais essient.

Le soucis est que je suis seul à maintenir ce logiciel ou le très peu de documentation ne m'aide pas... (3 personnes ont travaillé à temps plein dessus mais ne sont plus là...)
Et le temps imparti ne me permet pas de refaire certaines parties du logiciel... (SSII)

Merci.

[BenoitM]

Tu peux aussi creer d'autres classes et les imbriquées

Par exemple :
Creer la classe Adresse : string Rue, int CodePostale,string Ville, string Pays
Et la classe Personne avec : string Nom, string Prenom,Adresse Adresse

[Bluedeep]

Merci de ta réponse.

Effectivement la base de données est très mal conçues....

Dans ce cas, pourquoi veux tu faire matcher une table à une classe ?

Accessoirement, quand on a un modèle de données pourri et que le temps imparti ne permet pas de modifier le modèle physique, une solution peut être de rétablir un modèle (plus ou moins .... ) correct via des vues, et d'appuyer ton code exclusivement sur ces vues, sans toucher aux tables physiques. (d'ailleurs, c'est une recommandation valable même quand le modèle est "sain", ça simplifie beaucoup les évolutions).

[champomy62]

Oui, faire un héritage en quelque sorte...

[Bluedeep]

Oui, faire un héritage en quelque sorte...

Tu réponds à qui ? si c'est à moi, la réponse est "pas du tout".

[champomy62]

Dans ce cas, pourquoi veux tu faire matcher une table à une classe ?

Accessoirement, quand on a un modèle de données pourri et que le temps imparti ne permet pas de modifier le modèle physique, une solution peut être de rétablir un modèle (plus ou moins .... ) correct via des vues, et d'appuyer ton code exclusivement sur ces vues, sans toucher aux tables physiques. (d'ailleurs, c'est une recommandation valable même quand le modèle est "sain", ça simplifie beaucoup les évolutions).

Je souhaite etablir un lien entre une table et une classe pour créer une couche d'accès aux données...
Effectivement je n'avais pas pensé aux vues pour contourner le problème...

Tu réponds à qui ? si c'est à moi, la réponse est "pas du tout".

Oui je repondais à toi.
J'ai pensé à un heritage du fait que dans ta classe personne, tu avais un champ adresse. J'ai déduis ça trop vite.

Bluedeep, tu parlais de classe imbriqué, mais pour ma part sauf dans les exemples je n'ai jamais vu de programme en utilisé.. Dû certainement à ma petite expérience...

[Bluedeep]

Bluedeep, tu parlais de classe imbriqué,

non, c'est pas moi, c'est BenoitM.
Personnellement, je ne fabriquerais pas un modèle objet en fonction de ce que je trouve dans la base,mais en fonction de mes besoins métiers. Donc si je dois adapter le modèle de données sans toucher le modèle physique => vues.

[champomy62]

Oops, pardon !

OK, Je vais appliquer vos conseils. Pensez-vous qu'un livre sur les design patterns peut m'aider sur ce genre de problèmes ?

[Bluedeep]

Oops, pardon !

OK, Je vais appliquer vos conseils. Pensez-vous qu'un livre sur les design patterns peut m'aider sur ce genre de problèmes ?

Pour l'instant, c'est un problème sur le modèle de données. Commence par assainir la situation de ce coté.

A ce stade, les DP ne te seront d'aucun secours, puisque totalement hors du champs de la réflexion.

Après, why not .....

Je précise que je ne suis pas d'accord avec BenoitM ici, dont la proposition me semble relever un peu du cautére sur une jambe de bois.

[champomy62]

Ok je crée des vues.

Donc le nouveau code sera uniquement basé sur des vues et l'ancien code restera tel quel. Pensez-vous que c'est fiable sur le long terme étant donné que ma société souhaite investir sur ce logiciel ?

[BenoitM]

Je précise que je ne suis pas d'accord avec BenoitM ici, dont la proposition me semble relever un peu du cautére sur une jambe de bois.

Tu peux utiliser plusieurs techniques

Creer des vues pour simplifier le modele de la base de données
Creer des sous objets pour manipuler tes données métiers

---
Dans le cas que j'ai donnée Adresse n'est pas de l'héritage.
C'est un objet imbriqué.

Part contre tu peux utiliser l'héritage pour simplifier tes objets.
Exemple tu as une table Personne: Nom,Prenom,DateNaissance,NumeroNational,Telephone,Gsm,Rue,Code,Postal,Pays,Sexe,IdEtatCivil (Marié,Veuf,Cébibataire),...
Cette table ne me semble pas mal foutue donc pas vraimment l'utilité de la splitter part contre on pourrait imaginer une classe Personne avec Nom,Prenom,Adresse et une classe PersonneComplet qui dérive de Personne et qui contiendrait les champs manquant (sexe,etatCivil,téléphone,...)
car dans la plus part des écrans tu n'affiches que le Nom, prénom adresses

[Bluedeep]

Tu peux utiliser plusieurs techniques

Creer des vues pour simplifier le modele de la base de données
Creer des sous objets pour manipuler tes données métiers

---
Dans le cas que j'ai donnée Adresse n'est pas de l'héritage.
C'est un objet imbriqué.

Tu veux dire agrégé, plutôt, non ?

[BenoitM]

euh oui

[Bluedeep]

euh oui

Par ce que imbriqué, pour moi c'est une "sous classe", et si c'est pratique pour certain cas, sa prise en compte ne saurait relever - en général, car il y a des cas particulier - du modèle objet d'une application (mais d'un choix d'implémentation par le programmeur).

[Invité]

Pensez-vous que c'est fiable sur le long terme étant donné que ma société souhaite investir sur ce logiciel ?

Le logiciel étant depuis la base de données un concentré de mauvaises pratiques je doute de sa qualité. Or on sait tous que tout logiciel où la qualité est absente augmente le coût de la maintenance (qu'elle soit évolutive ou corrective) à moyen ou long terme.

Je pense que c'est comme ça avec la plupart des logiciels faits maison dans les SSII où toute personne en inter-contrat y touche, code à sa sauce, pas de documentation à jour et surtout que le point principal est l'absence de chef de projet pour le suivi du produit.

Bref je te souhaite surtout bonne chance pour les effets de bord.

[champomy62]

Bonjour,

Je reviens avec autre chose d'encore plus gros
J'ai essayais de faire comprendre à mes supérieurs que j'aimerai éclater une table de 104 champs en 2 tables pour travailler plus facilement, je vous explique .

Cette table contient actuellement :
4 champs qui permettent d'identifier un document sachant que ces informations sont redondantes. (Avec le numéro de document et une jointure, je peux retrouver les 3 autres informations(typ, état, domaine) bref passons) :

numeroDoc
TypDoc
Etat
Domaine
LIBZONE01
VALZONE01
LIBZONE02
VALZONE2
LIBZONE03
VALZONE3
...
LIBZONE50
VALZONE50


Voila comment est conçu cette table. Ce que j'aurai voulu faire, c'est éclaté cette table en deux, une qui contient les libellés et une autre, les valeurs avec pour clé primaire le numéro de document; ce qui aurait donné:

TABLE LIBEL_DIVERS:
NumeroDOC
LIBZONE01
LIBZONE02
LIBZONE03
LIBZONE04

TABLE VAL_DIVERS:
NumeroDOC
VALZONE01
VALZONE02
VALZONE03
VALZONE04

Pour moi cette décomposition m'aurait permis de mieux architecturer mon application et d'avoir une meilleure monté en charge de l'application puisque c'est une application fortement utilisée(Application de type GED : Gestion électronique de document).

Leur arguments : C'est plus facile quand tu as les données dans une table alors qu'une jointure c'est plus compliqué et niveau performances c'est pareil. Ils ne voient pas aussi pourquoi la maintenance serait accru si la table actuel serait éclaté. Ils me disent aussi que j'ai plus de chance de perdre des données car j'aurai 2 requêtes à faire au lieu d'une.. ce que j'ai contre dis car nous avons eu un exemple récemment qui démontrait que ça n'était pas vrai.

Qu'en pensez-vous et quels avantages dois-je donner pour convaincre mes chefs ? On en a déjà discuté et ils restent campés sur leurs positions actuellement.


Merci d'avance.