Pour compléter cinephil, voir l'article que j'ai consacré à cette technique : http://blog.developpez.com/sqlpro/p9...apping_ro_dire
A +
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pour compléter cinephil, voir l'article que j'ai consacré à cette technique : http://blog.developpez.com/sqlpro/p9...apping_ro_dire
A +
Les Bdd épaisses posent de gros problèmes :Envoyé par CinePhil
- la scalabilité est verticale --> coût d'exploitation explosif si on veut accroître notablement les perfs
- portage difficile, voire quasi impossible
- le risque permanent de tomber dans le développement sac de noeuds.
- la difficulté de faire du test unitaire, et les tests fonctionnels peuvent être extrêmement compliqués, voire impossibles dès lors que le schéma devient un tant soit peu complexe
De ce que je sais, ces deux derniers points sont une des raisons pour laquelle une grande banque française a redéveloppé son système financier en dehors de la base principale.
A mon sens, le meilleur compromis est de développer un maximum de l'applicatif en-dehors de la base, et de n'écrire des proc stockées que là où ça a du sens pour de l'optimisation ou des batchs. Une autre approche serait de découper l'applicatif en plusieurs bases de données avec chacune des responsabilités limitées, et faire communiquer ces bases uniquement via des interfaces définies proprement, de sorte que les bases peuvent être sur différents serveurs (Service Oriented Architecture) plus facilement testables.
Visiblement vous êtes très en retard sur l'évolution des technologies...
- Aujourd'hui il existe de nombreuses solutions pour une scalabilité horizontales. Mais la verticale coute beaucoup moins chère et benéficie d'un meilleurs MTBF. Prenons par exemple Centipede qui propose des solutions à plusieurs nœuds SQL Server avec des clients ayant des bases de données comprises entre 100 et 600 To
- Pour le portage le SQL est plus portable que n'importe quelle autre technologie puisqu'il est normalisé. Ce n'est pas du tout le cas des produits NoSQL !
- Le développement sac de nœud est due uniquement au manque de formation des développeurs. Il y a moins de risque en pratique car il y a moins de code à développer une solution en BD épaisse plutôt qu'en pur objet.
- Les tests fonctionnels ont toujours le même problème quelque soit la techno de BD utilisée.
- Enfin il existe SODA : Service Oriented Database Architecture et SQL Server le propose en standar dans toutes les version de SQL Server pour automatiser l'envoi de message asynchrone, transactionnés et sérialisés entre serveurs SQL...
Bref, commencez par vous former. Vous êtes visiblement en retard sur les technologies !
A +
Les bdd épaisses ont l'avantage de mettre une grosse barrière à l'entrée sur la compétence des développeurs. A compétences équivalente, la qualité sera la même entre une bdd épaisse et du SOA.
Dans les deux cas, trouver des gens compétents est la problématique.
La scalabilté verticale est moins chère pour les RDBMS payants, mais pas pour les gratuites, raison pour laquelle MySQL est si largement utilisé pour faire du sharding.
Oui mais pas pour les langages de procédures stockées.[*]Pour le portage le SQL est plus portable que n'importe quelle autre technologie puisqu'il est normalisé. Ce n'est pas du tout le cas des produits NoSQL !
Vous avez sans doute raison sur le problème du manque de formation, mais il se trouve que c'est comme ça: on trouve plus facilement des architectes et des codeurs Java que des architectes et des codeurs PL/SQL ou l'équivalent SQL server (TSQL ?).[*]Le développement sac de nœud est due uniquement au manque de formation des développeurs. Il y a moins de risque en pratique car il y a moins de code à développer une solution en BD épaisse plutôt qu'en pur objet.
C'est bien possible, je ne connais pas tout ce qui se fait sur le marché, loin s'en faut.Bref, commencez par vous former. Vous êtes visiblement en retard sur les technologies !
A +
C'est un avantage ou un inconvénient: c'est bcp plus difficile et coûteux pour un gros projet d'embaucher uniquement des experts base de données que des développeurs juniors en Java/C#.
Ca c'est vraiment un discours d'une haute stupidité. En gros vous dites, puisque mes développeurs sont incompétent, choisissons ce qu'il savent faire quitte à faire de la merde...
Et je me marre, car c'est justement là ou je gagne pas mal de fric à rectifier les conneries de développeurs ! Car le problème ce que la base de données c'est juste indispensable. Donc ne pas investir dessus est totalement suicidaire... D 'autant plus que la formation du salarié à son poste de travail est une obligation légale et qui plus est remboursée par les OPCA !!!
A +
J'ai vécu deux expériences sur DB2, où les BDD dataient des années 1970. Rien qu'a voir les noms des champs, on a envie de partir en courant.
Si une BDD est mal conçue, il y a vraiment intérêt paradoxalement de la rendre épaise.
Ce qu'on ne peut nier avec les ORM, c'est qu'en général les MCD sont mieux faits ... qu'avant ... car ils sont générés automatiquement à partir d'un logiciel. Je ne discute pas des affinages qui peuvent être faits par un expert en BDD, mais voilà, dans les entreprises, ceux qui décident ont souvent des piètres compétences en merise.
Dans certaines entreprises, l'utilisation d'un ORM est l'occasion de refondre la BDD, autrement dit c'est quand même mieux qu'avant.
ORM.
Bonsoir,
est-ce qu'il serait possible d'avoir un exemple ? J'ai de gros doutes car j'ai déjà eu l'occasion de voir le travail d'un ORM et le résultat était horrible, mauvais typage, pas de convention de nommage (alors que les développeurs sont très sensibles sur ce point)... Mais je peux me tromper. Je me permets également de rajouter que la modélisation des données entraîne également une normalisation (le travail sera plus facile si la modélisation tient la route) or ces tâches demandent du travail, de l'expérience, beaucoup de réflexion et chaque cas (ou presque) est particulier. Dès lors, je vois mal un ORM produire un modèle de qualité.
De plus, il faut également se poser la question du recul (et de la pérennité de l'application), effectivement, l'application Z tourne depuis X jours avec l'ORM Y mais qu'adviendra t-il dans 2 ans lorsque brusquement l'application en question aura vu le nombre d'utilisateurs multiplié par 10 000. La réponse est simple, on placera l'application à la poubelle et on en produira une autre.
Les bases de données relationnelles font partie des technologies matures et qui ont fait leurs preuves. Dès lors, l'intelligence (ou la sagesse) voudrait que l'on se fie à ces technologies plutôt qu'à d'autres technologies dont on a n'a aucun recul, aucun retour d'expérience (question de bon sens ?).
Enfin, DB2 m'apparaît être un excellent produit car c'est l'un des principaux SGBDR et il est très respectueux de la norme. Qu'entendez-vous par le nom des champs fait fuir ? Le choix du nom des colonnes pour une BDD donnée concerne la personne chargée de la création de la base de données. Et, il sera toujours possible d'utiliser les vues pour changer le nom des colonnes.
Le problème de fond est le suivant : le niveau de connaissance concernant les bases de données relationnelles (modèle relationnel, SQL, modélisation, architecture d'un SGBDR, architecture des ordinateurs...). Et bien évidemment la question de la mode...
En espérant ne pas me tromper.
J'avais peur de mal comprendre le message de Chaplin mais je vois que je ne suis pas le seul à avoir compris ça...
Ceci veut-il dire qu'on fait le modèle CONCEPTUEL de données après avoir fait l'application ?Ce qu'on ne peut nier avec les ORM, c'est qu'en général les MCD sont mieux faits ... qu'avant ... car ils sont générés automatiquement à partir d'un logiciel.
C'est pas un peu tard ?
Si vous trouvez que ce que fait un ORM est mieux que ce qu'il y avait avant, l'avant devait être à vomir !
En principe, on commence par modéliser les données avec rigueur puis on crée la BDD et les vues qui seront interrogées par le programme. Et de préférence sans Objet Réellement Merdique !
C'est surtout un discours réaliste qui correspond à une réalité économique à laquelle tous les chefs de projets de DSI sont confrontés.
Trouver des DBAs compétents est encore plus difficile que de trouver des développeurs compétents, et en plus ils coûtent chers (loi de l'offre et de la demande). Donc on préfère trouver des archis logiciels compétents, qui sauront limiter les dégats et qui sont plus polyvalents.
Et bien tant mieux ! De quoi vous plaignez-vous ?Et je me marre, car c'est justement là ou je gagne pas mal de fric à rectifier les conneries de développeurs ! Car le problème ce que la base de données c'est juste indispensable. Donc ne pas investir dessus est totalement suicidaire... D 'autant plus que la formation du salarié à son poste de travail est une obligation légale et qui plus est remboursée par les OPCA !!!
A +
De voir de la merde à longueur de journée ! Des maux de tête à répétition ! L'amour des belles choses et des choses bien construites.
Je confirme l'idée du discours réaliste.
Un nom de colonne : dummy_char_1. C'était dans une entreprise avec un DB épaisse et des gens assez compétents. Il n'y avait pas de vues de mémoire. Naturellement c'était un champs de l'ancienne version de la base d'il y a 20 ans mais non repris dans la nouvelle donc il fallait taper dans l'ancienne. Colonne à prendre en compte pour savoir le chiffre d'affaire, donc pas anodin.
Dans la même boite qui avait un bon niveau en SGBD, il y avait des colonnes XML, fatalement le même attribut vient avec des orthographes différentes. Le premier dev devait être en congé ou bien la seconde orthographe avait une sémantique différente oubliée depuis.
D'autres système de notations sont sur 8 caractères, très funky. J'ai déjà vu des notations qui incrémentent les lettres pour signifier une différence de format. Donc d'un nom qui veut dire un truc, ça devient n'importe quoi (IBM diront certains.
J'ai un exemple concret de logiciel très présent dans la finance contenant 1200 tables dont la nomenclature (table et colonnes) ne contient souvent que 4 caractères informatif. Et c'est encore une base que je considère comme bien modélisée.
La réalité c'est que des applications bien faites pour un domaine données, au bout de 10 ans doivent traiter de truc pas prévu à la base et rajoutés itérativement en bourrinant un peu plus à chaque fois. A la fin ça devient n'importe quoi vu que le refactoring n'a j'amais été budgété. Les cahiers des charges bien fait c'est dans la théories et les grosses boites propres. Une discussion avec un VP Marketing dans l’ascenseur c'est des fois le cahier des charges. Qui changera à la prochaine entrevue, remettant en cause tout le modèle (finalement on ne va plus vendre le produit mais faire du SaaS mais sauf si ...).
Quand le fonctionnel ne peut plus être compris par une personne unique, que les équipes ont un peu de rotation, que pour la majorité c'est un travail alimentaire, le tout avec des deadlines impossibles et la qualité décroît et génère de la dette technique.
Bingo Einstein, je reconnais que j'ai fait un post un peu caricatural en parlant d'ORM dans le sens où l'utilisation d'un ORM aurait été moins pire que de laisser quelqu'un concevoir avec sa vision (personnelle) de Merise.
Je dis tout de suite aux inconditionnels de DB2, je ne suis pas la pour faire la guerre, mais Jester a très bien analysé le problème qu'on peut rencontrer dans les entreprises. Je ne cherche pas à généralisé, je dis juste qu'avant 1980-90 (à définir), peu de gens maîtrisaient SQL, ils utilisaient des fichiers DDS ou DDL, quelqu'un me corrigera avec sa science DB2.
Combien d'entreprises utilisent des vues? Personne de ceux que j'ai vu, mais mon expérience n'est pas significative, no problem.
Finalement, je pourrais citer un exemple concret, à quoi ça sert, j'étais témoin sans y être impliqué, mais bon ils avaient pas mal de souci, et là messieurs, vous avez 100% raison.
OuiDe plus, il faut également se poser la question du recul (et de la pérennité de l'application), effectivement, l'application Z tourne depuis X jours avec l'ORM Y mais qu'adviendra t-il dans 2 ans lorsque brusquement l'application en question aura vu le nombre d'utilisateurs multiplié par 10 000. La réponse est simple, on placera l'application à la poubelle et on en produira une autre.
Je ne vais pas non plus condamner les ORM. La grosse difficulté dans un projet c'est la documentation et aussi le bon vouloir des DBA qui souvent ne sont pas coopérants, c'est le retour que j'aurais pour le projet en question sans y être impliqué. On pourrait invoquer des divergences de vue entre les DBA et les ingénieurs développement. J'ai parfois l'impression qu'il y a une barrière entre les deux mondes. Ensuite, faire des mise à jour de BDD est plus critique que des mises à jour d'application, c'est le principal frein.
Dans un projet, j'avais réussi à imposer mes points de vu concernant la BDD, ce qui a considérablement soulagé le développement pour l'application. C'était un super travail de collaboration mais qui n'a pas été reconnu car on a jugé mon travail personnel mais pas ma contribution globale qui a soulagé considérablement les développeurs.
Personnellement, j'utilise ObjectDB depuis maintenant 1 an sur un logiciel Java d'analyse de log.
Je suis ravi de la faciliter de mis en oeuvre de cette base de données ainsi que de ces performances.
J'ai déjà fait un certains nombre de projets avec Postgresql et MySQL et ces bases là ne tiennent pas la comparaison sur les deux critères que j'ai cité (surtout la complexité en fait)
Par contre, il me semble utile de préciser certaines choses concernant la mise en compétition entre les BDO et les BDR.
La 1er évidence serait de s'intéresser aux domaines d'utilisation de ces technologies.
En effet, les BDO ne sont pas faites pour gérer des ensembles peu structurés de données (tel les Data WareHouse par exemple) qui sont le domaine de prédilection des SGBDR.
Inversement, les SGBDR peine à gérer la persistance des objets d'une manière simple. Certes, des progrès ont été fait avec Hibernate qui s'est imposé dans le monde des langages objet comme une solution quasi unique (pour ne pas dire dogmatique) et qui permet de gérer des cas relativement complexes de persistance, néanmoins que d'effort à réaliser pour un résultat souvent mince, surtout si on considère qu'il existe des solutions beaucoup plus simple (ObjectDB) à mettre en oeuvre (essayer au moins une fois et vous verrez)
Donc, pour résumer ma pensé, pour moi les deux solutions doivent exister car les besoins qu'elles assignent sont différents.
Enfin, si les SGBDR sont si écrasants de représentativité c'est peut être parce que :
1) les entreprises sont frileuses à changer de technologie, surtout quand elles sont critiques (je les comprends)
2) le discours ambiant est que les BDO sont peu performantes (où sont les benchmarks ?), on compare quoi, Oracle avec O2 ? n'importe quoi !! et Versant alors c'est de la bouse de cheval peut être ?
3) les habitudes sont dures à perdre : quand vous avez investi du temps (des années) de formation sur une technologie et qu'on vous annonce qu'une autre technologie fais mieux pour moins cher vous avez peut être un peu envie que cette nouvelle techno ne voie pas le jour !
4) les décideurs ont souvent des formations techniques très légères (voire pas du tout) et ne voient donc pas le gain de productivité que peut représenter pour certains projets l'utilisation d'une BDO à la place d'une BDR. La réponse classique de ces gens là est souvent : "je ne vois pas la différence" ou "c'est pareil" ou encore "Machin m'a dit que ça ne vaux pas le coût". Par contre, au bout d'un an ou deux, quand le retard sur le planning devient critique, ils sont bien les premiers (lors de la phase bien connu de tous de recherche de coupable) à reconnaître les problèmes induit par la base de données : lenteurs, lourdeurs du à un schéma de base inadéquat, complexité de certains requêtes que plus personnes ne comprends tout ça pour persister quelques malheureux objets (ça c'est du vécu)
Bref, je n'ai pas l'intention de faire la leçons ç des professionnels mais un peu moins de dogme et un peu plus de courage (voire d’honnêteté) serait le bien venu dans ce monde.
Puisque quelqu'un a déterré ce vieux topic, je réagis sur ce post :
- dans les années 70 DB2 n'existait pas, il est sorti dans les années 80 (1983 d'après Wikipédia)
- les noms des colonnes (et non des champs) ne sont pas le fait de DB2, mais de pratiques du monde mainframe pour lequel DB2 a été conçu. DB2, dans sa version actuelle, supporte des noms de colonnes allant jusqu'à 128 car.
Dans le monde mainframe, les colonnes ont des noms courts (le plus souvent 8 caractères) et codés, on ne raconte pas sa vie pour déclarer le contenant contrairement avec ce qui se pratique beaucoup dans le monde open.
Ce n'est pas un souci quand il existe, et ce devrait être obligatoire, un dictionnaire de données.
Vous voulez sans doute dire l'inverse....Cela dépend de quels SGBDR vous parlez... Avec l'expérience de MySQmerde ou PostGreSQL évidemment c'est pas gagné. mais avec SQL Server ou Oracle et les technologies In Memory c'est très différent et surpasse me^me certains SGBD nNoSQL....Inversement, les SGBDR peine à gérer la persistance des objets d'une manière simple.Alors là je pisse de rire, car les performances d'Hibenate sont tellement lamentable que certaines entreprise en fait faillite en misant dessus !Certes, des progrès ont été fait avec Hibernate qui s'est imposé dans le monde des langages objet comme une solution quasi unique (pour ne pas dire dogmatique) et qui permet de gérer des cas relativement complexes de persistanceSur quelles études benchmarks ou autre analyse pragmatique et indépendantes vous basez vous pour de telles affirmations ?
Enfin, si les SGBDR sont si écrasants de représentativité c'est peut être parce que :
1) les entreprises sont frileuses à changer de technologie, surtout quand elles sont critiques (je les comprends)
2) le discours ambiant est que les BDO sont peu performantes (où sont les benchmarks ?), on compare quoi, Oracle avec O2 ? n'importe quoi !! et Versant alors c'est de la bouse de cheval peut être ?
3) les habitudes sont dures à perdre : quand vous avez investi du temps (des années) de formation sur une technologie et qu'on vous annonce qu'une autre technologie fais mieux pour moins cher vous avez peut être un peu envie que cette nouvelle techno ne voie pas le jour !
4) les décideurs ont souvent des formations techniques très légères (voire pas du tout) et ne voient donc pas le gain de productivité que peut représenter pour certains projets l'utilisation d'une BDO à la place d'une BDR.L'une des causes de l'adoption majeur des SGBDR est aussi sa fiabilité (loin devant les SGBDO et NoSQL)La réponse classique de ces gens là est souvent : "je ne vois pas la différence" ou "c'est pareil" ou encore "Machin m'a dit que ça ne vaux pas le coût". Par contre, au bout d'un an ou deux, quand le retard sur le planning devient critique, ils sont bien les premiers (lors de la phase bien connu de tous de recherche de coupable) à reconnaître les problèmes induit par la base de données : lenteurs, lourdeurs du à un schéma de base inadéquat, complexité de certains requêtes que plus personnes ne comprends tout ça pour persister quelques malheureux objets (ça c'est du vécu)
Bref, je n'ai pas l'intention de faire la leçons ç des professionnels mais un peu moins de dogme et un peu plus de courage (voire d’honnêteté) serait le bien venu dans ce monde.
L'autre est "l'inertie" des données. Lorsque l'on a des bases de plusieurs dizaines de To on en change pas d'un claquement de doigt !
A +
Répondre avec citation
Partager