Discussion :

[nico1407]

La création de la base de données par des annotations dans le code n'est pas une solution idéale.

La conception de la base ne passe même plus par un DBA pour optimisation et on assiste à du n'importe quoi de la part des developpeurs qui n'ont pas le niveau en SGBD.

J'ai vu un projet qui a commencé avec la création de la base par annotation, à la 2e version de l'application l'équipe est revenu à faire ses scripts SQL à la main, manque d'index, contrainte unicité...

Il est dangereux de faire évoluer sa base par "magie" avec les framework, on arrive à un point où les équipes de développement ne savent même plus ou ne veulent plus chercher à comprendre la gestion d'une BDD.

[_skip]

C'est ce que je soupçonnais en fait, trop d'abstraction risquerait de couper court aux optimisations que l'on peut réaliser par modélisation (éviter les jointures qui servent à rien, préférer rassembler les entités héritées dans une même table plutôt que d'éclater sur plusieurs tables suivant la situations etc..)

Pour la défense de Souviron, je dirai que ça m'arrive souvent d'utiliser des objets comme de vulgaires structures, des POJO IBatis notamment lorsqu'il s'agit de devoir lire et présenter / utiliser rapidement des données provenant de BDD.
C'est pas compatible avec la théorie du bô domaine full OO, c'est quasiment pas de l'objet, mais ça fait exactement ce que je demande et c'est performant.

Je crois surtout que ce qui est important, c'est que la théorie de façon excessive est nuisible car elle écarte de la réalité.
C'est un peu là qu'est l'ambiguité de la bonne approche : elle peut être bonne dans son contexte, et très mauvaise d'un point de vue académique.

+250000, J'ai vécu l'expérience de faire des choses contre mon intuition pour obéir aux bonnes pratiques (notamment en matière de d'abstraction et de couplage). Ben je dois dire que c'est arrivé que la complexité inutile ajoutée me retombe dessus...
Comme on a déjà dit, si le résultat est maintenable et satisfait le client dans les délais, le reste n'est que littérature.

[GrandFather]

Pour la défense de Souviron, je dirai que ça m'arrive souvent d'utiliser des objets comme de vulgaires structures, des POJO IBatis notamment lorsqu'il s'agit de devoir lire et présenter / utiliser rapidement des données provenant de BDD. C'est pas compatible avec la théorie du bô domaine full OO, c'est quasiment pas de l'objet, mais ça fait exactement ce que je demande et c'est performant.

Je le fais aussi, et quand j'utilise l'ORM de manière plus poussée c'est en en faisant le « client » de la BDD et pas l'inverse. La position de souviron est à un tout autre niveau : il ne voit même pas l'intérêt de l'objet en général, alors nos nuances « conception full OO » ou « conception mixte OO/SGBDR » lui passent un peu au dessus de la tête...

Comme on a déjà dit, si le résultat est maintenable et satisfait le client dans les délais, le reste n'est que littérature.

Si tu as réussi à remplir ces 2 objectifs, hélas souvent difficile à concilier dans un contexte professionnel tendu, c'est que, pour reprendre la métaphore pertinente de B.AF, tu as réussi ton soufflé.

[el_slapper]

(.../...)

Je travaille dans une entreprise comportant une dizaine de centres informatiques régionaux, une centaine de centres départementaux, des centaines d'applications métiers front-end, des process de production complètement automatisés, et des interactions complexes avec des entreprises tierces. Comment fait-on pour comprendre et appréhender sous une forme synthétique ne serait-ce qu'une fraction d'un tel ensemble sans employer une quelconque forme de modélisation ? En relisant toutes les lignes de code et en épluchant les bons de livraison fournisseur ?
(.../...)

Je suis globalement d'accord avec souviron, sauf sur ce point là. Quand le système d'information devient massif(plusieurs milliers de personnes à l'informatique dans une grande banque française), une nouvelle couche d'industrialisation est obligatoire pour retrouver ses petits. Le programme est une industrialisation d'un processus métier, mais l'informatique elle-même est à industrialiser. Pas pour qu'elle soit meilleure(au contraire, ça pousse à des standards pas toujours adaptés), mais pour qu'elle soit gérable. Mieux vaut 2 mauvais projets compatibles que deux bons incompatibles..... Évidement, dans la PME du coin, le raisonnement ci-dessus n'a aucun sens.

[B.AF]

Je suis globalement d'accord avec souviron, sauf sur ce point là. Quand le système d'information devient massif(plusieurs milliers de personnes à l'informatique dans une grande banque française), une nouvelle couche d'industrialisation est obligatoire pour retrouver ses petits. Le programme est une industrialisation d'un processus métier, mais l'informatique elle-même est à industrialiser. Pas pour qu'elle soit meilleure(au contraire, ça pousse à des standards pas toujours adaptés), mais pour qu'elle soit gérable. Mieux vaut 2 mauvais projets compatibles que deux bons incompatibles..... Évidement, dans la PME du coin, le raisonnement ci-dessus n'a aucun sens.

Si je prend une de ces boites justement il y a peu, un des "grands architectes" m'a expliqué que finalement ils avaient abandonnés hibernate au profit d'outils "plus simples" (dixit). Ils ont recentrée leur activité sur un SGBD, et monté un pôle de compêtence "accès aux données", avec des formations business intensives aux développeur qui donnent d'excellent résultat. Je ne dis pas que c'est mon approche favorité, mais c'est un bon exemple de la vie de tous les jours qui prouve que la solution n'est pas technique, mais décisonnelle. La décision étant ici :
- De réduire les risques de modélisation (connaissances métiers)
- De réduire les redondances (dépôt de domaine)
- De réduire les risques technolgiques

Après il y a la réalité aussi

[SQLpro]

Posez-vous les bonnes question...
Posez vous la question de savoir qu'est ce qui est bon pour la qualité des développements ?
Posez vous la question de la pérénité des outils ?
Que voyez vous ?

Moi je voit des sytèmes stables, parce que matures et rarement remis en question même si on tente de le faire croire. Je voit dans ce lot les SGBD en particulier (30 ans aujourd'hui...). Les épyphénomène tel que le cloud computing avec Azure ou BigTable, n'étant que des bluff marketing et ne remettent pas du tout les fondements des bases de données relationnelles...
A côté de cela je voit tout un tas de systèmes instables basé sur des frameworks... Renouvellement technologique tous les 6 mois ! Vous avez dit stabilité ???

Si vous voulez édifier un bâtiment, préférez vous le faire sur du sable mouvant, ou bien sur une dalle en béton armé ?

Quand aux centaines de tables qu'il faut traverser pour accéder à une donnée dans un modèle relationnel, moi je me pose la question suivante : si tel est le cas, alors c'est qu'il y a besoin d'un modèle relationnel. Donc autant le faire le mieux possible. Parce qu'il n'existe qu'une seule alternative : soit tout mettre à plat, soit réaliser un vrai modèle relationnel. Les gens qui tentent une approche hybride ou bien n'accordent aucune importance à la qualité du modèle (par exemple lorsqu'il oublient de le concevoir et laisse faire un ORM), se retrouvent tôt ou tard piègés et s'avère benoitementg insatisfait des possibilité du SGBDR alors qu'ils l'ont sciemment ignoré !

A +

[B.AF]

Posez-vous les bonnes question...
Posez vous la question de savoir qu'est ce qui est bon pour la qualité des développements ?
Posez vous la question de la pérénité des outils ?
Que voyez vous ?

Moi je voit des sytèmes stables, parce que matures et rarement remis en question même si on tente de le faire croire. Je voit dans ce lot les SGBD en particulier (30 ans aujourd'hui...). Les épyphénomène tel que le cloud computing avec Azure ou BigTable, n'étant que des bluff marketing et ne remettent pas du tout les fondements des bases de données relationnelles...
A côté de cela je voit tout un tas de systèmes instables basé sur des frameworks... Renouvellement technologique tous les 6 mois ! Vous avez dit stabilité ???

Si vous voulez édifier un bâtiment, préférez vous le faire sur du sable mouvant, ou bien sur une dalle en béton armé ?

Quand aux centaines de tables qu'il faut traverser pour accéder à une donnée dans un modèle relationnel, moi je me pose la question suivante : si tel est le cas, alors c'est qu'il y a besoin d'un modèle relationnel. Donc autant le faire le mieux possible. Parce qu'il n'existe qu'une seule alternative : soit tout mettre à plat, soit réaliser un vrai modèle relationnel. Les gens qui tentent une approche hybride ou bien n'accordent aucune importance à la qualité du modèle (par exemple lorsqu'il oublient de le concevoir et laisse faire un ORM), se retrouvent tôt ou tard piègés et s'avère benoitementg insatisfait des possibilité du SGBDR alors qu'ils l'ont sciemment ignoré !

A +

Super comme approche....Et dans ce cas, on reste en cobol aussi.
Le tas de système instable basé sur des Frameworks, c'est vraiment fait exprès ?
Hibernate a plus de 9 ans, topplink depuis 9 ans,ADO.Net 8 ans...

L'image avec le bâtiment est benoite : le matériaux est à déterminer à priori. C'est le travail de l'architecte.

Pour faire mieux, on peut avoir une base dont le modéle est parfait, mais dont l'exploitation est mauvaise, et réciproquement.

Le tout SQL n'est pas une solution viable dans tous les cas, et si ce n'est pas le cas, il faut aussi reconnaitre l'existance d'autres solutions et savoir s'en servir avant de les jetter avec l'eau du bain.

C'est le cas des caches distribués (memcache, probablement un truc encore instable qui tient wikipédia), des systèmes sur gros volumes (genre ebay qui découvre que les transactions sont un goulet d'étranglement).

C'est aussi la question du commit et du rollback et d'une façon générale de l'utilité de la transaction :
Si j'ai analysé correctement tous les workflows métiers et si j'ai pris en compte tous les risques de locks, pourquoi devrais-je prendre la sécurité de pouvoir annuler une transaction ? C'est intellectuellement superflu ?

Dans SQL 2005 et 2008 avec des sp en .Net, on peut faire des horreurs. La distribution de services depuis la base peut être une cata!

L'essentiel d'un code base c'est de contrôler l'intégralité des éléments et que l'ingénierie soit cohérente.

[pseudocode]

Moi je voit des sytèmes stables, parce que matures et rarement remis en question même si on tente de le faire croire. Je voit dans ce lot les SGBD en particulier (30 ans aujourd'hui...). Les épyphénomène tel que le cloud computing avec Azure ou BigTable, n'étant que des bluff marketing et ne remettent pas du tout les fondements des bases de données relationnelles...
A côté de cela je voit tout un tas de systèmes instables basé sur des frameworks... Renouvellement technologique tous les 6 mois ! Vous avez dit stabilité ???

C'est plutot une réflexion pour la discussion sur le débat "No-SQL".

Qu'on utilise une BDDR connue, un simple btree, ou la toute dernière techno de persistance en ligne, le problème de la modélisation reste entier.

Je ne vois pas en quoi utiliser une modélisation SQL rend les choses plus simple quand il s'agit de modéliser des relations ternaires.