Discussion :

[Invité]

Oui c'est un peu la marque de fabrique de l'auteur j'ai l'impression. C'est vrai que ce n'est pas vraiment nécessaire...

Sinon je suis convaincu de la nécessité des FK, j'ai d'ailleurs insisté pour que mon ancien employeur renonce à SQLite, même pour une petite application.

Sur ce genre de base, il suffit généralement d'une ou deux requêtes SELECT avec un NOT IN(...) sur les tables les plus fréquemment affectées pour repérer une poignée d'enregistrements fautifs.

:

SQLite gère désormais les contraintes FK :

SQLite Release 3.6.19 On 2009 Oct 14 (3.6.19)

D'autre part SQLite illustre parfaitement l'étendue de l'utilisation des BDD et les limites des discussions trop théoriques. Je pratique SQLite au plus haut niveau et j'en retire des avantages concurrentiels inestimables.

[Luc Orient]

... si mon code client fait une "bétise" et supprime une ligne parente non-protégée : je peux préférer connecter la base en admin, trouver les lignes orphelines et me faire ma propre idée de ce qu'il faut faire plutot que laisser l'utilisateur gérer une erreur dont il ne sait que faire.

J'ai un peu de mal à voir ce qu'on peut faire avec une facture supprimée alors qu'il reste des lignes de factures rattachées à rien ... Et puis pragmatisme contre pragmatisme, en tant que DBA j'ai suffisamment de travail à faire sans perdre mon temps à faire ce genre de manipulation sans interêt ...

[Invité]

J'ai un peu de mal à voir ce qu'on peut faire avec une facture supprimée alors qu'il reste des lignes de factures rattachées à rien ... Et puis pragmatisme contre pragmatisme, en tant que DBA j'ai suffisemment de travail à faire sans perdre mon temps à faire ce genre de manipulation sans interêt ...

Vous avez oublié de préciser que cet article est strictement limité à la gestion ... non ? Ces jours ci j'administre des serveurs BDD dont AUCUN ne fait de gestion .. Une base de données sert aussi à gérer un filesystem ou une liste de périphériques ou un flux ou..... du traitement de signal

Su les 3 pays où je travaille , seule la France ignore cela. Education ?
J'ai écrit des compilateurs en SQL il y a une 10aine d'années , les lignes orphelines étaient des liens morts et aucun utilisateur n'aurait pu gérer les millions de messages d'intégrité , c'est la force dune BDD , elle peut jointurer à postériori. Mais ce me semble limite louche chez vous, ne comptez vous que des sous ? C'est un peu réducteur quand même

Pensez vous que les aiguilleurs du ciel se voient interdire l'usage de BDD ? et les milliers de taches sur leur écran radar = autant de lignes de BDD avec ou sans contrainte FK ?? Messieurs voyez un peu large svp

[Oishiiii]

Le sujet ici est les clé étrangères en SQL et donc indirectement la Théorie Relationnelle.
La normalisation qui a pour but entre autre de réduire la redondance d'information entraine un nombre de tables relativement important. Celles-ci sont très souvent en associées (je n'utilise pas le mot relation volontairement).

Vous pouvez très bien vous servir de tables comme de vulgaires sacs ou espaces de stockage, c'est peut-être parfois nécessaire dans votre cas.

Mais les contraintes de clé étrangère sont tout simplement indispensables lorsqu'il faut garantir l'intégrité des données de la base.

Si vous n'avez aucune contraintes.. comment savez-vous quel brevet a passé un pilote et par conséquent s'il est autorisé à piloter tel type d'avion ?

[Invité]

Le sujet ici est les clé étrangères en SQL et donc indirectement la Théorie Relationnelle.
La normalisation qui a pour but entre autre de réduire la redondance d'information entraine un nombre de tables relativement important. Celles-ci sont très souvent en associées (je n'utilise pas le mot relation volontairement).

Vous pouvez très bien vous servir de tables comme de vulgaires sacs ou espaces de stockage, c'est peut-être parfois nécessaire dans votre cas.

Mais les contraintes de clé étrangère sont tout simplement indispensables lorsqu'il faut garantir l'intégrité des données de la base.

Si vous n'avez aucune contraintes.. comment savez-vous quel brevet a passé un pilote et par conséquent s'il est autorisé à piloté tel type d'avion ?

En fait, on l'ignore souvent car il faut une accréditation pour y avoir accès, alors que son nom se trouve avec le plan de vol. C'est un cas typique de référence croisée (que pensez vous de ce terme ) résolue à postériori.

L'info est stockée sur deux serveurs ultra sécurisés et auquels on n'a accès que dans le cadre de procédures précises. Ces infos arrivent dans un ordre inconnu au départ.
En business intelligence, vous obtiendrez même la marque de sa chemise mais dieu seul sait quand...

[Luc Orient]

... Mais ce me semble limite louche chez vous, ne comptez vous que des sous ? C'est un peu réducteur quand même

Non c'est normal pour moi ... je travaille dans une banque ...

[Invité]

Non c'est normal pour moi ... je travaille dans une banque ...

Ca me rassure aussi de savoir que mon compte ne pourra pas perdre son propiétaire sans bloquer le système entier. Finalement je crois que je vais me ranger à vos arguments. bonne nuit

[fsmrel]

Évidemment, si on m'a perdu une image, je ne fondrai pas en larmes :




Je me permets quand même de rappeler les quelques anecdotes que j’ai évoquées (parmi d'autres)...

http://www.developpez.net/forums/d82...t/#post4720293

Et voyez vous, unBonGars, si la moitié de vos périodes de cotisation pour votre retraite est perdue pour cause de non respect de l'intégrité référentielle, n’aurez-vous quand même pas le cœur un peu serré ? N'éprouverez-vous pas un sentiment de regret ?

[CinePhil]

Primo :
Gérer les contraintes via le sgbd suppose une remontée des messages d'erreur de la base : puis il faut gérer ces messages. Or ils n'ont pas toujours le même sens selon qu'on est en design-time ou au run time. Il peut être bien moins couteux de définir une politique de contraintes serveur souples plutôt que bloquer un client en prod sur un message du style ORA-ERR 1877...

Avant de filer une appli au client, on la teste non ?
Et si ce genre de message d'erreur intervient... ben on intervient pour qu'il n'intervienne plus chez le client !

secundo :
si mon code client fait une "bétise" et supprime une ligne parente non-protégée : je peux préférer connecter la base en admin, trouver les lignes orphelines et me faire ma propre idée de ce qu'il faut faire plutot que laisser l'utilisateur gérer une erreur dont il ne sait que faire.

Je pense que le DBA va t'envoyer sur les roses avant la dixième intervention que tu lui demanderas !

Tertio :
Messieurs les gourous de BDD merci de ne pas vous approprier les SGBD : Certaines applis en font un usage que vous n'imaginez pas et pour lequel vous n'avez pas forcément l'expertise ad hoc.

Bien sûr, les spécialistes en BDD sont spécialistes... en BDD pas en traitement de signal et autres sujets probablement très intéressants cités juste après.
Mais ils posent des questions pour concevoir correctement la BDD qui sera utilisé par le spécialiste du domaine et lui font valider la conception et l'appli avant de lui permetre de jouer avec.

Traitement de signal,

Sans connaître ce domaine, le signal vient d'une source non ?
Tiens, voilà déjà un bout de MCD :
Signal -1,1----Provenir----0,1- Source
Bon je vais vite sur ce bout de schéma mais c'est pour montrer qu'on peut probablement modéliser à peu près tout.

stockage de flux paginé, liaisons anticipées sont monnaie courante dans ma spécialité et tout ceci est assez loin des questions de foreign keys.

Ces domaines là, je ne les connais pas du tout et ne peux donc pas actuellement les modéliser mais avec un peu plus d'informations je suis sûr qu'on doit arriver à quelque chose.

D'autre part : gérer un mauvais client sur lequel on n'a pas la main est aussi le type de pollution à laquelle on peut être confronté. Parfois le théorie vous éloigne de la pratique et c'est le cas ici. Très théorique cette approche, décidément.

Si le client est mauvais, son fournisseur doit l'être aussi ?
Remarque, c'est peut-être un bon moyen de se débarrasser des mauvais clients après tout !

Comme manager, si mon gars ne gère pas les foreign keys mais qu'il sait bien faire des stats,

Ce n'est pas le même boulot.

je lui pardonne volontiers car je peux mettre des contraintes à postériori sur la base de tests solides,

Tests qui prendront du temps à élaborer, à analyser les résultats. Contraintes qui ne fonctionneront peut-être pas parce que des contraintes d'intégrité n'auront pas été implantées au préalable et il faudra alors perdre encore du temps à chercher les erreurs et du temps à les corriger.

alors que je ne peux pas forcément remplacer un bon designer.

Tu auras aussi peut-être autant voire plus de mal à remplacer un bon concepteur de BDD.

Pensez vous que les aiguilleurs du ciel se voient interdire l'usage de BDD ? et les milliers de taches sur leur écran radar = autant de lignes de BDD avec ou sans contrainte FK ?? Messieurs voyez un peu large svp

Les "milliers de taches sur leur écran radar = autant" d'avions avec des humains dedans !
Pas rassurant ce que tu as écrit là !
J'espère que les applis des aiguilleurs du ciel utilisent des BDD solides !

[plemaire]

Et bien, quel article, et je tombe la dessus par hasard … quelle chance.

Je tiens d’abord à préciser que je ne suis pas, contrairement à vous, un fervent adepte d’une solution plutôt que d’une autre. Mes commentaires seront donc purement formels et sans à priori sur le sujet posé.

Tout d’abord votre argumentation du point I.

Il est complètement inutile à mon sens de vérifier que le client existe, puisque c’est la première information ou presque que l’on va demander à un utilisateur quand on crée une commande. Si le client en question n’existe pas, il aura du mal à le sélectionner. Je ne vois donc pas l’intérêt de « Vérifier » son existence.

Ensuite vous introduisez la notion de suppression. Je me permettrais alors de vous demander dans quel logiciel sérieux vous avez constaté ce genre de commande SQL. Que je ne l’achète jamais. Supprimer un enregistrement d’une donnée de référence est totalement obsolète de nos jours, voir criminel. Je ne parlerais que des historiques pour ne citer qu’un seul cas.

Vous parlez aussi de niveau d’isolation. A toutes fins utiles, je vous signale qu’il existe des solutions simples à l’aide de timestamp, qui permettent de valider une donnée au dernier moment. Cela évite notamment de verrouiller des enregistrements (au mieux) trop longtemps.

Il me semble au final que dans votre exemple, vous ne tenez, pour vous justifier, aucun compte ni du process de la donnée dans le temps, ni de son aspect de cascade fonctionnelle. Il est inutile de refaire un contrôle qui à déjà été fait, volontairement ou mécaniquement. Si tel est le cas c’est que votre contrôle n’est pas au bon endroit dans la chaine de traitement des informations.

Dans votre chapitre numéro II.

Il est évident que vous ne faites aucune confiance à votre logiciel, et donc à votre code. Ce que je trouve passablement étonnant pour un développeur, puisque vous opposez alors les contraintes d’intégrités à la qualité du code. Alors que les deux doivent êtres à mon sens complémentaires.
Votre première requête établie une jointure inutile avec la table des employés, si on considère que les données sont cohérentes, et çà c’est un problème fonctionnel et de code, pas de contraintes.
De plus, si vous aviez voulu faire cette même requête sur une période de temps précise, du genre : Quels ont étés les sports des abonnés de 2007 ? Là vous n’auriez pas eux le choix.
Quand aux éventuels « Décalages » ou « Incohérences » de données qui peuvent survenir dans un logiciel, elles sont en générales acceptables, à minima.
Votre postulat est donc très réducteur.

Dans votre chapitre III.

Vous tentez de démontrer que la contrainte imposée par ces contraintes est « Supportable », certes, mais comparer à quoi ? Il est parfois des temps, à mon grand malheur, où le « Supportable » n’a pas sa place. Ce qu’implique une telle démarche n’est ni plus ni moins que d’être « très » structuré, ce qui n’est pas un mal tant que l’on n’abuse pas des bons principes.
Que se passe-t-il à chaque fois que la structure de la SGBD change ?
La contrainte n’est pas toujours à l’endroit précis où on l’imagine.

Dans votre chapitre IV.

Soudain vous redevenez ami avec les développeurs qui d’un coup respectent les normes. Soyons réalistes. Il est très probable que pour des raisons de pure planning ou de coût, si une caractéristique de contrainte d’une base apporte une vraie valeur ajoutée à une problématique, elle soit utilisée, même si elle rendra la portabilité complexe voir infaisable.
Je vous rappel aussi, que l’évolution des versions des moteur est bien trop rapide, à l’instar des OS. Les entreprises en générale ont autre chose à faire que de gérer les changements de versions des différents logiciels qu’elles utilisent. La norme aussi évolue.
L’énorme avantage de la gestion dans le code, entre autre des contraintes (une chance que l’on ne parle pas des Locks) c’est qu’elle possède la stabilité qu’on lui définie, et que l’on n’est pas soumis aux affres de la fuite en avant des éditeurs, parce que ca fait vendre.

Je travaille personnellement sur des ERP qui gèrent les verrous et les contraintes entièrement de façon logicielle, ce qui ne pose en fait aucun problème si cela est fait au bon endroit. Et je parle d’ERP très sérieux, portables ou pas, et très puissants. Je ne crois pas au hasard …


Pour conclure.

Je suis personnellement persuadé que les contraintes sont comme le reste. Si elles sont bien utilisées elles seront un plus, sinon elles seront une catastrophe.
Ce choix impose une connaissance « très » approfondie de « tous » les moteurs du moment. Pour peut que l’on exclu les inévitables BUG que les éditeurs essayent de corriger au fur et à mesure. Seulement voilà, un éditeur de logiciel lui, n’a pas toujours le temps d’attendre que l’éditeur du moteur veuille bien rectifier son erreur. Donc il choisi les solutions qu’il maitrise le mieux et le plus rapidement.

Je trouve votre verve un tantinet forte, et si votre objectif était de faire en sorte que les contraintes d’intégrités des SGBD soient plus utilisées, vous n’avez certainement pas utilisés les bon arguments, ni cités des cas reflétant une vérité concrète.

Je ne pense pas que la gestion des contraintes soit si dur à mettre en place, à condition de les encadrer de façon ultra stricte, et notamment dans leur utilisation par les Devs et les DBA. Et ce, dès le début du projet de développement. Si tel est le cas et que des règles d’usages très strictes sont édictées dès le départ, alors pourquoi pas. Mais quoi qu’il en soit, elles ne retirent en rien la gestion des erreurs liées.

Pour finir, je vous rappel que ce genre de contraintes représentent au final une quantité limité, même si pas sans impacts bien sur, du total des contraintes d’un logiciel, si on les compare aux contraintes fonctionnelles par exemple.

Enfin tout ceci n’engage que moi bien sur …

[plemaire]

Les "milliers de taches sur leur écran radar = autant" d'avions avec des humains dedans !
Pas rassurant ce que tu as écrit là !
J'espère que les applis des aiguilleurs du ciel utilisent des BDD solides !

Je me demande dans tel cas, l'importance de la BDD par rapport à l'ensemble du système.
Les Paraboles ? Les Antennes ? les Recepteurs éléctroniques ? les protocoles et signaux ? l'application elle même ?

La BDD est un outil GENERALISTE, qu'il convient d'utiliser à bon escient dans une application SPECIFIQUE. et si cela imlpique de NE PAS utiliser les FK, je ne vois pas en quoi cela choque. Et je ne comprend pas non plus, comment sans connaitre le besoin fonctionnel et Technique, on peut être aussi catégorique.

[Pierre Fauconnier]

Ne pas poser les contraintes dans la base et déléguer ce travail uniquement au logiciel revient à ne permettre l'utilisation des données que via le logiciel qui gère lesdites contraintes...

Au vu de ce que je rencontre quotidiennement en entreprise, cette approche n'est pas réaliste et empêche la centralisation des données en un seul endroit, avec x logiciels qui se connectent au "datawharehouse"...

[_skip]

A ma connaissance, qu'un programme client plante à cause d'une contrainte d'intégrité qu'il a violée suite à une situation bizarroïde de concurrence, c'est plus facilement acceptable et réparable que des dégâts au niveau de la cohérence des données.

Je suis plutôt partisan de dire que malgré tout le soin apporté à la gestion de situations difficiles dans un code client, le risque de bug est bien présent et des choses inattendues peuvent se produire.
Je préfère un bon gros plantage de mon application avec un message hideux plutôt que prendre le risque d'une insertion/modification foireuse qui se produirait silencieusement. Car ensuite, trouver l'erreur est déjà une chose, l'expliquer peut être très difficile et dans tous les cas la responsabilité du fournisseur de l'application ainsi que sa crédibilité peuvent rentrer en jeu.

Les contraintes ne sont pas la réponse à tout, mais sont toutefois une sécurité supplémentaire non négligeable. D'autant que la portabilité me semble pas si problématique que telle qu'exprimée dans le post précédent.

[plemaire]

Ne pas poser les contraintes dans la base et déléguer ce travail uniquement au logiciel revient à ne permettre l'utilisation des données que via le logiciel qui gère lesdites contraintes...

C'est parfaitement Exact, c'est le cas de tous les logiciels du marché ... à ma connaissance. Et j'irais même jusquà dire que c'est parfaitement volontaire ... vous comprendrez pourquoi ...

Au vu de ce que je rencontre quotidiennement en entreprise, cette approche n'est pas réaliste et empêche la centralisation des données en un seul endroit, avec x logiciels qui se connectent au "datawharehouse"...

Le DATAWHAREHOUSE est un concept fonctionnel, pas une simlpe SGBD. Il a pour obligation de faire entrer dans un moule unique les données de toutes les applications de l'entreprise. Rien à voir avec un logiciel. Quand à ceux que l'on utilise pour la "Restitution", ils ne gèrent rien, au plus ils font des calculs et de la présentation. Rien à voir avec un Logiciel d'autant moins de type ERP.

Dans le cas d'un DW, il est possible je n'en sait rien, que les contraintes soient une bonne chose. Je n'ai pas encore beaucoup étudié ce cas particulier. Mais le peut que j'en ai lut (Ralph Kimball) n'en parle pas du tout. Peut etre car il a considère que c'est une simple caractèristique technique.
Par contre, il incite clairement à la création de clef non significatives dans chaque table, peut est-ce là une spécificité qui induit naturellement l'usage des contraintes.

[plemaire]

A ma connaissance, qu'un programme client plante à cause d'une contrainte d'intégrité qu'il a violée suite à une situation bizarroïde de concurrence, c'est plus facilement acceptable et réparable que des dégâts au niveau de la cohérence des données.

Il faudrait poser la question au client il me semble, dont la seule préocupation sur le moment est : Quand cela remarchera t'il ?
Vous lui repondez : Ben on regarde le bug, rentrez chez vous ?

Je suis plutôt partisan de dire que malgré tout le soin apporté à la gestion de situations difficiles dans un code client, le risque de bug est bien présent et des choses inattendues peuvent se produire.

Dans le code d'un SGBD aussi ....

Les contraintes ne sont pas la réponse à tout, mais sont toutefois une sécurité supplémentaire non négligeable. D'autant que la portabilité me semble pas si problématique que telle qu'exprimée dans le post précédent.

L'expérience elle, semble dire le contraire ... (Enfin parfois).
Ceci dit je suis d'accord sur un point, elles ont leurs usages, mais aussi leurs limites, limites qui peuvent pousser un editeur à ne pas les utiliser, c'est son choix. J'en connait un très bon qui a fait ce choix, et pas par hasard ni par crainte vu les cadors qu'ils ont en DBA.

[Pierre Fauconnier]

C'est parfaitement Exact, c'est le cas de tous les logiciels du marché ... à ma connaissance. Et j'irais même jusquà dire que c'est parfaitement volontaire ... vous comprendrez pourquoi ...

Je comprends ce "pourquoi", mais je ne l'accepte pas. Il existe sur le marché belge quelques logiciels de gestion (compta/commercial) qui ont ouvert leur base de données, et à laquelle on peut se connecter pour lire, bien sûr, mais aussi pour écrire, et dans les pme que je conseille, j'oriente toujours le choix vers ces logiciels et jamais vers les logiciels "propriétaires" de leurs données

Le DATAWHAREHOUSE est un concept fonctionnel, pas une simlpe SGBD.

J'utilisais ce terme entre guillemets car je conçois les données d'une entreprise comme devant obligatoirement être ouvertes et donc je les imagine dans un "entrepôt", un endroit accessible où, via des droits et restrictions d'accès, il est aisé de prendre, mais aussi de modifier. Bien sûr, cela demande que les gestionnaires de données aient bien sécurisé leurs bases, notamment par les FK.

Dans une grande société pour laquelle je développe un truc en Access, on est confronté à un logiciel qui redescend une partie des données via une passerelle, un autre logiciel descendant l'autre partie dont on a besoin. Et à ces deux sources, on joint nos propres données. C'est un foutoir sans nom, les références orphelines sont légion... Bref, une mer*** infâme, alors qu'avec une source unique de données et des FK, les choses seraient beaucoup plus simples.

Dès qu'il y a partage de données, il me semble que les FK sont incontournables, et je trouve inconcevable d'obliger les modifs et ajouts de données via un seul canal. C'est pour moi un non-sens.

[fsmrel]

Je suis personnellement persuadé que les contraintes sont comme le reste. Si elles sont bien utilisées elles seront un plus, sinon elles seront une catastrophe.

Voulez-vous dire que l’intégrité référentielle assurée par le SGBD n’est qu’un plus, donc que la garantir par programme suffirait largement ?

Anyway. Vous aurez beau avoir des DBA qui sont tous des « cadors », des programmes réputés infaillibles, ce n'est pas pour autant que la production informatique sera alors à l'abri d'une erreur d'enchaînement des travaux (disons batch) ou de reprise suite à incident, et de toutes autres erreurs mettant en péril l’intégrité des données : errare humanum est.

L’intégrité référentielle n’a pas pour objet d’assurer l’ensemble des contrôles d’intégrité mais, comme son nom le sous-entend, les relations entre les tables, ce qui est déjà beaucoup : elle est in-dis-pen-sa-ble. Je vous renvoie aux quelques situations fâcheuses que j’ai connues lors de mon (très long) parcours de DBA, en relation avec l’absence préjudiciable de mise en œuvre de cette intégrité :

http://www.developpez.net/forums/d82...t/#post4720293

Plus généralement tout ce qui touche à l’intégrité des données devrait être sous-traité au SGBD. Même si aujourd’hui les SGBD SQL ne sont pas au niveau de la norme (voyez l’instruction CREATE ASSERTION), c’est dans cet esprit qu’il faut considérer l’intégrité d’une base de données. Même si la norme elle-même peut faire aujourd’hui l’objet de bien des critiques.

[plemaire]

J'utilisais ce terme entre guillemets car je conçois les données d'une entreprise comme devant obligatoirement être ouvertes et donc je les imagine dans un "entrepôt", un endroit accessible où, via des droits et restrictions d'accès, il est aisé de prendre, mais aussi de modifier. Bien sûr, cela demande que les gestionnaires de données aient bien sécurisé leurs bases, notamment par les FK.

Voulez-vous dire que l’intégrité référentielle assurée par le SGBD n’est qu’un plus, donc que la garantir par programme suffirait largement ?

Oui, pas forcément mais ce choix est parfaitement défendable.

On peut être idéaliste, je crois l’être, mais à condition d’être réaliste d’abord. C’est comme pour une BDD, on ne peut dénormaliser que si on est capable de normaliser 5 d’abord, et ensuite d’expliquer la dénormalisation. Il ne faut pas prendre de raccourcis.

Je crois que le message que j’ai du mal à faire passer c’est que une donnée c’est d’abord et avant tout le résultat d’un ensemble de règles de gestion, qui donnent à cette donnée sa valeur et sa cohérence. Et je le répète, la cohérence « technique » n’est pas forcement la meilleure, de plus elle représente BEAUCOUP moins de complexité que la cohérence fonctionnelle.
Un exemple simple : Avoir une entête de commande sans ligne ne pose aucun problème de contrainte, mais peut être catastrophique pour le fonctionnel, et là vos contraintes ne servent à rien ! Alors vous allez me dire oui mais dans le sens inverse ? Exact, sauf que si on en arrive là, c’est EN PREMIER LIEU parce que votre code est défaillant (Et dans ce cas là de manière outrageante).
Quelqu’un a cité l’exemple des roues de voiture. Personne ne prétend que les roues (ni la BDD) ne sont pas important, mais je vous rappel que tout un chacun peut choisir sa marque de pneu. Voir même changer les jantes !! La roue est en effet indispensable (comme la BDD), mais dans son aspect fonctionnel. N’importe quelle roue peut faire l’affaire, question de choix et surtout d’usage. Dailleurs je vous soumets une petite réflexion. Les roues sont vides et gonflées, ce qui génère des risques (crevaison), d’après vous, pourquoi ne sont t’elles pas tout simplement pleines ? Il existe aujourd’hui des matériaux qui sont parfaitement capables de remplir les caractéristiques nécessaires à ce que doit faire une roue.

Quand au partage des informations, on peut en débattre durant des années. Le fait est que dans une DSI, il existe deux orientations possibles. Soit vous prenez le meilleur des logiciels dans chaque domaine, et vous faites en sorte qu’ils soient « En phase », Soit vous optez pour le tout intégré, et ainsi, plus de problème référentiel. Dans le premier cas l’intégrité référentiel ne peut être gérée quasiment que à la main. Dans le second vous n’avez pas le choix, et à ma connaissance les éditeurs en général, comme par hasard, n’utilisent pas souvent la sous-traitance des contraintes au moteur de BDD.

Plus généralement tout ce qui touche à l’intégrité des données devrait être sous-traité au SGBD. Même si aujourd’hui les SGBD SQL ne sont pas au niveau de la norme (voyez l’instruction CREATE ASSERTION), c’est dans cet esprit qu’il faut considérer l’intégrité d’une base de données. Même si la norme elle-même peut faire aujourd’hui l’objet de bien des critiques.

Je ne critique pas la norme, mais bien les éditeurs de moteur de SGBD (entre autre) qui se sentent obligés de fournir des versions tous les ans sous peine de ne pas sembler suivre le mouvement. Mais de quoi on parle ? On a l’impression qu’aujourd’hui l’évolution des outils informatiques est liés plus au commerce, à la vente et à la communication, qu’à la réelle technique … SE SONT DES OUTILS, pas des chaussures à la mode que l’on jette tous les ans.
Le problème sous jacent c’est que à force de sortir des versions à qui mieux-mieux elles sont de plus en plus boguées (voyez le nombre de patchs qui sortent …). Ca ne se limite pas d’ailleurs aux BDD. Et je comprends fort bien une personne qui décide de garder la main techniquement sur l’outil de gestion qu’il développe, plutôt que de se retrouvé désolé (mais dans la mouise) que le moteur qu’il a choisi soit bogué.

Pour finir, sa me rappel le débat très ancien des IF et des GOSUB/PERFORM en COBOL. Ils y avaient ceux qui prétendaient que le IF était la seule et unique solution, et ceux qui prétendaient que le PERFORM l’était.
Personnellement, j’ai toujours utilisé les deux, en essayant de le faire à bon escient.
Il n’existe pas de règle qui ne soit incontournable ou qui ne nécessite des adaptations en fonction des besoins.

Ce qui m’a fait régir dans cet article, c’est le ton vindicatif de l’auteur. Soit vous utilisez les contraintes des BDD, soit vous êtes un abruti meurtrier que l’on se doit de mener devant un tribunal. Le monde, et celui des BDD inclus, n’est pas noir ou blanc. Et les dogmes ne servent ni à ouvrir l’esprit, ni à expliquer les choix avec sérénité.

J’ai toujours accepté toutes les solutions, même si parfois je n’y adhère que très moyennement, à partir du moment où le choix est parfaitement clair et réfléchi.
Et cela ne m’empêche absolument pas de A CHAQUE FOIS, me poser la question de ce qui serait le « bien ».
Je fini sur une petite phrase célèbre : Le mieux est l’ennemi du bien.
Et je vous garanti qu’en 20 ans de développement, j’ai pût maintes fois le vérifier.

Les contraintes, ca peut être bien, mais c'est pas obligatoire.

[al1_24]

Je ne critique pas la norme, mais bien les éditeurs de moteur de SGBD (entre autre) qui se sentent obligés de fournir des versions tous les ans sous peine de ne pas sembler suivre le mouvement. Mais de quoi on parle ? On a l’impression qu’aujourd’hui l’évolution des outils informatiques est liés plus au commerce, à la vente et à la communication, qu’à la réelle technique … SE SONT DES OUTILS, pas des chaussures à la mode que l’on jette tous les ans.

J'ai du travailler il y a quelques mois sur un site qui utilisait toujours la version 8 d'Oracle au même prétexte que les nouvelles versions n'apportaient rien.
Quelle difficulté de créer des requêtes efficaces et lisibles dans cet environnement obsolète et a-normal (au sens de ne respecteant pas la norme) sans parler des questions de performance...
Une nouvelle version n'est pas qu'un argument commercial. Elle apporte toujours des évolutions fonctionnelles et/ou techniques. Les métériels évoluent, les systèmes d'exploitation aussi. Il est normal que les applications suivent cette évolution et en profitent.

Quant à la question de l'implémentation des règles de gestion dans l'application ou le SGBD, elle se résumerait pour moi à celà : Cela ne sert à rien de mettre une porte blindée sur la façade si la porte de derrière se ferme avec un crochet rouillé sur une vis branlante.

[plemaire]

Quant à la question de l'implémentation des règles de gestion dans l'application ou le SGBD, elle se résumerait pour moi à celà : Cela ne sert à rien de mettre une porte blindée sur la façade si la porte de derrière se ferme avec un crochet rouillé sur une vis branlante.

Vous parlez de sécurité ? C'est un autre sujet il me semble ...

Quand aux regles de gestion, vous vouliez surement parler des contraintes d'intégrité ... sans doute ...