Discussion :

[SQLpro]

Visiblement vous mélangez tout à dessein.

Commençons par votre citation :

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

Nous parlons de BD relationnelles. Il existe de multiples types de bases de données pour de multiples usage (hierarchique, réseau, XML, OLAP, multivaluées....) c'est pourquoi cette définition ratisse large.
Visiblement vous ignorez le terme relationnel ! pas étonnant que vous affirmez n'importe quoi...

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

Là encore votre ignorance est superbe... Il n'ay a pas plus simplet et à la fois plus souple que le transactionement dans un SGBDR ou l'on peut piloter le niveau d'isolation de chaque transaction et de manière dynamique...
Sachez que les transactions ont été inventées par Gray et Bernstein pour satisfaire des problématiques d'ACIDité des données. Faire des transactions au niveau objet n'a aucun intérêt, mais complexifie et rend le système globalement lent.

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

Cela dépend des applications, mais pour l'informatique de gestion c'est bien souvent incontournable.

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

J'en rigole... Retournons la phrase :
Décentraliser les traitements, c'est décentraliser les problèmes... !
Est-ce mieux ou moins bien ?
M'est avis que de recherche sur 100 serveurs d'où vient le problèmes est plus couteux que de rechercher sur un seul... Mais sans doute suis-je has been !

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.

Vous déformez mes propos ou ne savez pas lire... J'ai dit que de se servir d'une SGBDR uniquement pour du stockage c'est stupide.

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.

Parce que les transactions n'ont d'intérêt que sur des données et qu'agir au plus près de l'endroit ou se trouve les données c'est beaucoup plus performant !

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é.

Il est certain qu'à 50 balais et après avoir un peu tout fait, y compris hors de l'informatique, je pense n'avoir encore rien vu qui me permette de juger...

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.

Si j'ai choisit de devenir un tel expert, c'est qu'après avoir vu les nombreuses impasse technique et les modes changer au grès des fantaisies, j'ai préférer m'investir dans une technique stable et efficace afin de répondre à de vrais besoin. Et croyez moi, je chôme pas !!!

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

Oui, mais central.

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

Vous me jugez sans me connaître ! Encore une affirmation péremptoire, comme l'essentielle de votre discours. Aucun argument.

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

Et il prendra une formule 1 ?

A +

[Jester]

Nous parlons de BD relationnelles. Il existe de multiples types de bases de données pour de multiples usage (hierarchique, réseau, XML, OLAP, multivaluées....) c'est pourquoi cette définition ratisse large.
Visiblement vous ignorez le terme relationnel ! pas étonnant que vous affirmez n'importe quoi...

Du coup on est au moins 2 ne pas voir le 'R' dans le titre de ce forum ou dans sa description. Ça me rassure. Tant qu'il n'y est pas, je prend ce forum dans la définition large.

Pour ma part je aussi trouve que centraliser les problèmes c'est une bonne pratique. Utiliser un SGBD pour du stockage pur, permet de centraliser les problèmes dans le code applicatif.

Sur la perte d'efficacité, la quasi-totalité provient de la surcharge de communication entre l'application et le SGBD. En général entre ce que j'écris en Java et ce que j'aurais écrit en PL/SQL, il n'y a pas de différences. Il faudrait donc juste pouvoir réintégrer les codes très proches des données dans les SGBD ou mettre le SGBD dans le serveur d'application.

Pour moi, migrer dans le SGBD ça a des avantages, mais ne pas le faire et tout confiner dans la partie applicative ça en a aussi. Je dirais que ça dépend au cas par cas.

[B.AF]

Ah bon...Il en existe de multiples...Ah merci !!!! Vraiment....
Mais si d'un point de vue stockage et traitement, c'est tellement la panacée; pourquoi Big Table par ex. ?

J'ai compris : Chez google, ils sont tellement bêtes qu'ils ont oublié de regarder et d'apprendre le SQL !!!!

Et pourquoi Wikipedia utilise des caches distribués qui synchronisent les DB pour éviter les contentions ?
Parce qu'ils ne comprennent rien !

Et pourquoi le Nyse fonctionne avec des bases objets ?
Pourquoi les calculs scientifiques n'utilisent pas de SGBDR ?

Mais les pompiers de paris OUI ! Alors comme la gestion des appels des pompiers de paris c'est très complexe d'un point de vue métier, traiter les flux de données nécessaires pour des simulations d'ADN, ça doit se faire en SQL aussi. Parce que sinon, c'est mal, on ne fait que stocker.

Et pour les transactions, si il n'y a pas commit et rollback on en parle pas. Sinon c'est pas une transaction. Mais pourquoi Ebay a supprimé la gestion des transactions....Des contentions...???? NOOOOOONNNN !
Encore des idiots qui n'ont rien compris au SGBD !!!!

M'est avis que de recherche sur 100 serveurs d'où vient le problèmes est plus couteux que de rechercher sur un seul... Mais sans doute suis-je has been !

Oui. Rien que vu la réponse. Oui.
Déjà parce que au niveau de l'archi des serveurs, rien n'interdit de distribuer des transactions. Rien n'interdit la présence d'un cluster, d'un grid, de n bases, de réplications bidir en temps réel.

Vous me jugez sans me connaître ! Encore une affirmation péremptoire, comme l'essentielle de votre discours. Aucun argument.

Je veux pas être désagréable, mais en architecture logicielle, vous partez de trop loin pour que le débat existe.

Très bien de la vendre. Mais bon on peut attendre autre chose que du client serveur en 2009.

Sachez que les transactions ont été inventées par Gray et Bernstein pour satisfaire des problématiques d'ACIDité des données. Faire des transactions au niveau objet n'a aucun intérêt, mais complexifie et rend le système globalement lent.
(...)
Parce que les transactions n'ont d'intérêt que sur des données et qu'agir au plus près de l'endroit ou se trouve les données c'est beaucoup plus performant !

A mourir de rire...est-ce que validation des données ça vous parle ? Pourquoi devrais-je stocker une donnée volatile dont je souhaite vérifier la cohérence avant de la stocker ...Sachant que sinon, je ne la stocke pas.... Plus besoin d'ETL et d'EAI, vive la proc stock....Bref, back to the future...

Mais est-ce que vous pouvez parfois décorréler la technique de l'implémentation ? Une transaction business, c'est le résultat potentiel de 1 à n transactions techniques. Pour cela, le SQL n'est pas du tout approprié. Pas plus que sur la réservation de ressource.

Et il prendra une formule 1 ?

Là j'en suis plutôt à me demander si la voiture existait déjà....

[B.AF]

Sur la perte d'efficacité, la quasi-totalité provient de la surcharge de communication entre l'application et le SGBD. En général entre ce que j'écris en Java et ce que j'aurais écrit en PL/SQL, il n'y a pas de différences. Il faudrait donc juste pouvoir réintégrer les codes très proches des données dans les SGBD ou mettre le SGBD dans le serveur d'application.

Pour moi, migrer dans le SGBD ça a des avantages, mais ne pas le faire et tout confiner dans la partie applicative ça en a aussi. Je dirais que ça dépend au cas par cas.

Enfin tu perds tout, déjà tu ne pars des tests, toute la conception est résumée à dessiner des tables, faut se taper des CRUD de base avant...Bref, c'est des outils antédiluviens, anti-productifs.

Plus de logique de test unitaires, le versioning c'est un calvaire, la gestion des releases aussi, la documentation du code...heu du schéma n'est pas automatique, enfin c'est d'un autre temps.

Même si ce que tu dis est juste sur Java et PL/SQL dans 90% des cas.
Mais c'est un vrai cauchemard.

Plus de découpage de projet technique (Mine de rien, les jar et autres DLL, ça soulage pas mal le découpage fonctionnel pour la maintenance), plus de débuggage pas à pas, pas de possibilité d'intégration continue, pas d'orientation service...Montée en charge pénible, potentiel temps réel limité...

[Waldar]

Vos arguments sont plutôt intéressants et c'est très bien de les mettre en face les uns des autres.

Si on pouvait éviter les attaques personnelles ce serait plus agréable à lire et probablement plus constructif.

[Jester]

La raison pour qu'actuellement je n'utilise pas de procédure stockées est que ma base de données pour le dev et les tests n'en a pas (en tout cas pas les même que la base de production) vu que c'est un petit SGBD in process en java.

Par contre, même dans le cas où j'en utiliserais (y a un endroit où je pense que c'est vraiment nécessaire), les objets seront toujours définit dans le code applicatif et translaté en schéma par l'outil ORM (comme toujours, quitte à rajouter ce qu'il oublie). C'est une hérésie de définir 2x le même objet, disons un utilisateur, une fois pour le schéma BD et une fois pour la partie applicative et de se tapper le mapping à la main. Et il se trouve que c'est plus logique dans la partie applicative car ça peut générer le code SQL et le code de validation des saisies. En 5 lignes qui décrivent juste un objet métier, on peut générer les interfaces de saisies/visu correspondantes, le code de validation, et le code SQL de création.

Sur des cas spécifiques, il est toujours possible de changer des choses dans la BD ou remplacer du code applicatif par un appel à une procédure stockée, mais c'est de l'optimisation dont il faut mesurer l'avantage vs l'inconvénient. Tout l'intérêt des méthodes modernes c'est de développer vite et de pouvoir optimiser ensuite là où ça a du sens. Je me fiche de savoir si une page web fait 10 appels à la base de données si elle n'est affichée qu'une fois par jour.

[Mat.M]

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

C'est très contestable ; si le volume de données dans la base est élevé cela sera plus rapide en SQL ou mieux avec des procédures stockées que de vouloir refaire la même chose en couche objet avec Java ou autre...
parce que les SGBDR sont particulièrement optimisés pour supporter les grosses requêtes.
Je crois qu'ils créent des systèmes d'arbres binaires de recherche de donnée..
C'est certain que pour des domaines comme le calcul scientifique faire tout reposer les calculs sur du SQL dans un SGBDR c'est un mauvais choix parce qu'un SGBDR n'est pas trop fait pour cela..


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

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.

Parce qu'un SGBD est particulièrement optimisé et éprouvé !

Sur la perte d'efficacité, la quasi-totalité provient de la surcharge de communication entre l'application et le SGBD. En général entre ce que j'écris en Java et ce que j'aurais écrit en PL/SQL, il n'y a pas de différences. Il faudrait donc juste pouvoir réintégrer les codes très proches des données dans les SGBD ou mettre le SGBD dans le serveur d'application.

Pour moi, migrer dans le SGBD ça a des avantages, mais ne pas le faire et tout confiner dans la partie applicative ça en a aussi. Je dirais que ça dépend au cas par cas.

euuh je suis très sceptique là-dessus bon je veux bien te croire....mais je doute vraiment que du code Java soit aussi efficace que l'équivalent en PL/SQL..
Pour un SGBD de volume de données petit et moyen oui il n'y a peut-être pas de différences mais pour une grosse base de données je suis très sceptique..

[B.AF]

Là dessus, il y a une vérité unique : on ne peut pas développer un logiciel exploitant une db sans se soucier de la db.

on peut contraindre son rôle, mettre une couche d'abstraction entre les objets et le sql etc,etc mais on ne peut pas ignorer les aspects techniques.

L'erreur commise avec les ORM (Hibernate), plus difficile avec des les mappers (IBatis) et qu'il fournissent une abstraction séduisante, mais souvent on oublie que dérrière il y a du SQL et les performances sont gravements impactées. C'est une question de practice. Si un expert SQL prend hibernate et implémente son propre dialect, et prend en charge par exemple les aspects relationnels et la validation des chargement (data access layer) tu peux obtenir d'excellents résultats et fournir une vraie abstraction.

Le problème c'est aussi que beaucoup ont utilisé ces technos comme un anti sql, ce qui est une mauvaise approche, mais n'est pas une approche systèmatique.

Ce que je trouve hérétique c'est de faire de l'objet drivé par le relationnel et l'inverse. Un modéle objet peut persister dans un modéle relationnel différent et répondant mieux aux contraintes relationnelles.

Le problème de ce mélange des genres provoque des récursivités dans le moteur db utilisé, donc des contentions, et au niveau applicatif, des répercussions dans le modèle objet.

Et là on peut vraiment développer en couche et séparer les responsabilités :

J'ai 300 objets, avec leurs méthodes, leurs propriétés et leurs dépendances.
Comment les persister ?
La réponse n'est pas automatiquement de mapper 300 objets. Cela peut être de passer pas des sp, ou du sql direct, mais la responsabilité métier est moindre.
Donc les transaction in fine dans la db beaucoup plus fiables, pas d'objets temporaires, et une base de code bien maintenue, ainsi qu'une couche objet dont les tests son db indépendants.

Et la séparation physique (distribution) est envisageable.

Limite, je vais me faire l'avocat du diable et dire que si tu mappes un objet / 1 table, quelque part, tu n'as pas besoin d'un ORM.

L'ORM pour moi est un outil qui est partagé entre l'expert DB et l'architecte. C'est l'outil qui permet de garantir que :
- L'architecte pense son accès aux données
- L'expert Db maitrise les processus et leur implémentation technique
- Les développeurs ne peuvent pas créer d'anti pattern en utilisant ces couches.
- l'accès aux données est testable et documenté

Au contraire, c'est bien plus dangereux aujourd'hui d'utiliser un ORM que du SQL direct, même si apparence plus productif. Mais à terme une vraie politique d'accès aux données, avec une vraie base de connaissance, c'est payant et en productivité et en maintenance.
En outre, par rapport aux profils, on peut avoir des dév spécialisés plutôt que des couteaux suisses qui font un peu de SQl, un peu de réseau....

Développer vite, ça se mesure dans le temps :
Si tu mets 200J pour développer une fonctionnalité qui te coute 300J de maintenance, c'est pas terrible.

Le problème étant qu'aujourd'hui la mentalité veuille que le test soit in-fine, les problèmes arrivent in-fine. Or c'est à l'occurence du défaut que l'on mesure le besoin de granularité. Donc aujourd'hui dans le RAD, on développe vite le prototype, mais la mise en production est pénible.

Une base de code propre part des tests.
Savoir que objet 1 et 2 sont sauvegardés par sp, ou à la volée, ou dans un fichier texte et que cela fonctionne ne veut pas dire que le résultat est cohérent. Ce qui est cohérent c'est la finalité de cette sauvegarde et de sa contribution à un dialogue business lambda.

[B.AF]

Parce qu'un SGBD est particulièrement optimisé et éprouvé !

Ah bon...Parce que la source donnée est nécessairement unique et de même fondamentaux de conceptions ?

Prenons SQL Server avec un exemple trivial/simple : J'ai 3 Bases supportant mon activité. Par soucis d'interopérabilité, je souhaite avoir un chainage. Disons
1 - base A ventes
2 - Base B back office
3 - Base C sav

Chaque base a son appli. Je souhaite que A poste une nouvelle commande dans back office quand le vendeur a terminé, et que le sav ouvre un nouveau dossier si le client n'existe pas . Je veux un traitement en temps réel.
Si un user de A crée une vente dans la base A, B doit créer un suivi de commande, créer un client si le client de la vente n'existe pas, le sav idem etc,etc....

Techniquement, je pourrais avoir une succession sur A,B et C de transactions atomiques, techniquement parfaite, mais une signification business nulle et inappropriée.

Donc en admettant que je délégue les taches à un outil de bpm quelconque, qui doit piloter la transaction et comment ?
Ou est-il utile que je prévois des suppressions de données, en admettant que pendant un laps de temps court j'ai des données incohérentes ?

Ca pourrait aussi bien être des schémas, des instances oracles, DB2 ou 3 serveurs indépendants. L'abstraction est justement importante pour ne pas bloquer l'architecture technique et résoudre des questions fondamentales.

C'est donc impossible de dire arbitrairement "Il faut ça parce que c'est éprouvé". Oui c'est éprouvé techniquement et connu, mais la vraie épreuve, c'est l'implémentation et l'exploitation. Et quelle que soit la techno, chaque projet est une nouvelle épreuve ou trop de croyance est un risque grave d'échec de de perte de temps.

[Jester]

euuh je suis très sceptique là-dessus bon je veux bien te croire....mais je doute vraiment que du code Java soit aussi efficace que l'équivalent en PL/SQL..
Pour un SGBD de volume de données petit et moyen oui il n'y a peut-être pas de différences mais pour une grosse base de données je suis très sceptique..

Du code java qui ne fait que reprendre la logique d'un code PL/SQL (les if, les boucles ...) par exemple et qui envoie des requêtes à la base de données dès qu'ils s'agit de vraiment faire quelque chose. Du coup, aux coûts de communication près (qui peuvent représenter 90% de la durée du traitement), ça me semble devoir être identique. Il y a peut-être des cas atypiques, mais je n'en ai pas en tête.

Mon argumentation part du fait que Oracle permet du PL/SQL ou du Java (ou du .Net semblerait) pour les triggers et procédure stockées, donc la question revient à savoir si leurs performances sont similaires dans la BD.

PS : En fait il y a aussi des coûts de conversion des types en Java (pris d'une doc Oracle).

[B.AF]

Du code java qui ne fait que reprendre la logique d'un code PL/SQL (les if, les boucles ...) par exemple et qui envoie des requêtes à la base de données dès qu'ils s'agit de vraiment faire quelque chose. Du coup, aux coûts de communication près (qui peuvent représenter 90% de la durée du traitement), ça me semble devoir être identique. Il y a peut-être des cas atypiques, mais je n'en ai pas en tête.

Mon argumentation part du fait que Oracle permet du PL/SQL ou du Java (ou du .Net semblerait) pour les triggers et procédure stockées, donc la question revient à savoir si leurs performances sont similaires dans la BD.

PS : En fait il y a aussi des coûts de conversion des types en Java (pris d'une doc Oracle).

Les deux sont valables, il y a des traitement qu'un langage comme java fera plus rapidement que SQL et réciproquement. De même il y a des choses pour lesquelles c++ et plus adapté que Java.

Pour le CLR ou le Java embarqué dans la DB...C'est litigieux...Même microsoft déconseille le dev de sp en clr...Et là pour le coup c'est assez bancal.

En même temps, là seule fois ou j'ai essayé de l'utiliser, c'était sur 2005 et franchement j'ai vite fait machine arrière.

[SQLpro]

Pour le CLR ou le Java embarqué dans la DB...C'est litigieux...Même microsoft déconseille le dev de sp en clr...Et là pour le coup c'est assez bancal.

Ou avez vous vu que MS déconseillait l'utilisation de CLR dans SQL ???
Cette affirmation est une bêtise de plus à mettre sur votre compte.
Sachez que le SIG de SQL Server 2008 est entièrement réalisé en CLR et ses performances sont bien supérieures à celle de PostGis actuellement !

Vous n'avez visiblement pas compris l'intérêt de la CLR dans SQL Server. Pour mémo voici ce que j'écrivais avant la sortie officielle de SQL Server 2005 :
http://sqlpro.developpez.com/sqlserv...age=conclusion

Mais le CLR est parfaitement adapté à des problématique de calcul complexe monoligne par exemple comme c'est le cas du SIG !

A +

[Mat.M]

Ah bon...Parce que la source donnée est nécessairement unique et de même fondamentaux de conceptions ?

ok mais je me suis mal exprimé
je voulais dire optimisé pour tout ce qui est tri des données dans la base , agrégation , mise à jour

[Maximil ian]

Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données.

Si, ce que les outils d'OR/M (Hibernate...) nomment "transactions" sont bien des transactions au sens base de données, elles se traduisent directement par des ordres transactionnels envoyés au SGBD. A ne pas confondre avec les sessions qui sont des unités de travail utilisateur à durée de vie limitée, c'est à dire un scope contenant les objets gérés par l'ORM.

Sachez que les transactions ont été inventées par Gray et Bernstein pour satisfaire des problématiques d'ACIDité des données. Faire des transactions au niveau objet n'a aucun intérêt, mais complexifie et rend le système globalement lent.

Faux. On va considérer que ce que tu appelles "transactions niveau objet" sont des sessions au sens ORM.

Tout le monde connait le bouton Appliquer qui figure dans de nombreuses fenêtres sous Windows (différent du bouton OK). Dans le cas d'une application interfacée avec un SGBD, cliquer sur ce bouton reviendra à envoyer un ordre COMMIT et donc clore la transaction. En effet les modifications qui ont été effectuées dans la fenêtre doivent être stockées durablement, visibles par les autres utilisateurs et même si on clique sur Annuler ensuite, les modifications restent bien que cela ferme la fenêtre.

En revanche le même bouton Appliquer ne déclenchera pas une fermeture de la session de notre ORM. On reste sur la fenêtre, donc aucune raison de perdre nos entités en session et de devoir réhydrater ces mêmes entités depuis la base ensuite. Par contre il y a fort à parier qu'un clic sur Annuler provoquera une fermeture de la session. Donc les sessions ORM ont un intérêt et ne concordent pas toujours avec les transactions.

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 !

Le problème ici n'est pas tant l'ORM lui-même, mais le fait de lui déléguer aveuglément l'ensemble des requêtes. Comme certains l'avancent (http://codebetter.com/blogs/karlsegu...-thoughts.aspx), si l'outil d'ORM peut prendre en charge 95% des accès aux données de façon automatisée, c'est déjà une avancée remarquable. Pour les 5% ou plus de requêtes critiques / problématiques restantes, il n'a jamais été interdit de les optimiser au cas par cas voire de les passer en SQL "à la main".

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...

Ce n'est pas le rôle d'un ORM de mettre en valeur les erreurs d'un modèle de données déjà existant (dans le cas d'une approche bottom-up, c'est à dire conception du modèle de données d'abord puis du modèle objet par-dessus). Dans un scénario top-down, rien n'empêche de recourir à de tels outils de modélisation pour corriger le tir après que le modèle relationnel ait été inféré des objets.

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.

La plupart je ne sais pas, Hibernate (sans doute le plus connu) en tout cas oui : https://www.hibernate.org/hib_docs/n...lsetguide-s1-2. De plus, rien n'empêche d'implémenter ce CHECK au niveau objet avec une règle métier.

Pour finir, je trouve que dans ta diatribe d'ayatollah du relationnel tu oublies toutes les avancées du génie logiciel permises par le paradigme objet (car elles fonctionnent en synergie avec l'objet) :

- design patterns
- refactoring
- test-driven development
- domain-driven design
...

L'intérêt de ces concepts n'est pas la performance, mais tout aussi important, l'évolutivité, la testabilité du code et sa capacité à modéliser avec précision des problématiques complexe du monde réel. Autant d'avantages considérables qui ont - et ce n'est pas un hasard de l'histoire dû à quelques illuminés qui auraient fait un hold-up sur le monde du développement - favorisé l'avènement des langages objet aux dépens des langages procéduraux.

[B.AF]

SQLPro,

j'ai l'impression de parler à buzz l'éclair dans un distributeur de bonbon...

Je crois que tu devrais regarder toy story : ça t'éviterai de te facher, de prendre ces sujets pas très importants moins au sérieux (non mais c'est vrai, tout le monde s'en tape du malheur des rdbms maltraités et que toutes les relations soient bien matérialisées et que les règles métiers soient ou pas en sql.) et je crois que tu peux en tirer un enseignement personnel.

Si tu tripes à te faire des listing de SQL, super, ça me va. Moi ça me gonfle terriblement. Un peu comme les gens qui ont des avis qui n'évoluent jamais.

@+

[B.AF]

Le problème ici n'est pas tant l'ORM lui-même, mais le fait de lui déléguer aveuglément l'ensemble des requêtes. Comme certains l'avancent (http://codebetter.com/blogs/karlsegu...-thoughts.aspx), si l'outil d'ORM peut prendre en charge 95% des accès aux données de façon automatisée, c'est déjà une avancée remarquable. Pour les 5% ou plus de requêtes critiques / problématiques restantes, il n'a jamais été interdit de les optimiser au cas par cas voire de les passer en SQL "à la main".


Ce n'est pas le rôle d'un ORM de mettre en valeur les erreurs d'un modèle de données déjà existant (dans le cas d'une approche bottom-up, c'est à dire conception du modèle de données d'abord puis du modèle objet par-dessus). Dans un scénario top-down, rien n'empêche de recourir à de tels outils de modélisation pour corriger le tir après que le modèle relationnel ait été inféré des objets.

Ces deux remarquables remarques, il faudrait les garder et les mettre en gros en gras et en rouge dans tous les forums où se posent des questions d'architecture et d'accès aux données.

Et j'ajoute aussi que l'ORM n'empêche pas de se poser des questions de performances.

[fsmrel]

Bonsoir,

Loin des débats d’experts, auxquels je ne comprends pas grand-chose, j’en reviens au problème soulevé par raynord et ayant trait à l’intégrité référentielle.

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.

Demander à l’application de garantir l’intégrité des données suffit-il ?

Dans le cas des applications traditionnelles de gestion, mais néanmoins centrales, vitales, dans le monde des entreprises telles que les banques, les sociétés d’assurance, les caisses de retraite, dans la distribution, l’industrie, les administrations, etc., la réponse est non, car il peut en résulter de très sérieux dommages. A suivre, quelques péripéties dans lesquelles j’ai trempé, dépêché par mon entreprise (une SSII).

Il était une banque où je fus appelé pour tenter de rétablir les liens entre les tables des comptes, des contrats, des clients, etc. La cata. J’ai tout tenté pour remettre les choses d’aplomb. Le Président lui-même me posait tous les matins la même question dans laquelle l’angoisse était à peine voilée : « Alors ? mes en-cours ? » Peine perdue. La banque n’existe plus.

Une société d’assurance. Pour le DSI, la base de données Clients c’était du béton : « Je n’ai jamais entendu parler de quelque problème que ce soit, tout baigne ». J’étais alors chargé de valider un modèle conceptuel de données et le modèle logique dérivé, ceci pour une autre base, alimentée à partir des données de production. Ayant mis en œuvre l’intégrité référentielle pour la nouvelle base, ce qui devait arriver arriva, ce fut un révélateur : 30% de données rejetées lors de la « remontée » dans la base toute neuve. Le DSI verdit et il fallut plus d’un an pour arriver à remettre la base Clients à peu près d’équerre.

Une société de crédit automobile. Pour valider une application en cour de refonte, j’avais été autorisé à copier les données de production. Je fus obligé de porter le pet au plus vite, car il y avait quelques milliers de contrats faisant référence à des clients inconnus au bataillon. Panique à bord, tout le monde sur le pont... Après enquête, il s’est avéré que, suite à un incident matériel en production, il y avait eu une restauration des données Clients/Contrats, mais à partir d’une sauvegarde des clients ayant eu lieu à une date n’ayant rien à voir avec la date de sauvegarde des contrats. Heureusement, il y avait un an de backup en magasin et le coup put être rattrapé. (Le SGBD n’était pas relationnel. Il a par la suite été remplacé par DB2, lequel aurait tout de suite détecté le décalage des sauvegardes.)

Une caisse de retraite. Un décideur (fonctionnel) décide de faire débrancher l’intégrité référentielle pour une partie de la base de données. Prudent, je recopie les tables de production dans un environnement qu’on m’a affecté, j’écris toutes les requêtes SQL pour vérifier (de nuit, car il est hors de question de pomper du temps machine pendant la journée) que les tables impliquées sont restées cohérentes suite à traitement diurne. Au résultat, ça n’a pas traîné : je constate que 780000 périodes passées par les cotisants dans les entreprises se sont envolées. Traitements à refaire, avec ordre cette fois-ci du décideur de brancher l’intégrité référentielle. Qu’est-ce qu’il ne faut pas faire pour que les gens comprennent...

Et j’en ai bien d’autres...

Il faut être bien naïf pour croire que les contrôles d’intégrité assurés par programme permettent de dormir sur ses deux oreilles. Après tout, dans la série « ceinture, bretelles et épingle à nourrice », si vous avez un DBA sous la main, tout en laissant l’application consciencieusement contrôler ce qu’elle à a à contrôler, demandez donc à ce spécialiste de mettre en œuvre l’intégrité référentielle, au moins pour les tables les plus sensibles, ou (si le chef refuse), de développer et exécuter les requêtes permettant d’auditer le contenu des tables.

Par référence aux trois petits cochons, il faut préférer construire une maison en briques plutôt qu’en paille et implanter l’intégrité référentielle. Attention au loup.

[al1_24]

Qui n'a pas, au cours de son parcours professionnel, rencontré des DBA qui refusent de mettre en place toute intégrité référentielle dans la base au prétexte que

ça pompe trop de ressources et le serveur ne suivra pas

[fsmrel]

Qui n'a pas, au cours de son parcours professionnel, rencontré des DBA qui refusent de mettre en place toute intégrité référentielle dans la base au prétexte que

ça pompe trop de ressources et le serveur ne suivra pas

Un DBA de ce genre marche à l’émotion et ferait mieux de faire du prototypage de performances en relation avec l’intégrité référentielle (en mise à jour intensive bien entendu). Il ignore peut-être aussi que les contrôles d’intégrité font l’objet montagnes de lignes de code s’il faut les assurer de manière applicative et que « ça pompe des ressources », non seulement du côté du serveur mais aussi de celui du développement cette fois-ci (sans oublier la maintenance du code et la dégradation de la qualité qui en résulte au fil du temps).

Je rappelle souvent que lorsque DB2 (et a fortiori les autres SGBDR) ne gérait pas encore l’intégrité référentielle, le G.U.I.D.E. (Groupement des utilisateurs IBM) se faisait l’écho de la multitude qui la réclamait à cor et à cri. Quand au bout de quatre ans, en 1988, IBM nous la livra, changement de chanson : « Finalement, est-ce bien utile ? Est-ce que ça ne coûterait pas la feau des pesses quant aux performances ? » Concernant l’utilité, il n’y a pas photo, l’intégrité des données n’a pas de prix. Je le redis, en ce qui concerne la performance, plutôt que de faire dans l'incantation, il faut retrousser ses manches et quantifier les bienfaits/méfaits de l’IR à coups de prototypage. C’est en tout cas ce que je fais systématiquement chez mes clients. Ensuite, on peut discuter objectivement avec la Direction de la Production de la mise en œuvre de l’IR. Pour ma part, je n'ai jamais essuyé de refus.

[SQLpro]

Et même ce que peu de gens savent c'est que parfois la présence d'une contrainte d'intégrité référentielle permet à la requête d'aller encore plus vite que s'il n'y en avais pas. Par exemple, dans une jointure si la FK est présente et la clef non trouvée dans la table mère il est inutile de parcourir la table fille...

De la même façon, on me demande souvent pourquoi je met des contraintes de domaine partout. Par exemple pourquoi je met une contrainte CHECK (VALUE BETWEEN 0 AND 100) à mes pourcentages...
C'est aussi parce que si l'on recherche les lignes avec le filtre suivant :

Code :

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

WHERE REDUCTION_POURCENT > 150

que la réponse soit immédiate !

A +