Discussion :

[_skip]

Bonjour,

Ce sujet fait suite aux récentes discussions sur ce forum concernant les ORM, les problèmes rencontrés au niveau de la qualité du design des bases de données et la capacité d'indépendance offerte par ce type d'outil par rapport aux différentes bases de données du marché.

Dans mon expérience, une application orientée base de données a toujours démarré (sans compter les phases plus orientées analyse, organisation, faisabilité) par la création du schéma de base de données. Ensuite seulement venait la partie ORM / mapping par rétro ingénieurie pour la création du *client* de cette BDD. (approche schema-first)

Maintenant qu'un certains nombres d'outil et de frameworks d'OR/mapping vous propose l'inverse, c'est à dire vous écrivez vos classes en c# ou en java vous ajoutez quelques annotations au tout et vous générez la base de donnée qui va avec par forward-engineering. (Model first).

Dans leurs discours commerciaux, ces outils vous promettent :

-Une productivité sans égale.
-Du code indépendant de la base de donnée finale parmi celles supportées.
-La persistence transparente.
-La prise en charge de la migration en cas d'évolution du schéma BDD.

Les outils stables proposant cette approche dont j'ai entendu parler jusqu'ici sont :

-XPO
-OpenAccess

Alors les vraies questions sont :

-Avez-vous des retours d'expérience d'utilisation d'approches model first?
-Croyez-vous en ce genre de pratique et si oui jusqu'à quel point?

[Emmanuel Lecoester]

Le mariage OO - relationnel n'est qu'un middleware. Maintenant qu'on fasse :

• modèle OO -> génération relationnel
• modèle relationnel-> génération OO
• modèle relationnel, modèle OO, ORM

Au final on perdra d'un coté ou de l'autre...

Un de ces jours on remettra tout dans des fichiers texte vu que le développeur dotnet nous annoncent "la base de données on s'en fout c'est la DAL qui le gère".

J'ai vu une approche "model first" en 1999 où c'était l'IHM qui pilotait le modèle de base de données, sur les 8 lots du projet seuls les deux premiers ont vu le jour vu qu'à chaque lot on revoyait le modèle .

[souviron34]

Le mariage OO - relationnel n'est qu'un middleware. Maintenant qu'on fasse :

• modèle OO -> génération relationnel
• modèle relationnel-> génération OO
• modèle relationnel, modèle OO, ORM

Au final on perdra d'un coté ou de l'autre...

Un de ces jours on remettra tout dans des fichiers texte vu que le développeur dotnet nous annoncent "la base de données on s'en fout c'est la DAL qui le gère".

J'ai vu une approche "model first" en 1999 où c'était l'IHM qui pilotait le modèle de base de données, sur les 8 lots du projet seuls les deux premiers ont vu le jour vu qu'à chaque lot on revoyait le modèle .

Pour moi, cela fait longtemps que c'est la base de ma pensée...

Dans 99.999999% des cas que j'ai vu, utiliser une SGBD était tout simplement un "trip" ou un à-priori d'informaticiens ou de boîtes...

Dans la pratique, à quelques (très rares) exceptions près, cela complique très nettement le choses, sans parler des coûts qui explosent...

Je ne suis pas contre à priori, je suis contre l'utilisation d'un bulldozer pour écraser une mouche...

Et en effet, de ce que je vois depuis une 15 aine d'années avec l'OO, sa modélisation, et les possibilités offertes par des outils/langages.. comme SQL, je pense fondamentalement que dans le principe il y a un bug....

Quand on demande à faire une opération complexe, c'est une opération métier. Cela devrait donc être à la couche métier de la faire. Et de plus, comme c'est métier, cela devrait être indépendant de la manière dont les données sont stockées/gérées, et donc indépendant de la BD..

Or je ne vois apparaître que de plus en plus de liens, et de plus en plus d'imbrication de la BD avec les données et le métier...

Pour moi, une bonne application portable et indépendante devrait considérer à la base être répartie et multi-BD, et donc indépendante de SQL etc (avec par exemple certaines données sous Oracle, d'autres sous Access, d'autres dans des fichiers textes etc etc..).

UNIQUEMENT à cette condition on aurait alors une vraie analyse, et une vraie séparation et indépendance...

Mais visiblement les forces du marketing et des modes sont plus fortes que le bon sens

Sans parler des problèmes de perfomances, où pour accéder à une donnée il faut passer à travers 250 tables différentes..

[Tommy31]

Quand on demande à faire une opération complexe, c'est une opération métier. Cela devrait donc être à la couche métier de la faire. Et de plus, comme c'est métier, cela devrait être indépendant de la manière dont les données sont stockées/gérées, et donc indépendant de la BD..

Ca, ca fait plaisir à lire !

Pour moi, une bonne application portable et indépendante devrait considérer à la base être répartie et multi-BD, et donc indépendante de SQL etc (avec par exemple certaines données sous Oracle, d'autres sous Access, d'autres dans des fichiers textes etc etc..).

Bien qu'idéaliste, je partage cette conviction. Cependant dans les cas concrets et sous le joug de fortes contraintes de temps, on s'assoit vite sur ces bons principes.

Mais visiblement les forces du marketing et des modes sont plus fortes que le bon sens

De quelle mode parles-tu ? Il me semble que la mode justement est aux architectures en couche avec une segmentation claire des responsabilités, et une indépendance marquée entre elle (couplage relaché).

[_skip]

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

[Plageman]

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

A nous autres non expert de trouver notre vérité...

[Emmanuel Lecoester]

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

C'est exactement ce que je me disais aussi.

Les bases de ces deux approches sont parfaitement recevables.

Dans le cas du modèle OO drivant le modèle relationnel, quel interet à passer sur un SGBDR ? pourquoi n'utilisez vous pas un SGBDOO cela éviterai les couches ORM et vous auriez une vraie gestion OO .

Pour la partie bases de données épaisses j'accroche un peu plus car combien d'applications sont développées avec les dernières technologies (dot, java,...) tout en gardant le modèle d'origine d'il y a quelques années (qu'il soit bon ou mauvais) ?

[souviron34]

De quelle mode parles-tu ? Il me semble que la mode justement est aux architectures en couche avec une segmentation claire des responsabilités, et une indépendance marquée entre elle (couplage relaché).

Je ne sais pas, de ce que je vois sur les forums ici et là...

Que ce soit en développements Web, sur le forum Conception, ou sur le forum BD...


Je trouve les schémas, modélisations, etc etc, et BDs très très très fortement liées (via la BD, via un outil)..

Et l'utilisation d'UML ou de MCD comme des Dieux en fait partie...

[TheLeadingEdge]

Je trouve les schémas, modélisations, etc etc, et BDs très très très fortement liées (via la BD, via un outil)..

Et l'utilisation d'UML ou de MCD comme des Dieux en fait partie...

Ce n'est pas du tout ce que l'on essaie de faire passer comme message dans Conception!! Au contraire!
On y parle d'orthogonalité, de forte cohésion, faible couplage, séparation des responsabilités...
La persistance (mémoire) de l'appli est gérée par un SGDBr. On fait un modèle ad hoc. Pour moi c'est encore 1 MLD.
Et si la cible est 1 SGBD00 c'est un DC UML spécialisé.
Le métier (l'intelligence) c'est un autre modèle (DC UML). La couche métier n'a pas a savoir comment les données sont persistées. Elle délègue de façon transparente à une couche service (DAL/DAO)
La couche service de persistance c'est avec un framework. Hibernate par exemple parce que je pense que c'est le plus évolué (mais d'autres en préfèreront un autre et auront aussi raison).
Plus les 2 modèles à mapper seront propres, plus le mapping auto sera de bonne qualité. Mai pour l'instant le meilleur ''mapper'' reste le dev. Et il ne faut pas s'imaginer que HB8 est une baguette magique qui va corriger les erreurs de conception et faire un bon travail à partir de bases cochonnées.
On peut faire du boulot trés propre et trés fin avec un framework. Mais il ne sufit pas de cliquer sur 2 boutons pour générer un modèle générique et ensuite dire que l'outil fait de la merde. Ou à l'inverse bidouiller dans le mapping sans se poser de question sur l'intelligence de ce qu'on fait pour corriger des erreurs ou des manques dans les modèles données ou métier. Ca nécessite un minimum de compétences.

Dans 99.999999% des cas que j'ai vu, utiliser une SGBD était tout simplement un "trip" ou un à-priori d'informaticiens ou de boîtes...

Dans ceux ou je travaille, c'est 99,9% obligatoire. Mais c'est du à un domaine différent sans doute (info de gestion)

pourquoi n'utilisez vous pas un SGBDOO cela éviterai les couches ORM et vous auriez une vraie gestion OO .

. Tu t'es déjà battu avec les pointeurs d'une appli en c qui gère les objets dans un base oo ?
XML c'est un caviar à faire.

[souviron34]

La couche métier n'a pas a savoir comment les données sont persistées. Elle délègue de façon transparente à une couche service (DAL/DAO)

Mais elle n'a même pas à savoir ce que c'est que la persistence !!!!

Par contre, la BD n'a rien à savoir de ce qu'on fait avec les données. Elles est purement fournisseuse...

Or je vois (et je suis désolé, cela figure beaucoup dans ce que je vois dans le forum Conception) des modèles où on applique des "join", des "where", etc etc..

Et, qui plus est, où on introduit (dans du code Java, Php, C++, ou n'importe quoi) des requêtes SQL (ou mysql, mais c'est strictement pareil), dans du code d'IHM, dans du code métier, etc etc...

La combinaison des 2 effets me paraît catastrophique...

C'est tout.

[TheLeadingEdge]

Mais elle n'a même pas à savoir ce que c'est que la persistence !!!!

Oui mais on serait dans un mode parfait. Pour l'instant ce qui s'en rapproche le plus c'est d'utiliser un fwk qui mappe automatiquement les 2.

Par contre, la BD n'a rien à savoir de ce qu'on fait avec les données. Elles est purement fournisseuse...

Encore ''oui mais'' (désolé ). La bdd est la mémoire, le métier est l'intelligence. Mais les 2 couches doivent être cohérentes entre elles. Il existe tout de même un lien entre les données qui sont travaillées ds la couche métier et l'organisation des données stockées ds la base (ou vice-versa)

des modèles où on applique des "join", des "where", etc etc..

Il faut bien entrer et sortir les données. Dans la couche de persistance, le SQL ''c'est pas sale'' ?

Et, qui plus est, où on introduit (dans du code Java, Php, C++, ou n'importe quoi) des requêtes SQL (ou mysql, mais c'est strictement pareil), dans du code d'IHM, dans du code métier, etc etc...La combinaison des 2 effets me paraît catastrophique...

Là je ne peux qu'être totalement d'accord. C'est une horreur.

[souviron34]

Encore ''oui mais'' (désolé ). La bdd est la mémoire, le métier est l'intelligence. Mais les 2 couches doivent être cohérentes entre elles. Il existe tout de même un lien entre les données qui sont travaillées ds la couche métier et l'organisation des données stockées ds la base (ou vice-versa)

pour moi, la réponse est NON


Je te cite l'exemple le plus flagrant sur lequel j'ai travaillé :

un logiciel pour la météo.

Données :

• des stations au sol, automatiques, ou des messages d'avion. BD format interne aux Services de Meteo. Structure de répertoire par jour.
  
  
• des modèles numériques 3D : BD format international météo, structure de répertoire libre (par origine (Europe, USA, Canada, Japon..), par résolution (aux 100 kms, aux 25 kms, aux 2kms), par dates (une semaine, un jour..)...
  
  
• des radars : BD format fournisseur du Radar. Structure du répertoire fixée (par heure).
  
  
• de la foudre : format ASCII. Structure de répertoire par années.
  
  
• Des dessins graphiques (front, éditions) : format suivant les logiciels. Structure des répertoires suivant les logiciels.

ça c'est juste pour les données principales...

Le logiciel (et la couche de communication, le protocole), n'en a rien à savoir de comment les données sont stockées... ni de leur granularité dans le temps, ou dans l'espace..

Tout ce qu'on demande c'est "données entre telle et telle date, de telle source, entre tel (latitude,longitude) et tel (latitude longitude)".

Un point c'est tout...

Côté application, tout est dynamique. On ne sait ni avec quel serveur on traite, ni avec quelle base de données, ni quelle est l'organisation. La première connection donne la liste des types de données et des sources.
On choisi ce qu'on souhaite, et voilà.

Du côté des serveurs, c'est identique : en général ça fonctionne en grappe. L'application se connecte sur un serveur, qui a une liste d'esclaves. Le "maître" ne sait pas ce qu'il gère, ni comment c'est géré, ni avec quel outil. C'est uniquement au serveur de bout de chaîne, celui qui attaque directement la BD, de savoir comment les données sont organisées, avec quel outil...

[souviron34]

Je rejoins un peu Vlade, franchement y en a marre des querelles de chapelle stériles...
...
Respectons-nous les uns les autres en évitant les positions intégristes et on y arrivera

ce n'est pas à mon propos que tu dis ça, hein ??

Parce que je ne suis ni l'un ni l'autre....

[el_slapper]

@Souviron : ton exemple est un exemple, ou effectivement on peut deconnecter pas mal de choses. Quand on gère(j'ai fait ça la semaine dernière) des contrats et les garanties associées aux contrats, il faut bien, à un moment, récupérer les données des garanties pour pouvoir gérer le contrat. Celui-là; pas le contrat d'après. Tu es bien obligé de mettre une clause where n° contrat = n° contrat trouvé dans la base contrat..... Que ce soit dans le programme principal(ce qui est fait), dans une couche d'accès(solution qui a ma préférence) ou dans la base de données directement(ce que je deteste).

Je déteste confier des tâches à la base de données parceque personne n'y comprend rien. L'analyse fournie dans le blog du défenseur de cette solution explique que c'est la faiblesse des compétences en base de données qui explique pourquoi cette solution "optimale" n'est pas généralisée. Je suis d'accord, et j'ajouterais que si personne n'y panne rien, c'est une mauvaise solution, qui mérite donc son sort funeste.....

[souviron34]

@Souviron : ton exemple est un exemple, ou effectivement on peut deconnecter pas mal de choses.

Oui et non..

Quand en temps réel tu veux calculer un champ qui soit "Température modèle - Température Observée", par exemple, ou afficher simultanément toutes les données présentes et les avoir en temps réel, il faut bien être connecté à l'ensemble...

MAIS cela suppose une modélisation des données et de leur accès INDEPENDANTE de la BD..

Car de plus rien ne dit que demain matin les modèles numériques ne seront pas gérés par Oracle.. (ce qui s'est passé pendant un temps (avant qu'ils ne reculent devant le prix de la Licence))

Quand on gère(j'ai fait ça la semaine dernière) des contrats et les garanties associées aux contrats, il faut bien, à un moment, récupérer les données des garanties pour pouvoir gérer le contrat. Celui-là; pas le contrat d'après. Tu est bien obligé de mettre une clause where n° contrat = n° contrat trouvé dans la base contrat..... Que ce soit dans le programme principal(ce qui est fait), dans une couche d'accès(solution qui a ma préférence) ou dans la base de données directement(ce que je deteste).

Non, ça c'est parce que la BD a été conçue comme ça.. ça n'est pas intrinsèque..

Tu as des contrats qui ont un type. Suivant le type il y a des garanties.

Je n'y connais rien à ce domaine, mais la logique n'est pas forcément (je n'ai pas dit "n'est pas" ) celle mise en oeuvre ici...

Et sinon, par exemple une chose qu'on avait faite pour la météo, c'est définir des types de données "agrégé", qui n'ont aucun sens l'un sans l'autre.. (par exemple, le vent est un couple vitesse,direction.. Envoyer une latitude-longitude et une direction toute seule ne sert pas à grand chose...).

Et le type de donnée "utilisateur" était donc "vent".

Maintenant, je ne connais pas ton domaine, mais j'ai quand même eu à faire quelques incursions dans des SGBDR de "gestion" (pour l'équivalent d'EDF dans un pays étranger), et j'avais trouvé l'usage de SGBDR lourd.. Mais c'était (sans doute ??) dû à leur modélisation.. Disons que aller d'un client à son compte , ça allait, mais pour le relveur du compteur, c'était assez complexe si par exemple le compteur avait changé d'endroit (je crois me souvenir 15 tables successives...)...

Je déteste confier des tâches à la base de données parceque personne n'y comprend rien. L'analyse fournie dans le blog du défenseur de cette solution explique que c'est la faiblesse des compétences en base de données qui explique pourquoi cette solution "optimale" n'est pas généralisée.

Non, je crois qu'au contraire c'est parce que la solution de facilité est d'utiliser les BDs directement... Il est plus facile de se servir d'une requête complexe (car SQL est quand même très complet si on veut faire ce genre de choses) que de faire une modélisation stricte indépendante qui au final fera la même chose...

Enfin, c'est mon avis..

Mais encore une fois, quand je vois les analyses de certains, il y a de quoi s'arracher les cheveux...

j'ajouterais que si personne n'y panne rien, c'est une mauvaise solution, qui mérite donc son sort funeste.....

[GrandFather]

Je déteste confier des tâches à la base de données parceque personne n'y comprend rien. L'analyse fournie dans le blog du défenseur de cette solution explique que c'est la faiblesse des compétences en base de données qui explique pourquoi cette solution "optimale" n'est pas généralisée. Je suis d'accord, et j'ajouterais que si personne n'y panne rien, c'est une mauvaise solution, qui mérite donc son sort funeste.....

A contrario, l'approche « Model first » n'est pas toujours exemplaire de simplicité, malgré les discours lénifiants. Hibernate, c'est bien joli pour faire du mapping simple, mais lorsqu'on attaque les problématiques de transaction et d'aggrégation d'objets cela devient tout de suite moins trivial... Je pense même, mais ce n'est qu'une évaluation personnelle, que la maîtrise de ces concepts nécessite un effort de formation du même ordre de grandeur que pour être à l'aise avec le modèle relationnel et SQL. Et encore, SQL est un standard, on peut donc s'attendre à une certaine homogénéité de fonctionnement en changeant de base de données ; si on change de framework, on réapprend tout ou presque.

Personnellement, je reste sur l'approche « schema first » : le modèle relationnel est conçu et éprouvé avant même qu'une seule ligne de code de l'application ait été écrite. J'y implémente le maximum de règles métiers, tout ce qui permettra de préserver au maximum l'intégrité et la cohérence interne des données. S'assurer ainsi qu'à tout moment on n'aura pas de garanties enregistrées sans le contrat auxquelles elles se rapportent, que la date d'effet ne peut pas être antérieure à la date de souscription, etc.

Ainsi, on se prémunit au maximum d'éventuels défauts des applications clientes de la BDD. Je suis en cela l'enseignement de mes maîtres : « Ecris des applications bugguées, incomplètes, ne répondant pas au cahier des charges mais JAMAIS, entends-tu, JAMAIS tu ne dois jouer avec les données du client ».

Bien sûr, cette approche n'a pas que des avantages, elle suppose que toutes ces règles métiers sont entièrement formalisées, et relativement pérennes. Dans des domaines où les spécifications ne sont pas totalement stabilisées, l'approche Model first peut apporter plus de souplesse.

[souviron34]

juste un petit aparté sur ce que tu mentionnes..

J'ai eu à travailler sur un énorme (60 personnes depuis 15 ans, 2 millions de lignes, 85 millions de $) projet..

L'architecte était l'achitecte original (celui depuis le départ). Le directeur technique aussi...

Lorsque j'ai demandé à l'architecte ce que faisait son soft, il m'a montré son mur, derrière lui, où s'étalaient (mur entièrement couvert) toutes les relations de la BD.. Mais il était incapable (ou plutôt il n'était plus capable) de me dire ce que le soft était censé faire, de manière aborescente et succinte (comme un document marketing).

Sauf que, le soft ne faisait pas ce qui était demandé.. Ou plutôt, il le faisait, en présupposant que la BD était remplie, car ils avaient prévues les données pour des cas de recherche d'archives/statistiques. Mais la BD était vide, car personne ne voulait utiliser le soft...


Finalement, après 1 an de travail, on a réduit tout ça à 24 fenêtres (ils en avaient 650) et 70 000 lignes de code. Avec Access. Et juste 8 tables..




Tout ça pour dire que la structuration des données ne fait pas tout, loin s'en faut...

[_skip]

Personnellement, je reste sur l'approche « schema first » : le modèle relationnel est conçu et éprouvé avant même qu'une seule ligne de code de l'application ait été écrite. J'y implémente le maximum de règles métiers, tout ce qui permettra de préserver au maximum l'intégrité et la cohérence interne des données. S'assurer ainsi qu'à tout moment on n'aura pas de garanties enregistrées sans le contrat auxquelles elles se rapportent, que la date d'effet ne peut pas être antérieure à la date de souscription, etc.

Ainsi, on se prémunit au maximum d'éventuels défauts des applications clientes de la BDD. Je suis en cela l'enseignement de mes maîtres : « Ecris des applications bugguées, incomplètes, ne répondant pas au cahier des charges mais JAMAIS, entends-tu, JAMAIS tu ne dois jouer avec les données du client ».

C'est aussi mon cas, toutes les contraintes d'unicité ou de clefs étrangères sont décrites. On ne shoote pas un produit qui est référencé dans une commande, ou un client qui a une facture. On insère pas de données incomplètes. J'arrive pas du tout à comprendre pourquoi tant de gens ne créent même pas les foreign keys!

Ensuite du coté client, j'interagis avec les données a l'aide d'une façade métier qui prend en charge les opérations CRUD, la conversion d'une ligne de donnée en un objet de même structure, etc...
J'aime que ces objets soient plus ou moins des copies 1:1 de ma base de donnée, et ne pas en faire des objets métiers *lourds* avec deux tonnes de fonctionnalités qui incluent du lazy loading et ça.

En fait je suis incapable de me dire d'utiliser un objet mappé d'hibernate tel un objet métier, je me sers d'ORM vraiment au sens "jveux pas faire du SQL pour des opérations simples".

Je supporte pas l'idée de me dire que je vais accéder à une propriété et que ça va générer dieu sait quel requête derrière avec suivant comment, une grosse exception car la connexion BDD a été fermée entre deux! J'aime bien que les objets ne m'explosent pas à la figure et soit sérialisables sans soucis.
Et je trouve qu'hibernate avec les proxys dynamiques est vraiment pénible avec tout sa *magie* qui opère alors que l'entité est hors du contexte ou elle a été chargée.

[B.AF]

Ah moi j'aime lire souviron parce que ça sent la vraie vie.

Il faut aller jusqu'au bout de la chose: ORM, SQL, Génération de code..Ce sont des outils, l'erreur est humaine.

Le problème de l'informatique d'aujourd'hui est qu'elle répond à des problèmatiques métier par des concepts technologiques.

On peut utiliser l'outil que l'on veut, la conception technologique, c'est 10% du travail. La modélisation, l'abstraction, la spécification, la compréhension, l'encpsulation du business, de ses règles c'est 90% du job.

L'architecture en couche n'a pas de sens fonctionnellement. Elle a un sens dans la gestion : maintenance, tests, spécialisation.

A force de parler d'objets métiers, de règles métiers on oubli qu'un objet n'est pas seul.

Question de base :
J'ai un objet A, qui contient une liste d'objet B, chaque B contient un C qui lui même dépend d'un A et une liste d'objets E.
Sachant que pour appliquer l'algorithme j'aurai besoin d'une liste de D qui contient une liste d'IH, ou IH est une interface implémentée par J ou k.
En fonction du résultat de A.B[n].C.A.Prop1== A.Prop1, je dois exploiter D.J[] ou D.K[].
Cette exploitation va m'amener pour chaque E présent dans la liste à..
Le mettre à jour si E[n].Prop1==B[n].C.Prop1
Le supprimer sinon
Le créer si il n'existe pas

- La plupart des mappeurs SQL vont générés autant d'instructions SQL qu'il y a de problèmes
- La plupart des ORM vont mal utilisé provoquer une surcharge, des n+1
- Bien utilisé, avec une politique de lazy et une exploitation judicieuse, il vont générer moins de SQL par usage du cache n1; mais dans ce cas, il faut penser statefull, sinon, chaque màj demandera d'attacher à la session donc provoquera des hits DB
- Des SP sont une solution, mais la modèle objet devra être injecté, provoquant la nécessité de passer par des structures annexes. LEs transactions seront complexes à piloter
- Dans le cas d'un SOA, le service peut faire, mais le volume de données du graph sera suffisamment lourd pour plomber les perfs
- DAns le cas d'un client serveur, le client va morfler

Il n'y a pas de cas triviaux dans le développement d'entreprise.
La réponse à ma question est dans la modélisation. Le model est ne lui même inutilisable correctement. C'est un pb de conception pas de techno.

[souviron34]

Ah moi j'aime lire souviron parce que ça sent la vraie vie.

Si ce n'est pas ironique, c'est sans doute à cause de mon approche de "physicien", pratico-pratique et non informaticien...

Je n'aime ni les maths ni la théorie, mais les solutions.. simples.. (même si elles sont complexes à trouver)..

Il n'y a pas de cas triviaux dans le développement d'entreprise.
La réponse à ma question est dans la modélisation. Le model est ne lui même inutilisable correctement. C'est un pb de conception pas de techno.