Discussion :

[mumen]

Développeurs, bonjour à vous

J'ai commencé à programmer au début des années 1980. Un bail. À cette époque on croyait pouvoir faire des programmes qui fabriqueraient des applications usuelles au kilomètre. On appelait ça des générateurs d’applications. On attendait beaucoup de la génération de code et comme toute bonne Arlésienne, on l'attend toujours…

J’ai relevé dans ce forum un argumentaire concis et, me semble-t-il complet qui vient appuyer trente ans après la thèse de l’Arlésienne. C’est un réquisitoire mature qui se pose définitivement contre la possibilité d'être un jour capable de générer des applications de gestion.

C'est bien beau de rêver qu'un générateur de code miracle sera capable de réaliser tout seul une application complète à partir des spécifications...

C'est juste oublier que tout n'est pas automatisable (par exemple comment un logiciel peut-il inventer un algorithme ?).

C'est juste oublier que ce qui est automatisable l'est souvent au prix d'une perte de souplesse et / ou de performance.

C'est juste oublier que le mélange code généré / code écrit à la main est une horreur à maintenir.

C'est juste oublier que le seul moyen pour que les spécifications soient assez précises pour être "traduites" directement en code, dans le cas général du moins, c'est qu'elles contiennent au moins autant d'infos que le code lui-même. Autrement dit le code est plus facile à écrire.

Pourquoi j'ouvre ce débat ? Depuis l'Internet, tout le monde est tombé un jour ou l'autre sur cette citation de Mark Twain : "Ils ne savaient pas que c'était impossible, alors ils l'ont fait". Eh bien ! ce n'est pas du tout ce qui m'est arrivé ! Je pensais que c'était très difficile peut-être même pire, mais je l'ai fait quand même, petit à petit en n'ayant rien à perdre que du temps à faire ce que j'adore faire, coder. Je sais ne pas être seul à avoir avancé en développement dans le sens qui s'est imposé à moi, mais je peux prétendre avoir obtenu en ce domaine un résultat flagrant et j’entends le partager.

Nous tous, développeurs professionnels sommes forcément passés par la phase de métaprogrammation, celle où l'on fait du code qui fait du code. Ce que je veux exprimer par ce débat que j'alimenterai progressivement en m'appuyant sur les points énoncés par I_believe_in_code, c'est ce que la métaprogrammation, systématiquement appliquée à la programmation d'applications de gestion, a pu donner comme résultats apparemment contre-intuitifs.

Voici mon credo porteur : "Tout ce que je fais pour un client donné, si c'est exploitable sans changement pour d'autres clients, alors je mettrai dix fois plus de temps à le faire s'il le faut, et à mon propre compte, mais je ne le referai jamais plus ensuite."

[mumen]

C'est bien beau de rêver qu'un générateur de code miracle sera capable de réaliser tout seul une application complète à partir des spécifications...

On connait désormais sans conteste le résultat d'un générateur de code à partir des spécifications : une fois qu'il est généré, on intervient pour ajouter les spécificités dans le code et ainsi on s'interdit de le générer à nouveau, on le fige complètement. Le problème, c'est qu'en figeant le code on fige aussi la spécification, puisque si l'on désire la modifier, on est obligé soit d'écraser le code préalablement généré - avec ses modifications - soit on est obligé de modifier à la main le code généré antérieurement pour qu'il reflète les modifications de la spécification. Dans les deux cas, dès que le client change d'avis - ou qu'on s'est trompé en cycle de développement rapide - , c'est la foire d'empoigne pour maintenir ce qui tend vite à devenir sac de nœuds.

À mes débuts, j'étais naïf et impressionnable, mais plutôt pragmatique. J'ai pu admirer un générateur de code et, la première surprise passée (on peut faire du code qui fait du code !) j'ai quand même bien vu que ce n'était pas pour moi... Trop désordonné, trop dans le besoin de faire pour comprendre. Quand des années plus tard, ayant la possibilité de tout recommencer à zéro sur de nouvelles bases, et que j'ai eu la pensée d'automatiser les tâches du quotidien, je n'ai même pas envisagé la génération de code comme solution viable. J'ai parfois l'impression que le développement rapide, objet, agile a suivi quand même cette voie-là au détriment de la spécification. Mais c'est une autre histoire.

Mon approche a été différente, la même que certains autres développeurs : générer de l'interface. Même si à l'intérieur de l'interface, il y a du code généré, en aucun cas il n'est envisagé de le modifier manuellement. La première mouture du formulaire sera écrasée, sans rien perdre, par la suivante. Cette interface devait elle-même être universelle, réutilisable à profusion, utile jusqu'au bout des ongles, toujours améliorable en tant que partie d'un système lié à une bibliothèque de code. Indépendante des spécifications. Une heuristique automatisée en somme.

Ce qui fait le succès d'Access, c'est en partie son heuristique. Quand, en tant que développeur, on affiche une table à la disposition des utilisateurs, on leur donne la possibilité sans rien avoir à coder de trier, de sélectionner ainsi que d'autres possibilités. Mais quand il s'agit d'améliorer cette heuristique, on est obligé de passer par la création de formulaires. C'est cette étape longue et demandant de l'habileté qu'une heuristique automatisée va prendre en charge. Si cette heuristique est bonne, alors il ne sera quasiment plus jamais nécessaire de créer un formulaire manuellement. On verra qu'il en va autrement pour les états, mais néanmoins, le gain de temps est prodigieux. Ce gain, vous développeurs professionnels, l'avez déjà expérimenté. Que vous ayez opté pour la génération de code ou pour la génération d'IHM, votre productivité est nécessairement et intimement liée à ce type de généralisation.

Mais tout n'est pas dit. Cette IHM doit avoir ses sources. La liste des colonnes d'une table n'y suffit pas et il faut bien y avoir quelque part une déclaration de ce qui la constitue.

La structure des tables, des champs et des relations offerte par le moteur de base de données, que ce soit Jet, MySql ou SQL Serveur, est finalement trop disparate et insuffisante pour définir cette IHM, puisqu'elle ne comporte pas la moindre donnée de navigation qui doit permettre d'approfondir l'outil généré.

Je ne sais pas comment ont procédé ceux qui ont opté comme moi pour la génération d'IHM, mais je me suis vu amené à concevoir un minilangage déclaratif de formulaire, indiquant la table concernée par le formulaire, son titre, sa source et bien sûr la liste de ses champs ainsi que certaines de ses propriétés. J'avais mis des jours entiers pour mettre au point un seul formulaire spécifique chez un client donné. Ce formulaire était un candidat valable pour la généralisation envisagée dans ce langage de formulaire. J'avais pu tester cela en d'autres sites et j'ai finalement développé une application complète basée uniquement sur des formulaires en colonnes, générés par mon nouveau moteur de génération d'IHM. En quelques minutes, montre en main, une trentaine ou plus de formulaires étaient fabriqués qui définissaient totalement un suivi de chantier de carreleur, de la prévision (MO, Achat, Sous traitance et Facturé) au réalisé (les mêmes). J'étais un peu intimidé de mettre ça sur les PC, et si ça ne marchait pas...

Le langage s'est révélé formidable. Selon les besoins, il s'est étoffé progressivement de possibilités nouvelles, en restant toujours relativement compatible avec ses anciennes versions. Il est très vite devenu une source aussi pour les appels de code. Appels extérieurs au formulaire, bien sûr, rangés dans un module classique, au nom tout trouvé, le nom de la table. Ça a commencé à se ranger tout seul... J'ai emmené au moins une dizaine d'applications dans l'aventure. Mais ça, c'est la suite de ce fil.

En conclusion de ce chapitre et pour répondre à I_believe_in_code, je déclare ici qu'un générateur d'IHM peut faire des miracles. Mais cela vous le saviez déjà. Par contre, correctement imbriqué dans un système, j'affirme qu'il sera capable de réaliser tout seul une application fonctionnelle à partir des spécifications... et ça, c'est ce que je veux vous faire comprendre d'abord et toucher du doigt ensuite !

Merci de votre patience.

[nnovic]

Voici mon credo porteur : "Tout ce que je fais pour un client donné, si c'est exploitable sans changement pour d'autres clients, alors je mettrai dix fois plus de temps à le faire s'il le faut, et à mon propre compte, mais je ne le referai jamais plus ensuite."

Ce serait l'idéal, c'est vrai, mais ce n'est pas toujours possible. Ainsi, la plupart des contrats de travail que j'ai eu dans ma courte carrière mentionnaient très clairement que tout ce que j'inventais était la propriété de l'employeur. Impossible, donc, à réutiliser chez un autre.

[Logan Mauzaize]

Ce serait l'idéal, c'est vrai, mais ce n'est pas toujours possible. Ainsi, la plupart des contrats de travail que j'ai eu dans ma courte carrière mentionnaient très clairement que tout ce que j'inventaisécrivais était la propriété de l'employeur. Impossible, donc, à réutiliser chez un autre.

On est pas dans paycheck Meme si le droit aux états-unis le permet, les idées ne sont pas brevetables en Europe.

[nnovic]

On est pas dans paycheck Meme si le droit aux états-unis le permet, les idées ne sont pas brevetables en Europe.

Ok, je n'ai pas utilisé le bon vocabulaire, les contrats en question parlaient d'invention, donc réalisation concrète en effet. D'ailleurs il s'agissait peut-être même de clause abusive. Ce que je voulais souligner, c'est qu'il n'était pas si évident de pouvoir réutiliser chez Y un projet développé chez/pour X. Il peut y avoir un problème de droit.

[el_slapper]

En même temps, j'ai eu à développé un outillage à la banque G, ça m'a pris un mois, à la banque B, j'ai eu besoin du même, en une journée c'était torché. Tout était déjà dans ma tête, il n'y avait plus qu'à...

[Logan Mauzaize]

En même temps, j'ai eu à développé un outillage à la banque G, ça m'a pris un mois, à la banque B, j'ai eu besoin du même, en une journée c'était torché. Tout était déjà dans ma tête, il n'y avait plus qu'à...

C'est bien ce que je voulais dire

Ok, je n'ai pas utilisé le bon vocabulaire, les contrats en question parlaient d'invention, donc réalisation concrète en effet. D'ailleurs il s'agissait peut-être même de clause abusive. Ce que je voulais souligner, c'est qu'il n'était pas si évident de pouvoir réutiliser chez Y un projet développé chez/pour X. Il peut y avoir un problème de droit.

Rien ne t'empêche de développer dans ton coin, pondre ça en librairie/COTS et octroyer le droit à ton client de l'utiliser Ou lui vendre si t'es un vrai maquereau
Par contre tu ne pourras pas lui vendre le temps de développement mais tu peux facturer la formation et le développement du paramétrage.

[mumen]

En même temps, j'ai eu à développé un outillage à la banque G, ça m'a pris un mois, à la banque B, j'ai eu besoin du même, en une journée c'était torché. Tout était déjà dans ma tête, il n'y avait plus qu'à...

C'est un vrai paradoxe de ce métier. Plus tu as de métier, moins tu coûtes cher !

[rimram31]

En même temps, j'ai eu à développé un outillage à la banque G, ça m'a pris un mois, à la banque B, j'ai eu besoin du même, en une journée c'était torché. Tout était déjà dans ma tête, il n'y avait plus qu'à...

Il m'est arrivé quelque chose de similaire, mais j'ai facturé deux fois ... rares situations ou on peut facturer ce que ça rapporte et non ce que ça coute.

[mumen]

AUTOMATISER

C'est juste oublier que tout n'est pas automatisable (par exemple comment un logiciel peut-il inventer un algorithme ?).

Personne ne dira le contraire. La question n’est pas de chercher à tout automatiser, mais de chercher ce qui peut l’être. Le présupposé qu’il faut tout automatiser pour pouvoir générer de l’application repose sur une erreur de jugement compréhensible : tous se sont cassé les dents là-dessus.

Je n’ai jamais cherché à tout automatiser, ni même à automatiser le plus possible. J’ai cherché à automatiser ce qui pouvait l’être, de la meilleure façon possible. Mon objectif est de pouvoir oublier le plus de choses possible quand je développe pour le client, et ceci pour ainsi dire à n’importe quel prix.

Nous étions restés au chapitre précédent au miracle de la génération d’interfaces Homme/Machine. Mes IHM étaient définies au début dans de petits fichiers textes. Le générateur de formulaires (puis d’états) était conçu pour ne surtout pas gêner l’autre programmeur, celui que j’étais quand j’étais en clientèle. Il me fallait à tout moment pouvoir revenir à des méthodes traditionnelles, tout en maintenant actif ce qui pouvait être « sauvé » d’une expérience de travail peut-être désastreuse face à la réalité. Il faut dire qu’aujourd’hui encore, ce système de développement conserve cet état d’esprit et reste débrayable : je peux à tout moment, en clientèle, sauter en marche du système et faire le boulot selon les méthodes traditionnelles. Dans les faits, cela ne m’a jamais servi. Le bouton « Créer un Formulaire » dans Access a quelque peu pris la poussière ces quinze dernières années. On verra qu'il n'est pas le seul.

Passer de petits fichiers textes pour définir les formulaires à une table des formulaires dans l’application, le pas à franchir était petit, mais lourd de conséquences. Ceci parce qu’un Formulaire est toujours relié à une Table elle-même constituée de champs, parce que cette table appartient à une base de données, à une application, etc. Ce franchissement qui allait devenir un gouffre de temps, une passion dévorante, peu de gens l’ont franchi. C’est ce qui fait que, à ce jour, peu de gens peuvent vraiment parler en connaissance de cause de la génération d’applications. La suite était logique pour une personne sans intention démesurée, comme je l’étais : je voulais juste m’alléger la tâche, je voulais être disponible et serein pour développer – à la tâche et non au forfait – l’application de mon client chez lui.

Automatiser ce qui peut l’être, et l’automatiser de façon la plus simple possible. En dessinant le système qui allait recevoir toutes mes applications, j’ai eu à faire des choix. Il me fallait quelque chose de rigoureux et de facile à programmer tout en restant ouvert à tout.


DEUX SIMPLIFICATIONS ÉLÉMENTAIRES

J’ai opté pour des clés primaires de tables systématiques, privées, de type numérique entier long et auto-incrémentées. J’ai considéré que les quelques optimisations perdues par cette obligation ne seraient pas un souci. J’ai fait mes premières armes sur des systèmes à disquettes et je sais ce qu’est la chasse à l’octet. J’ai fait ce choix d’autant plus facilement que je savais que de grands théoriciens de la base de données le recommandent chaudement.

La suite est intéressante. Le deuxième choix restrictif que j’ai fait concerne la mise en relation des tables. J’ai opté pour une relation de 1 à n sur clé étrangère à un seul champ et forcément sur la clé primaire de la table référencée. Cette méthode, la plus simple de toutes, permet de représenter toutes les relations, avec, comme précédemment, certaines pertes d’optimisations de modélisation. Cette dernière simplification allait s’avérer être la première pierre angulaire du système à venir : par cette simplification, la relation pouvait se définir entièrement comme une propriété d’un champ.

Les deux simplifications apportées ici ont ceci d’harmonieux qu’elles sont conformes à ce que l’on faisait bien avant en développement, quand on n’établissait pas de clé primaire sur les enregistrements puisqu’on avait leur position physique dans le fichier : le numéro de record. La relation se faisait tout naturellement en mémorisant un numéro de record étranger dans un champ de la table distante.

Access, depuis la version 2000, a exploité avec bonheur la déclaration de la relation dans son heuristique. Les développeurs qui utilisent la possibilité d’insérer les tables dépendantes d’un seul clic, sous forme de liste ou de détail d’enregistrement savent ce que permet cette intégration. Mais ce qui apparaît comme un excellent outillage d’appoint dans Access se révèle être beaucoup plus fondamental dans un système qui intègre vraiment les relations au niveau de la définition même des tables. Nous verrons par la suite certaines applications que ce procédé a autorisées, qui sont des concepts de rupture par rapport aux méthodes actuelles de modélisation. Rien de moins.


UN OUTIL DE FOND REMARQUABLE

Access est un grand logiciel de développement de logiciels de gestion. Bien qu’il ait potentiellement sa place dans les deux mondes, sa place est souvent par erreur assignée exclusivement au domaine des petits développements, car on l’associe avec son moteur de données par défaut, Jet.

Le monde du grand développement est celui qui correspond au mode d’accès aux données dit client/serveur. Dans ces applications, on est avant tout avare de bande passante réseau et l’on considère comme normal d’afficher un enregistrement à la fois.

Dans le monde du petit développement, la base centrale est partagée en Pair à Pair entre très peu d’utilisateurs, voire un seul et l’on se permet très naturellement d’afficher des listes entières d’enregistrements.

C’est dans ce deuxième monde, celui du petit développement que se situe ce système. Il bénéficie ainsi d’une très grande liberté avec les ressources, ce qui est une importante contrainte de moins. C’est la troisième des conditions qui a permis au problème de la génération d’application d’être résolu. Ceci pose des problèmes seulement si l’on sort des spécifications de Jet, et dans ce cadre, ce que je nomme « le gavage de combobox » est (plus ou moins) autorisé ! On lira à profit cet excellent texte de Papy Turbo qui permet bien d’appréhender cet état d’esprit et dont je mets ici un extrait significatif pour ce qui m'intéresse :

…je conçois qu’une liste déroulante de plusieurs milliers de lignes le fasse frémir d’horreur. J’ai atrocement honte, mais je fais cela tous les jours avec Access et Jet, sans n’avoir jamais subi la moindre perte de performances, même sur un « vieux » Pentium à 300 MHz.

UNE CLIENTÈLE SOUS-INFORMATISÉE

Le dernier point important à mes yeux qui sépare les deux mondes est la clientèle. Il est facile de comprendre que les gros comptes ont des budgets lourds pour la conception de leur informatique de gestion, les ERP par exemple. Les moyennes entreprises et certaines petites, ont aussi les moyens d’investir et ont des budgets pas aussi colossaux, mais sérieux quand même, qui les placent de facto dans la gamme des gros clients pour de gros développements en client/serveur.

On se dit qu’alors, les petits développements trouvent naturellement leurs clients chez les petites et les très petites entreprises… et l’on a tort. Aujourd’hui, le logiciel de gestion de bases de données le plus employé pour l’informatisation de la gestion de l'entreprise n’est pas un logiciel de gestion de bases de données. Ce n’est pas Access, non, c’est Excel. Une clientèle monstrueuse était au début des années 1980 l’enfant pauvre de l’informatisation de sa gestion et aujourd’hui elle a en plus le tableur, c’est quasiment tout ce qui a changé. C’est là que l’on se dit qu’une solution rapide, fiable et libre pour générer de l’application fonctionnelle sans savoir coder devrait être une quête pour pas mal de monde…


CONCLUSION

Dans ce second chapitre, je ne fais pas de déclarations fracassantes, non cela viendra. Je situe les conditions qui rendent possible d’automatiser ce qui est automatisable. C’est déjà énorme puisque cela situe la voie pour une première réalisation en taille réelle. Si je devais réécrire aujourd'hui cet outil, je pense que je réintégrerais certaines possibilités délibérément retenues, au début du cahier des charges comme : clé primaire de type indifférent avec possibilité de la rendre publique, écriture d'une IHM orientée pour chacun des deux mondes, etc. Mais c'est une autre histoire.

Merci de votre patience.

[germinolegrand]

Une question (et une quête) très intéressante que celle-ci !

Je m'intéresse fortement à la méta programmation, mon credo à moi commençant par : Do Not Repeat Yourself !

[Logan Mauzaize]

Bien que je trouve la prose bien écrite et intéressante mais que j'ai quelques désaccords, ça tend à nous emmener vers où ? Que tu es capable de générer automatiquement une application complète (avec quelques limitations) à partir d'une spécification décrite dans un langage naturel donc sans complétude et non formel (pas d’ambiguïté) ?

Concernant l'utilisation d'une clé primaire avec plusieurs champs, en dehors des ORM qui ont généralement besoin de la notion d’identité (au sens objet) en quoi est-ce un problème ?

[yann2]

Salut

Concernant l'utilisation d'une clé primaire avec plusieurs champs, en dehors des ORM qui ont généralement besoin de la notion d’identité (au sens objet) en quoi est-ce un problème ?

Ça n'a rien à voir avec le sujet initial mais, au hasard je dirai que le problème arrive dès que tu dois souvent référencer ladite table. On est alors obligé de faire une clé étrangère composée. On duplique donc des informations un peu partout. De plus, un nombre prend beaucoup moins de place que des chaines de caractères, par exemple.

J'ai toujours trouvé l'utilisation d'un identifiant technique plus sûre que les identifiants "naturels".

D'autres pistes de réponses sur wikipedia : http://fr.wikipedia.org/wiki/Cl%C3%A9_artificielle

Comme il est simple de définir une contrainte d'unicité sur plusieurs champs, je ne vois pas l'intérêt d'utiliser autre chose qu'un identifiant technique.

Un billet de blog à ce sujet : http://www.courtois.cc/blogeclectiqu...-cle-naturelle

Yann

[Logan Mauzaize]

En cas de clé étrangère composite, il s'agit parfois (généralement ?) d'une information intrasèque de la donnée fille. Donc on ne duplique pas de données à proprement parler.

Avec une clé "artificielle" tu supprimes une information qui peut être essentielle pour l'optimisation
Ex:

Code SQL :

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

1
2
3
SELECT * FROM CHILD WHERE PARENT_NOM='DUPONT'
vs
SELECT * FROM CHILD WHERE PARENT_ID IN (SELECT ID FROM PARENT WHERE NOM='DUPONT');

Il en est de même pour les optimiseurs de certains SGBD, qui utiliseront ce genre de liens pour optimiser les lectures.

Ca peut paraître bête dans cet exemple mais avec des relations un peu complexe, il te faut constamment faire des jointures sur les tables pour récupérer/filtrer les données.

Ce n'est pas nécessairement gênant avec les clusters Oracle (cad liés physiquement les enregistrements) mais je ne sais pas si les autres SGBD gère ce genre de mécanismes. De toutes façons ca revient à dénormaliser le schéma. Donc niveau gestion de l'espace disque, ca doit se valoir.

Il y a également plusieurs problèmes que j'ai déjà rencontré : impossible de rattacher les orphelins de manière fonctionnel/logique. Ca devient des données mortes qui polluent la base. Il faut constamment requêter les parents pour connaître leur identité.

Je ne dis pas que c'est inutile mais que l'inverse est tout à fait viable et exploitable.

[mumen]

Bonjour

Bien que je trouve la prose bien écrite et intéressante mais que j'ai quelques désaccords, ça tend à nous emmener vers où ? Que tu es capable de générer automatiquement une application complète (avec quelques limitations) à partir d'une spécification décrite dans un langage naturel donc sans complétude et non formel (pas d’ambiguïté) ?

La première précision qui s'impose est que je n'ai pas le niveau de vocabulaire et de connaissance théorique pour être certain de te comprendre entièrement : je suis formé sur le terrain. Mais je veux bien apprendre.

Ma spécification, qui permet de générer une application, n'est pas en langage naturel ! je n'en suis ni capable, ni même désireux - ou alors dans une autre vie. Non, c'est une définition formelle à plat qui comporte une liste exhaustive des tables, champs, relations avec leurs propriétés, plus, et c'est là un premier changement de paradigme de la formalisation dont je parlerai ensuite, plus donc, un saupoudrage d'informations concernant l'IHM et la navigation. Ma définition demande à l'acteur analyste d'indiquer formellement au système ce type d'information. En quelque sortes, ces informations sont la partie visible par l'utilisateur final qui s'appuie sur la modélisation classique qui, elle, lui est invisible.

Concernant l'utilisation d'une clé primaire avec plusieurs champs, en dehors des ORM qui ont généralement besoin de la notion d’identité (au sens objet) en quoi est-ce un problème ?

Ce ne serait un problème que si mon choix impliquait une restriction dans la possibilité de représenter une relation. Ce que je ne crois pas. Si j'ai fait ce choix, c'est pour deux raisons opportunistes. D'une part ma représentation à plat se trouve fortement simplifiée, ce qui m'autorise une grande lisibilité sans avoir à l'encapsuler dans un développement que je ne voulais pas faire, celui de l'éditeur de ces définitions. Cet éditeur, c'est Excel, utilisé de façon basique. D'autre part, la programmation de l'IHM repose énormément sur l'enchaînement relationnel et je n'ai pas voulu m'encombrer de complexités dont l'utilité n'était pas démontrée à mon niveau.

Il est possible que mon étude ne permette pas de tout représenter en terme d'informatique de gestion, mais il faudra me le montrer, car je ne l'ai jamais rencontré. Et je le redis, même si je n'ai pas la source à citer, c'est une chose reconnue et même préconisée par de vrais théoriciens. Ce cher Brouard doit bien savoir ça.

[mumen]

Avec une clé "artificielle" tu supprimes une information qui peut être essentielle pour l'optimisation

Je suis entièrement d'accord. C'est le prix que j'ai accepté de payer. Mon choix amène d'ailleurs d'autres complexités, lors du développement du système particulièrement. Je reste persuadé que c'est très secondaire eu égard aux résultats que j'ai obtenu dans un contexte pas aussi exigeant qu'en c/s. C'est un débat dans lequel je ne me noierais pas : comme je l'ai indiqué, s'il fallait redévelopper aujourd'hui, il faudrait en tenir compte.

Il y a également plusieurs problèmes que j'ai déjà rencontré : impossible de rattacher les orphelins de manière fonctionnel/logique. Ca devient des données mortes qui polluent la base. Il faut constamment requêter les parents pour connaître leur identité.

D'une part au sein de la base il y a les mécanismes d'intégrité relationnelle et d'autre part pour des liens non formels, c'est là qu'il faut bien établir une relation plus explicite, c'est le cas que je mentionne plus haut lors du développement système, ou j'ai du m'encombrer d'une clé primaire pour la compatibilité avec le système.

Ces désagréments ne doivent pas faire oublier les agréments. Le côté systématique de la relation telle que je l'emploie est aussi très reposant, il permet d'aboutir à un de mes buts : oublier des choses.

[yann2]

En cas de clé étrangère composite, il s'agit parfois (généralement ?) d'une information intrasèque de la donnée fille. Donc on ne duplique pas de données à proprement parler.

Avec une clé "artificielle" tu supprimes une information qui peut être essentielle pour l'optimisation
Ex:

Code SQL :

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

1
2
3
SELECT * FROM CHILD WHERE PARENT_NOM='DUPONT'
vs
SELECT * FROM CHILD WHERE PARENT_ID IN (SELECT ID FROM PARENT WHERE NOM='DUPONT');

Il en est de même pour les optimiseurs de certains SGBD, qui utiliseront ce genre de liens pour optimiser les lectures.

Ca peut paraître bête dans cet exemple mais avec des relations un peu complexe, il te faut constamment faire des jointures sur les tables pour récupérer/filtrer les données.

Ce n'est pas nécessairement gênant avec les clusters Oracle (cad liés physiquement les enregistrements) mais je ne sais pas si les autres SGBD gère ce genre de mécanismes. De toutes façons ca revient à dénormaliser le schéma. Donc niveau gestion de l'espace disque, ca doit se valoir.

Oui, l'exemple n'est pas bon.
* Lors d'un mariage, un des deux époux change de nom. Il faut donc mettre toutes les relations à jour (un ON UPDATE CASCADE) (mais quid des autres sources de données qui utilisaient aussi cet identifiant ?)
* Deux personnes ne peuvent pas s'appeler 'DUPONT'.

Mais bon ça c'est juste le doigt. J'ai compris ton exemple et saisi l'idée

Je ne fais pas l'apologie des clés artificielles, je veux juste exposer pourquoi on peut les utiliser et les pros et cons sont déjà renseignés dans les liens que j'ai donné

[nnovic]

Bon enfin bref, jusqu'à maintenant il y a beaucoup de blabla, et peu d'éléments probants...

[yann2]

Bonjour

Bon enfin bref, jusqu'à maintenant il y a beaucoup de blabla, et peu d'éléments probants...

Et bien personnellement, j'utilise la génération de code au quotidien mais, je ne fais plus d'application de gestion. Donc je vais essayer de donner quelques éléments.

Tout d'abord, j'utilise l'ingénierie dirigée par les modèles et plus concrètement les technologies basées sur le framework Eclipse Modeling Framework (http://www.eclipse.org/modeling/emf/). Ce framework propose un méta-méta-modèle nommé Ecore qui est une implémentation d'EMOF (Essential Meta Object Facility) qui est un standard défini par l'OMG (Object Management Group). Voir la spécification de MOF ici : http://www.omg.org/spec/MOF/2.4.1/.

EMF propose de facilement définir ce qu'on appelle un DSL (Domain Specific Language). Il fourni un générateur qui va nous permettre de manipuler les modèles exprimés à l'aide de ce DSL.

De nombreux outils s'appuient sur ce framework pour fournir, par exemple :

• des modeleurs graphiques
• des générateurs de code
• de la validation de modèles
• de la transformation de modèles

Il y a un petit tutoriel sur l'utilisation d'acceleo qui est un outil pour écrire des générateurs de code ici : http://younessbazhar.developpez.com/.../introacceleo/

Il s'agit vraiment d'une introduction. La puissance d'acceleo se révèle lorsqu'on utilise un DSL.

Vous pouvez trouver ici : https://github.com/eclipse-soc/amalg...n-with-Acceleo un exemple bien plus fourni pour la génération d'une application Androïd à partir d'un DSL.

En utilisant correctement cet outil on obtient :

• Un générateur incrémental : il est possible de relancer la génération sans perdre le code ajouté par un développeur
• Du code lisible et respectant les bonnes pratiques
• La possibilité de débrancher le générateur : déduit du deuxième point.

Le principal problème est de définir ce qu'on veut générer. On aura tendance à vouloir générer beaucoup de choses mais cela complique beaucoup le travail de modélisation. Il faut donc trouver un compromis. Personnellement je ne vois pas l'utilité de vouloir générer 100% du code d'une application en utilisant cette technique. Le modèle et le générateur de code deviendraient trop complexes.

Yann

[I_believe_in_code]

Je ne comprends pas grand chose aux discussions sur les logiciels de gestion, ni sur les bases de données (domaine auquel je n'ai pas touché depuis mes études).

Je tiens cependant à apporter une précision par-rapport à ce que je dis dans mon passage quoté dans le premier post de ce sujet.

Je suis personnellement un pratiquant convaincu du code généré. Il y en a peu, en proportion, dans mes programme, mais il y en a. C'est d'ailleurs la principale raison pour laquelle je continue de temps en temps de programmer en LISP entre deux épaisses tranches de C. Les macros de LISP sont excellentes pour générer du code.

Mais je n'utilise que des générateurs de code que j'écris moi-même, et qui produisent du code ni plus ni moins lisible et ni plus ni moins long que celui que j'écrirais entièrement à la main. Je ne pourrais pas avoir confiance en un truc qui produit cinq mille nouvelles lignes de code imbuvables dans douze langages différents dès que je clique sur un bouton. Je n'en peux plus de ces applis qui tournent à un centième de leur vitesse théorique tout en nécessitant 1Go de mémoire et de disque pour faire pas mieux que ce que j'utilisais il y a dix ans sur mon ordinateur de l'époque (Un pentium 166 avec 2 Go de disque dur qui était déjà dépassé à ce moment-là mais sur lequel je n'utilisais que des logiciels corrects pas du tout générés).

Par ailleurs je n'ai jamais réussi (en fait je n'ai jamais osé essayer, et j'ai peut-être tort ?) à générer "automatiquement" une application complète et je ne vois même pas comment cela serait possible dans mes domaines de prédilection (le traitement d'image et l'analyse d'image).