Discussion :

[raynord]

Bonjour à tous,

Je suis un ingé en qualité qui réalise l'audit d'un projet espagnol, un ERP fortement inspiré de SAP, qui gère les rennes de tous les départements de la boite.

Les responsables du chef de projet se sont rendu compte que la documentation du projet était plus qu'insuffisante et nous ont embauchés afin de réaliser la documentation du projet.

Après avoir terminé avec les pré-requis fonctionnels je me suis penché sur la base de donnée du projet dont la documentation était inexistante (pas de MCD, rien, impossible de connaitre le pourquoi du comment de chaque table).

J'ai effectué un "reverse engineering" de la base avec Toad Data modeler.
Cette base de données de 6 go de données composée de 330 tables ne possède aucune relation.

J'ai donc demandé au chef de projet qui m'a confirmé l'absence de relations en argumentant que les bases de données enormes d'ERP n'ont généralement pas de relations afin de faciliter les taches de maintenance et de pouvoir adapter l'application rapidement en cas de modification des pré-requis.
Il m'a même cité SAP en disant que les bases de données de cet ERP ne possédait pas de relations et que c'est le code de l'appli qui garantissait l'intégrité des données.

N'ayant travaillé qu'avec des bases beaucoup moins volumineuses je ne peux pas mettre en doute ses propos.

Est-il dans le vrai?
Une base de données sans relation ne met elle pas en danger l'intégrité de la table?
L'exemple de SAP est un fait prouvé?

Merci par avance.

[SQLpro]

L'absence de MCD est généralement la preuve reine d'une mauvaise modélisation introduisant généralement de la redondance et des anomalies transactionnelles dont une base fonctionnellement incohérente.

Notez que votre terminologie est TOTALEMENT innapropriée :

"ne possède aucune relation. "

Une relation est un objet mathématique porteur de données dans l'univers des bases de données relationnelles. Vous voulez sans doute parler d'intégrité référentielle qui se traduit en SQL par des contraintes de type FOREIGN KEY.

J'ai donc demandé au chef de projet qui m'a confirmé l'absence de relations en argumentant que les bases de données enormes d'ERP n'ont généralement pas de relations afin de faciliter les taches de maintenance et de pouvoir adapter l'application rapidement en cas de modification des pré-requis.

En aucun cas cela n'a d'impact. Mais l'absence d'un modèle de données et de l'outil de modélisation qui va avec conduit à ce genre de pratique d'un autre age. Contrairement aux idées reçues, les contraintes permettent même d'améliorer les performances des bons SGBDR ! Y compris les contraintes de type FK.

Il m'a même cité SAP en disant que les bases de données de cet ERP ne possédait pas de relations et que c'est le code de l'appli qui garantissait l'intégrité des données.

Ce n'est en aucun cas un gage de bonne pratique et le fait de réaliser ces contraintes pas l'application pénalise fortement l'application. Mais hélas beaucoup d'éditeurs considèrent la base de données comme un simple espace de stockage à la manière de Cobol, justement parce que beaucoup d'applications datent de cette époque et ont été portée en environnement SGBDR...
Cela ne garantie d'ailleurs pas la cohérence de la base par exemple lors des phases initiales de reprise de données par exemple, puisque l'application ne peut présumer de la façon dont les données antérieures seront reprise.
Dans les audit que j'ai mené (voir les différents article que j'ai écrit), ce type d'argumentaire est immédiatement démoli par quelques requête montrant certaines lignes orphelines (il y en a toujours dans ce type d'appli).

Est-il dans le vrai?

Absolument pas. Il a 20 ans de retard et s'est arrêté à Cobol...
Hélas la culture SGBD relationnelle est peu fréquente et les personnes qui savent en tirer partie très rare...

Une base de données sans relation ne met elle pas en danger l'intégrité de la table?

Pas de la table, mais de la base !

L'exemple de SAP est un fait prouvé?

Je crois que oui, mais il me semble que l'on peut forcer le système afin qu'il les mettent en place au sein de la base. Ceci ayant été fait pour des question de portage afin que le système puisse fonctionner même sur des bases dénuées de contraintes, et non pas parce que c'est pas bien !!!!

A +

[raynord]

Merci beaucoup pour votre réponse constructive, elle confirme mes doutes! Et effectivement ma terminologie était mauvaise.

[Fabien Celaia]

+1 pour les commentaires de SQLPro !

Pour reprendre les exemples sur SAP et les ERP en général: généralement, ces progiciels viennent avec tous leurs modules, et l'utilisateur n'utilise que les modules/tables associées qui lui sont utiles.

C'est donc par souci de simplification qu'aucune RI n'est implémentée dans le modèle.

Tant que tous les accès se font au travers de l'application, la méthode est discutable mais encore acceptable.

Du moment qu'une modification peut intervenir directement dans les données , elle ne l'est plus et l'intégrité des données n'a plus de garantie.

D'un point de vue modélisation, la quasi totalité des ERP sont un modèle de ce qui ne doit pas être fait .
Ex: Peoplesoft = 20'000 (et autant de vues) tables sans liens entre elles
Oracle eBusiness = 24550 tables sans liens entre elles

[SQLpro]

Le mieux en la matière était ADONIX : chaque fois qu'un nouveau client était ajouté il y avait création d'un nouveau schéma SQL avec quelques dizaines de tables associées.
Bref, bonjour la maintenance !!!

A +

[bacchus41]

Absolument pas. Il a 20 ans de retard et s'est arrêté à Cobol...
Hélas la culture SGBD relationnelle est peu fréquente et les personnes qui savent en tirer partie très rare...

A +

Bonjour,

Je travaille sur un gros projet Cobol/DB2, et l'utilisation de FK est une règle.
Toutes les tables sont liées entre elles, c'est beaucoup plus sur pour l'intégrité des données, on est jamais a l'abris d'un oubli dans le code, alors la FK est la pour sécuriser le tout...

[B.AF]

Oui enfin il faut modérer un peu aussi le fait que les contraintes relationnelles impliquent peu d'abstraction et que le principe d'un éditeur c'est de faire un produit commun à x utilisateurs.

De la même façon, il existe des produits qui sont aujourd'hui impossible à maintenir parce que trop de relations, trop de triggers, trop de sp...

En plus à débugger au quotidien, le SQL c'est une plaie incommensurable.
Sans parlers des plans d'exécution ...

C'est facile d'expliquer à des gens aujourd'hui qui ont fait une appli il y a 10 ans qu'ils ne comprennent rien est qu'ils sont has been. Peut être aussi qu'à l'époque, tout n'était pas parfait...

En 2009, mettre du traitement métier dans la base, c'est d'un tel anachronisme et d'un tel niveau de risque que je préfére 100 fois une application dont le sgbd est juste des tables sans relations et sans contraintes, avec des objets clairs et des tests fonctionnels, qu'un gros SGBD à 800 tables, avec ses objets temporaires, triggers, appels à n niveaux de sp,etc,etc....

Et à plus forte raison si la base dépasse les centaines de Go.

Combien ici ont du développer des softs à hautre dispo avec un sgbd et ont laissé sur la bas côté la gestion des verrous et des locks ?

Le SGBD c'est le mal nécessaire de l'informatique d'entreprise.

[SQLpro]

Je pense malheureusement que vous êtes totalement à côté de la plaque !!!!

hélas de nombreuses personnes dont la compétence en matière de gestion de données frise le vide absolu ont la même vision que vous.

En plus à débugger au quotidien, le SQL c'est une plaie incommensurable.

C'est un simple problème de formation. Pourriez vous débuguer du Cobol ? Pourtant pendant 25 ans ce langage fur l'objet de chaine de programmes composé de centaines de milliers de ligne... Pour ma part je débogue le SQL sans aucun problème. Question de formation et de méthode... Sans doute est-ce has been d'avoir une méthode et préférez vous les absconcerries de la syntaxe des langages comme C++, java ou C#...

Sans parlers des plans d'exécution ...

Expliquez vous ??? Cela ne veut rien dire...

En 2009, mettre du traitement métier dans la base, c'est d'un tel anachronisme...

Victime de la mode ? C'est votre choix... Soyons sérieux ! Aujourd'hui le modernisme serait plutôt d'en remettre un max vu les faiblesses dramatiques des ORM. Au moins ayez l'honnêteté de vous cultiver, lisez ces articles :
http://thehelsinkideclaration.blogsp...vc-part-2.html
http://www.dulcian.com/Articles/Thic...ited_final.htm

Combien ici ont du développer des softs à hautre dispo avec un sgbd et ont laissé sur la bas côté la gestion des verrous et des locks ?

Quelques sites à haute dispo 24/24 avec forte volumétrie : les pompiers de paris, service de gestion des appels. Amadeus : service mondial de réservation de place d'avions (24/24 très forte volumétrie). Cela vous suffit-il ? ... Fnac.com, ooshop.com, Euridile/Inpi (registre des société, marques brevets...). Toutes ces applications, tous ces sites fonctionnent avec une ou plusieurs bases SQL Server comportant plusieurs centaines de Go à quelques téras...

Extrait d'un article que je doit faire paraître ces jours prochains :

********

INTRO :
Il y a quatre ans, un article intitulé La fin des bases de données relationnelles nous expliquait que les serveurs de SGBDR étaient le point faible des architectures à plusieurs niveaux, et devaient donc disparaître dans un futur proche pour laisser la place aux serveurs d'applications. L'auteur qualifiait même d'"arnaque intellectuelle" le concept de bases de données...
Force est de constater qu’il n’en est rien, mais que les technologies bien mûres des bases de données ont donné de beaux fruits, à condition de savoir les apprécier, ce qui semble encore loin d’être le cas. Explication d’un concept dont l’avenir est très prometteur.

...

3 - Où placer le code métier ?

Maintenant que nous savons que la base de données est bien plus intelligente que nous le pensions, voyons comment aborder ce vieux débat où les avis divergent. Soyons encore une fois pragmatique et n'hésitons pas à expérimenter la chose.
Considérons une application Web utilisant un SGBD relationnel de haut niveau permettant d'utiliser toutes les techniques modernes. Ajoutons autant de serveurs que nous voulons...
Dans une telle configuration, on peut répartir le code en au moins trois endroits : sur le client, sur le SGBDR et enfin sur tous les serveurs intermédiaires entre les données et le client. Qu'il y ait, un, deux ou trois serveurs intermédiaire – que nous appellerons tiers – n'apporte aucun changement majeur, dans le sens où nous espérons que chacun des serveurs s'est spécialisé dans une tâche et que le développeur a bien fait son travail (par exemple serveur d'objet "métier" COM, DCOM, CORBA, EJB, .net, serveur de présentation pour le rendu Web, serveur d'application à distance...).

...

Il s'ensuit une analyse des retours d'expériences menées par l'auteur en comparant les développements conçus par l'approche traditionnelle et celle du concept de développement épais côté bases de données.
Et le constat fait froid dans le dos...
o réduction par un facteur 3 à 4 des lignes de code client, donc réduction potentielle par ce même facteur des bugs non encore découverts;
o division par un facteur 10 à 100 des temps de réponse du système;
o réduction par un facteur 2 à 3 du temps global de développement.
Le seul inconvénient de cette approche réside dans le fait qu'il convient que les acteurs d'un tel projet maîtrisent les techniques des bases de données relationnelles, ce qui est rarement le cas !
On l'a compris, les avantages majeurs de cette approche sont la concision du code et l'absence d'aller et retour réseau entre le code métier et la base de données. Bref performance, qualité et économie...


...


6 – Pourquoi pas un ORM ?

Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met, les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. Quant à la qualité des requêtes SQL les connaisseurs apprécierons : du fait qu'il faut être compatible avec tout un tas de SGBDR, le nivellement se fait par le bas. Mieux : pour les plus mauvais ORM, tous les arguments sont passés à titre de chaîne de caractères ce qui rend les index de la base inopérant ! Enfin, les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données. Mais c'est à près tout très logique... Christian Soutou, professant à l'université de Toulouse le Mirail, me montrait un tutorial de Serge Tahé pour apprendre la persistance dans Java : près de 305 pages pour décrire le fonctionnement du système et les problèmes potentiels... Vous avez dit RAD ? Il est vrai qu'en SQL on ne dispose que de quelques instructions pour faire la même chose avec la rapidité et la performance en plus...

En fait, à cause de ce genre d'outils et de l'unique pensée objet, un grand nombre de développeurs n'ont plus aucune vision de ce qu'est un modèle de données. Pour preuve, certains demandent sur les forums quels sont les design pattern pour modéliser les données d'un client... tandis que d'autre piégés par leur ORM et dans l'incapacité de savoir ce qui s'y passe derrière, vont droit au mur, comme cet internaute qui cherche désespérément à augmenter les ressources de PostGreSQL, afin que la requête générée par Hibernate puisse contenir plus de 1664 colonnes !
Enfonçons le clou un peu plus avec l'immédiat avenir de l'informatique que je prédis fort peu propice aux ORM et aux frameworks... Constatons qu'en matière de ressource, les ordinateurs ne peuvent plus croître sur la simple fréquence du processeur. Aujourd'hui il n'est pas physiquement possible d'aller au delà de quelques giga hertz pour les cadencer. Ceci induit que le seul moyen de faire croitre la puissance de calcul est d'augmenter le nombre des CPU. Or les ORM ne disposent d'aucun mécanisme transparent pour exploiter pleinement le multi processing. Ainsi l'exécution d'un traitement complexe découlant d'une règle métier sera difficile à paralléliser. Alors que dans un SGBDR les moteurs en jeu tirent partit du maximum de CPU à disposition, et cela sans écrire la moindre ligne de code pour les en prier ! C'est la grande force de la nature ensembliste des traitements en bases de données...


...


Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les geek de s'affirmer, et pour les développeurs de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leur ignorance.
Quant à l’argument qui consiste à dire que la maintenabilité du code d’un langage client est bien plus simple que du SQL, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, rendu les développeurs inapte au codage dans un SGBDR, pour avoir parfois choisi les mauvais outils, on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

...

Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…

...

En conclusion

Avec l'explosion des langages, ORM et frameworks, on doit se poser la question du ratio de l'investissement de formation nécessaire par rapport au code effectivement produit. Si l'on continue sur cette voie il faudra bientôt que les développeurs passent la moitié de leur temps de travail en formation, à moins finalement que l'on ne décide de les employer que quelques années juste après leur sortie de l'école et qu'on ne les jette après usage comme un kleenex...
Plus grave, cette position folle du code nouveau va à l'encontre de toute solution de pérennité pour les applications développées : il y a fort à parier que de telles applications seront de moins en moins maintenables dans le temps . Mais il est vrai que la mode est au trash logiciel...
Cela serait-il dû à la prolétarisation de l'informatique comme le dit si bien Christian Fauré dans son article "la prolétarisation dans les sociétés informatiques" ?

Les différents métiers que j'ai pratiqué, m'ont appris quelque chose : on en revient toujours au fondamentaux... Telle est la leçon qui devrait être enseignée à tout informaticien. Certes les choses évoluent, et en informatique plus vite que dans tout autre métier. Mais c'est justement pour cela qu'il est souhaitable de ne jamais perde de vue les fondements même de l'édifice informatique. Or les basiques en la matière reposent essentiellement sur les données : après tout ce sont bien les données qui sont le moteur informatique de l'entreprise et non l'inverse. Une entreprise sans programmes mais avec données peut encore s'en tirer, mais sans données que saurait-elle faire de ses programmes ?
Il convient donc de tout faire autour des données, ce que certains ont appelé l'approche data centric, bref concevoir des modèles de données fiables et gérer la qualité des données. En y rajoutant les concepts de développement en base de données épaisse nous avons réuni toutes les garanties de pérennité, performance et fiabilité. Mais le SGBDR peut-il aujourd'hui tout faire ? En matière d'informatique de gestion, la réponse est assurément oui. Mais combien savent ce qu'est capable de faire un tel outil ? Qui sait que les SGBDR les plus modernes incorporent aujourd'hui le XML nativement, un SIG performant, un outil d'indexation textuel ou encore des services web ?

....

A +

[Mat.M]

J'ai donc demandé au chef de projet qui m'a confirmé l'absence de relations en argumentant que les bases de données enormes d'ERP n'ont généralement pas de relations afin de faciliter les taches de maintenance et de pouvoir adapter l'application rapidement en cas de modification des pré-requis.

D'un point de vue pratique on enlève les relations entre tables parce que bien souvent les enregistrements connexes sont requis..

Par exemple sous un petit SGBD comme Access c'est un peu casse-pied de mettre des relations sinon on a sans arrêt des messages d'erreur.

Ceci dit je rejoins l'avis des autres une telle base de donnée telle qu'elle est décrite c'est une analyse déficiente ou bien un MCD absent..

Une base de données sans relation ne met elle pas en danger l'intégrité de la table?
Merci par avance.

Tout dépend si telle ou telle table de la base de donnnées a besoin d'une clé étrangère provenant d'une autre table pour son intégrité.
Mais une base de donnée digne de ce nom s'il n'ya pas de relations entre les tables oui l'intégrité des données risque d'être compromise.
Et comme le dit SQLPro si on met des contraintes les performances seront accrues.
Mais une base de données sans relation cela ressemble à un canard boiteux.

[Mat.M]

Absolument pas. Il a 20 ans de retard et s'est arrêté à Cobol...
Hélas la culture SGBD relationnelle est peu fréquente et les personnes qui savent en tirer partie très rare...

Mais ne crois-tu pas que cela traduit une carence de formation ?

Je ne comprends pas il y a des tas de personnes qui sortent de formation ( ne vous inquiétez pas je suis passé par là aussi ) avec des diplomes Bac4/5 on les met sur des projets et ils maitrisent à peine les concepts inhérents aux bases de données ( intégrité référentielle,MCD...)
Ceci est un autre sujet pardonnez-moi de faire du HS

[SQLpro]

En professionnel de la chose et surtout en tant qu'enseignant pour une école d'ingénieur et pour le CNAM, je dirais simplement la chose suivante :
En 5eme année d'ingéniorat j'ai 40 heures de cours à donner dans lequle je devrais en principe faire :

• les bases de données relationnelles
• la modélisation de données
• le langage SQL
• les transactions
• le décisionnel
• la qualité des données

avec cours et TP...

Croyez vous franchement que ce nombre d'heure soit suffisant ?

malheureusement c'est le cas de la majorité des écoles d'ingé et des enseignements universitaires....

A +

[Mat.M]

oups je n'avais pas vu que vous étiez prof donc très spécialiste dans la matière.
C'est vrai que 40heures cela fait juste avec les TP mais ceci est un tout autre sujet

Le mieux en la matière était ADONIX : chaque fois qu'un nouveau client était ajouté il y avait création d'un nouveau schéma SQL avec quelques dizaines de tables associées.
Bref, bonjour la maintenance !!!

A +

hé ho j'ai bossé dans une SSII en Rhone Alpes spécialisée Adonix et ça tourne encore

Toutes ces applications, tous ces sites fonctionnent avec une ou plusieurs bases SQL Server comportant plusieurs centaines de Go à quelques téras...

Désolé de dévier du sujet mais dois-je en conclure que SQL Server c'est un produit qui tient la route alors et n'a pas peur de la comparaison avec Oracle ?

Annual sales goals for 300 sales persons were calculated by the completed application in about 20 minutes. The system made about 5000 round trips from the application server to the database in order to run the routine. Most the most significant performance problems were due to poorly coded SQL. After refactoring and tuning the SQL, the application required only 20 seconds to execute

Sans commentaire !

[Luc Orient]

... Combien ici ont du développer des softs à hautre dispo avec un sgbd et ont laissé sur la bas côté la gestion des verrous et des locks ?

Mais vous voulez dire quoi là ?

[Jester]

Victime de la mode ? C'est votre choix... Soyons sérieux ! Aujourd'hui le modernisme serait plutôt d'en remettre un max vu les faiblesses dramatiques des ORM. Au moins ayez l'honnêteté de vous cultiver, lisez ces articles :
http://thehelsinkideclaration.blogsp...vc-part-2.html
http://www.dulcian.com/Articles/Thic...ited_final.htm

Ce sont des liens sur des boites de consultants SGBD, c'est donc fortement biaisé. On peut par exemple citer un petit descriptif du data warehouse de facebook qui est basé sur hadoop http://www.dbms2.com/2009/05/11/face...doop-and-hive/ . Et ce genre d'architecture on the cloud semble relativement à la mode. Il n'est plus question de mal utiliser des relations, mais de ne plus en avoir du tout, tout devient des couples (key, value). Je trouve cela peu optimal.

Pour les frameworks ORM, ils modélisent les relations dans la base de données (le framework que j'utilise ne modélise pas les check bizarrement par contre). Il est assez répandu d'utiliser des caches comme memcache qu'utilise par exemple facebook au dessus de serveurs mysql. pour palier à des utilisations sous-optimales de la base de données.

Pour ce qui est de la facilité de développement, il ne me semble pas que l'on puisse profiler les exécutions pas à pas des procédures de la base de données, par exemple mettre des break points dans les triggers (peut-être SQL Server?). Il ne me semble pas non plus que l'on puisse faire facilement des test unitaires. Si je ne me trompe pas c'est dommage.

[voran]

Désolé de dévier du sujet mais dois-je en conclure que SQL Server c'est un produit qui tient la route alors et n'a pas peur de la comparaison avec Oracle ?

Pas du tout !
Au contraire, si un SGBD comme SQL Server n'était même pas capable de gérer ce type de volumétrie à notre époque, il serait obsolète ... nuance !

[voran]

oups je n'avais pas vu que vous étiez prof

[SQLpro]

C'est mieux Jester... Vos argument sont un peu plus structurés, mais vos exemples toujours navrant...

Ce sont des liens sur des boites de consultants SGBD, c'est donc fortement biaisé.

Sans doute préférez vous les commentaires des geek du libre qui eux sont payés en sous main par IBM et autres....
Moi je m'intéresse à tous les commentaires et je regarde en pratique ce que cela donne.
De plus j'ai expérimenté ce modèle de développement depuis plus de 10 ans et je n'ai jamais ni problème ni retour négatif de la part de mes clients....

On peut par exemple citer un petit descriptif du data warehouse de facebook qui est basé sur hadoop http://www.dbms2.com/2009/05/11/face...doop-and-hive/ . Et ce genre d'architecture on the cloud semble relativement à la mode. Il n'est plus question de mal utiliser des relations, mais de ne plus en avoir du tout, tout devient des couples (key, value). Je trouve cela peu optimal.

Croyez vous qu'une application aussi peu sensible soit franchement un modèle ? Je veut dire par là que si quelques données sont perdues, tout le monde s'en fou.... Même le "client" puisqu'il n'y en as pas (gratuité du service).
En revanche pour des applications de gestion comme de la compta, des sites web marchand, une banque, c'est plus que vital. Le jour ou vous me citerez un grand site web marchand avec une base de donnée sans contraintes, faites moi signe, j'irais leur donner gratuitement une journée de conseil ! (un cadeau à 1200 €)...

Pour les frameworks ORM, ils modélisent les relations dans la base de données (le framework que j'utilise ne modélise pas les check bizarrement par contre). Il est assez répandu d'utiliser des caches comme memcache qu'utilise par exemple facebook au dessus de serveurs mysql. pour palier à des utilisations sous-optimales de la base de données.

Déjà vous baissez, car vous ne savez pas de quoi vous parlez : le terme relation désigne un objet mathématique porteur de données. Une base sans relation est donc un base sans table. Maintenant vous voulez sans doute parler des contraintes d'intégrité référentielles ou contraintes FOREIGN KEY. Qu'ils permettent de mettre en œuvre une telle contraintes est un minimum, mais cela ne veut pas dire que le modèle de données soit correct... C'est déjà un réel problème. Les outils de modélisation sont fait pour cela et permettent de mettre en évidence certaines erreurs du modèle, ce qu'un ORM est incapable de faire...
De plus et comme vous le citez la plupart ne permettent pas de mettre en oecuvre des contraintes CHECK, qsui sont pour moi, absolument nécessaire. Toute colonne devrait avoir sa contrainte CHECK afin d'éviter de polluer la base avec des données imbéciles. Cela s'appelle la gestion de la qualité des données. Cela coûte très cher lorsqu'on arrive au décisionnel (en général 50% du cout d'un décisionnel est le nettoyage des données relationnelles)
Quand à l'utilisation sous optimale dont vous parlez en citant MySQL c'est pitoyable. Nous savons tous que MySQL n'est pas taillé ni pour de fortes charges ni pour la concurrence. Le choix est dès le départ mauvais, inadapté.... Encore une fois manque de culture ! C'est pourquoi on essaye de rattraper les faiblesses d'un outil par un autre. C'est proprement stupide !

Pour ce qui est de la facilité de développement, il ne me semble pas que l'on puisse profiler les exécutions pas à pas des procédures de la base de données, par exemple mettre des break points dans les triggers (peut-être SQL Server?). Il ne me semble pas non plus que l'on puisse faire facilement des test unitaires. Si je ne me trompe pas c'est dommage.

Vous vous trompez lourdement. De tels outils existent. Déjà en SQL Server 2005 on pouvait déboguer par Visual Studio. Avec 2008 c'est directement intégré aux outils client de SQL Server....
Encore une fois vous affirmez sans savoir, ce que vous faites depuis le début en polluant les forums de developpez !

A +

[B.AF]

En professionnel de la chose et surtout en tant qu'enseignant pour une école d'ingénieur et pour le CNAM, je dirais simplement la chose suivante :
En 5eme année d'ingéniorat j'ai 40 heures de cours à donner dans lequle je devrais en principe faire :

• les bases de données relationnelles
• la modélisation de données
• le langage SQL
• les transactions
• le décisionnel
• la qualité des données

avec cours et TP...

Croyez vous franchement que ce nombre d'heure soit suffisant ?

malheureusement c'est le cas de la majorité des écoles d'ingé et des enseignements universitaires....

A +

C'est bien de donner des cours et de conseiller, mais bon de là à dire que tous ceux qui ne croient plus au SGBD comme pierre angulaire d'une application ne comprennent rien, c'est un peu idiot et péremptoire.

Je connais des économistes qui écrivent des livres et donnent des cours, mais donc aucune théorie ne s'est révélée éfficiente...

Sans doute est-ce has been d'avoir une méthode et préférez vous les absconcerries de la syntaxe des langages comme C++, java ou C#...

Ce qui je trouve grave en 2009 c'est de lire ça. Déjà le mélange de langages, le prosélitisme

Quant aux exemples ,il serait judicieux de donner des exemples en rapport avec la question : d'aujourd'hui.

D'où l'anachronisme.

Il existe aussi des lègions d'application critiques, haute dispo, voir temps réel qui n'utilisent pas la base pour autre chose que dépôt de données fiable et qui sont très bien conçues. Et c'est bien comme ça.


Quant aux supers articles où le gars ne sait pas faire la différence entre IBatis et Hibernate, bon c'est gentil...Mais c'est comme dire que LOC = bug, c'est d'un autre temps. C'est de l'architecture des années 80~90.
C'est du poujadisme informatique. Même sur la critique de serge Tahé, c'est d'un déplacé et d'un vulgaire...

[SQLpro]

Il existe aussi des lègions d'application critiques, haute dispo, voir temps réel qui n'utilisent pas la base pour autre chose que dépôt de données fiable et qui sont très bien conçues. Et c'est bien comme ça.

C'est là un des hic majeur... Considérer le SGBDR comme outil de stockage est un hérésie. Un SGBDR est fait pour manipuler des données et gérer des transactions. S'il n'y a aucune transaction à faire et si l'on ne fait quasiment que du stockage (pas d'extraction) alors l'utilisation du SGBDR n'a aucun intérêt. Il est utilisé à contre emploi et il ne faut donc pas s'étonner que de tels abus conduisent à des insatisfactions.... Or malheureusement beaucoup d'applications utilisent un SGBDR pour du vulgaire stockage, d'où les problèmes d'incompréhension de certains informaticiens à la culture un peu étriquée

Si vous voulez déménager, allez vous utiliser une formule 1 ou un camion ?

A +

[B.AF]

C'est là un des hic majeur... Considérer le SGBDR comme outil de stockage est un hérésie. Un SGBDR est fait pour manipuler des données et gérer des transactions. S'il n'y a aucune transaction à faire et si l'on ne fait quasiment que du stockage (pas d'extraction) alors l'utilisation du SGBDR n'a aucun intérêt. Il est utilisé à contre emploi et il ne faut donc pas s'étonner que de tels abus conduisent à des insatisfactions.... Or malheureusement beaucoup d'applications utilisent un SGBDR pour du vulgaire stockage, d'où les problèmes d'incompréhension de certains informaticiens à la culture un peu étriquée

Si vous voulez déménager, allez vous utiliser une formule 1 ou un camion ?

A +

Wikipedia :

Une base de données est un conteneur organisé pour le stockage de grandes quantités d'informations.

Je ne vois pas en quoi c'est idiot d'avoir des données stockées, de les extraires et de faire un traitement avec...Probablement que je me vois mal faire un processus stochastique en SQL mais plutôt en C++ qu'en VB ou en Delphi ou que vous manquez d'expérience sur d'autres domaines de l'informatique.

Le problème transactionnel des SGBD est qu'il n'a aucune subtilité, et qu'il va justement à l'encontre de besoins fonctionnels critiques.

Le SGBD peut être dans ses fonctionnalités (transactions) insuffisant.

C'est une erreur ou horreur avec les moyens disponibles aujourd'hui de traiter le SGBD comme un élement principal.

Centraliser les traitements dans la base, c'est centraliser les problèmes.

Si une BASE de DONNEES ne sert pas à stocker des données pour pouvoir s'en servir...Là...Oui, je ne vois pas à quoi ça sert.

Je ne vois pas en quoi le SGBD devrait et fera mieux la gestion des transactions qu'un service bien conçu qui justement découpera l'algo de la donnée et du sql.

La culture étriquée, c'est de juger sur piéce, sans prendre le recul nécessaire sur une situation. Le tout SGBD, c'est très étriqué.

A priori, je vais pas demander à un expert SQL comment designer une application distribuée ni même de comprendre ou d'avoir un avis sur la question : ce n'est pas son domaine.
En revanche, j'espére que sur la base, un expert SQL pourra émettre une expertise en fonction de mes besoins.

La base est un élément d'un tout. Rien de plus, rien de moins.

Vous souffrez d'un surspécialisation professionnelle qui vous enlève beaucoup d'objectivité à mon avis.

Si je déménage, je demande à un déménageur.