Discussion :

[plemaire]

C'est le type même de l'argument nul et inutile... C'est quoi une application sérieuse? A vous lire, ce sera une application qui respecte VOS principes, et la non-sérieuse sera celle qui utilise les triggers... Un argumentaire plus fouillé serait bienvenu...

C'est vrai qu'il n existe pas de règle pour définir cela, mais je dirais, par exemple, une application qui gère plus de 100 tables, dont la moitié contiennent des données de base ... mais ca reste approximatif je le reconnais.
Quand à celle qui utilise les TRIGGERS, c'est que son code interne est sufisemment simple pour se le permettre.
Cela reste des critères un peu aléatoires bien sur, c'est un ordre d'idée.
Quand à l'argumentaire, il est pile poil dans mon prost précédent. Et je suis étonné que vous ne me quotiez pas là dessus.

Ah, cette condescendance mal placée, alors qu'il faudrait déjà s'entendre sur le terme "développeur" et ce qu'il recouvre...

Si je me permet d'avoir cette condescendance comme tu la nomme, c'est que depuis mes 20 années de DEVELOPPEMENT, j'ai utilisé non seulement les outils que je cite, mais au bas mots une 15 aines d'autres langages et outils.
Alors je suis désolé si ma "Condescendance" te delpait, mais elle reste le fruit de mon expérience personelle.

C'est peut-être justement parce que je ne suis pas "développeur" selon TA définition du terme, que j'apprécie énormément partager au maximum les données entre diverses applications, de manière à ne pas dépendre du "génie" qui va développer l'erp miracle en me rendant totalement dépendant de lui...

Je suis un passionné d'ETL et de DW. D'autant que dans mon entreprise actuelle, nous n'avons pas moins de 2 ERP complétés d'une 10aine d'autres logiciels spécialisés (CONSO,TEMPS,PROJETS,RH,ORDO,PLANNIF Etc ...). Alors si quelqu'un aime le partage de donnée, c'est bien moi. Et pourtant je ne mélange pas cela avec les contraintes, car comme le disait si bien Jester, Comment gère tu tes contraintes entres 20 bases différentes sur des moteurs différents ? Je suis curieux de savoir ...
Quand à l'ERP magique, en tout cas de réputation, il n'en existe que 2 à ma connaissance, EXCEL et SAP, ce qui évidemment me rend hilare ....

... (oui, j'ai l'outrecuidance de ranger Access dans les SGDB),

Peut être me fera tu le plaisir de citer mes propos quand au fait que ACCESS n'est pas un SGBD ... il me semble même avoir dis quasiment le contraire. Si le débat tourne de cette facon ... il vaudrait mieux que le sujet soit clos définitivement, car personne n'en tirera rien de bon.

Et même lorsque je développe une toute petite application en Access avec des données qui ne seront jamais partagées, je mets systématiquement l'intégrité référentielle, gagnant ainsi pas mal de temps qui aurait été gaspillé à pondre du code...

Il ne me semble pas avoir non plus dis que dans le cadre de petites applications de stockage, et d'autant plus en ACCESS, il est idiot d'utiliser des contraintes.

Je me borne depuis le début à tenter d'expliquer, mais pour cela encore faudrait t'il que l'on me lise, que ce que je réfute, c'est le discours de l'auteur qui prétend que si on n'utilise pas les Contraintes, on est un criminel bon à enfermer. Ce que j'en pense moi, c'est que c'est son discours qui est criminel, car il ne convainc que les afficionados, il n'enfonce que des portes ouvertes, alors où est l'interêt. Se faire mousser devant un public conquis d'avance ? Pas constructif.

Je reste certain qu'un tel article, bien tourné, avec des cas plus réalistes et en prenant un peu de recul vis à vis de ce qu'est "Une Application", l'effet escompté aurait été nettement meilleurs.

Maintenant je vais revenir sur le metier de Developpeur. Beaucoup ici sont du monde de la BDD d'après ce que je constate. Et jusqu'à présent, il ne me semble pas avoir "Dénigrer" le metier de DBA, d'autant que je l'ai vécu aussi. J'aimerait donc, que personne ne dénigre le metier de Developpeur, et ne "Pense" que le developpement c'est une affaire de petit joueurs qui feraient mieux d'êtres des DBA.
Ce metier je l'apprend encore aujourd'hui chaque jour, même au bout de 20 ans et je remerci le ciel pour ca. C'est un vrai metier, comme celui de DBA. Alors soit on adopte une posture et on clos de débat par avance. Soit on se fait plutôt éducateur, formateur, et on fait avancer le sujet. Mais pour ca, il faut aussi accepter les arguements de l'autre camps, et surtout les lires.

Après si vous voulez ... on discute.
Sur un cas précis peut etre même ... vous avez peut etre une application en tête ? comme base de discussion.

[Pierre Fauconnier]

Je suis également partant pour un débat constructif, qui ne s'arrête pas à la forme ou à certains mots, et qui est argumenté. On peut donc, pour ma part, laisser tomber les tiroirs dans lesquels on met ou desquels on exclut les développeurs sur tel ou tel système, et en revenir au thème du débat.

Je suis évidemment d'accord pour dire qu'il faut une intégrité par code entre bases différentes, vu qu'il est impossible de faire autrement. Mais c'est un cas particulier qui n'exclut pas ipso facto d'utiliser les outils natifs à l'intérieur de chaque base.

J'admets donc déjà beaucoup moins que lesdits outils ne soient pas utilisés à l'intérieur de la base, et notamment parce que ce qui est dévolu au SGBD ne doit l'être qu'une fois, quelle que soit la façon dont la base est attaquée. Il me semble qu'il y a donc là trois arguments "pour" l'intégrité "native":
1) Cette intégrité est indépendante des logiciels qui gèrent les données
2) Economie de développement car on place une fois l'intégrité, au lieu de devoir la développer sur chacune des applications qui se connecteront aux données
3) Bien sûr, il y a des bugs, mais j'ai l'impression que l'intégrité native est globalement plus sûre que celle qui sera placée par code...

Et pour moi, même pour une petite application avec données non partagées, voire même verrouillées d'interventions externes à l'application, les trois points cités plus haut restent valables et permettent une économie de code et une sécurité accrue.

[plemaire]

Tout est question de contexte.
Une fois qu’on est d’accord avec ca, il ne reste que de la logique et des choix.

Il faut bien comprendre que là où je suis d’accord avec toi, c’est dans le contexte suivant.

Si l’application tend plus au stockage et à la diffusion de données, qu’à la gestion de choses compliquées. Les contraintes me semblent plutôt une bonne chose.
Je parle par exemple d’une gestion de stock de base, pas trop complexe.
Si on veut parler d’une finance complète avec des immos, de la comptabilité analytique etc., là c’est un autre cas de figure.

Prenons donc notre application de gestion de Stock de Base.
Elle va probablement utiliser 10 ou 15 tables, pas beaucoup plus.
Elle ne sera certainement pas portable.
Et encore moins connectée à d’autres (Enfin probablement).
Comme l’application sera de taille très moyenne, voir petite, on utilisera pour se faire un outil/langage simple/basique/4eme génération …
De ce fait, et par principe je dirais presque, le code doit être minimaliste.
Il est donc dans ce cas là quasi incontournable d’utiliser à fond la BDD.
Comprenons nous bien. Dans ce cas précis, c’est la donnée qui est importante. Je veux dire, par rapport à la complexité de sa gestion. Oui la donnée est toujours importante :p.
Mais cela reste à mon sens des cas spécifiques.

Maintenant, pour des applis un peu plus lourdes, il me semble très possible d’avoir une démarche différente du genre.

Je défini de façon très précise la part des contraintes qui seront dans la BDD, et celles qui seront dans le code. Et là en effet c’est au DBA de vendre son truc.
Il faut bien comprendre que dans ce cas là, le contrôle de certaines contraintes, notamment fonctionnelles, via le code, est inévitable. Il est donc très tentant de les y mettre toutes. Je te garantie que c’est un gain en maintenance applicative ensuite (En principe).
Ce n’est peut être pas un gain en terme de « Cohésion » des données, à la base, mais on peut approcher par code des contraintes BDD, et s’y retrouver sur la maintenance. Enfin là ya pas de chiffres … c’est sur.

Tout ceci à condition de limiter l’usage des ces contraintes :
Uniquement celles qui sont « normalisées » et « Portables ».
Uniquement celles qui entrent dans la catégorie que l’on à définie comme dévolue au BDD.
Cette catégorie est très complexe à définir, car elle ne doit souffrir absolument d’aucune interprétation.
Pour une raison simple, c’est que pour le coup, le développeur lui saura qu’il ne doit pas s’en préoccuper. Il est donc certain qu’il ne le fera pas. Un bon développeur est un développeur fainéant ;p.
A partir de ce moment là, chacun peut travailler de son coté.

Par rapport à tes trois points.
Je pense honnêtement qu’il est illusoire de penser une base de données « APPLICATIVE » en termes de partage entre différents logiciels. Cela existe en fait, mais uniquement dans le cas ou un éditeur de solution rachète un autre logiciel pour compléter son offre. L’intégration ne sera pas totale dès le début. Mais la séparation n’est pas gérable, sincèrement. On en arrivera donc forcément à une situation de produit « Intégré ».

Ce qui fait que ton point 2) saute aussi. Car dans une même application, on ne gère une contrainte fonctionnelle qu’une seule fois aussi. Un seul code.

Quand à ton point 3, franchement, ne l’oublions pas, un moteur de SGBD est développé par des développeurs hein ;p
Donc je n’ais pas vraiment d’avis sur cette question.

Par contre il y a une question que je me pose.

Quelles seraient les contraintes, totalement portables d’un moteur à l’autre, et que l’on pourrait « Sectorisées » ou « Catégorisées » de façon efficace ?

Ma question est sincère hein … Si tu peux y répondre en prenant en compte ce que j’ai écrit plus haut …

Bon ben c’est pas tout mais avec la neige j’ai trois heures de route pour rentrer moi … A+

[fsmrel]

Bonsoir,

Sans doute que je suis pas aussi calé que vous en SGBD, mais laissez moi mes 20 ans de dev de mon coté, et si vous en aviez autant, je pense que la discussion prendrait une tournure différente. Pas forcement négative, mais en prenant en compte un milliers de problématiques que dans votre petit univers vous n'appercevez même pas ... enfin à vous lire.

Je vous laisse volontiers vos vingt ans de développement. Et rassurez-vous, pour ma part j’ai commencé à développer au milieu des années soixante. Par exemple, en 1965-1966, j’ai développé les programmes de gestion du personnel d’un grand établissement public et ceux-ci ont tourné comme une horloge pendant trente ans.

Concernant mon « petit univers », limité il est vrai, puisque je n’ai passé que trente-trois ans dans une société de services et que je ne suis intervenu que dans le monde de la banque, de l’assurance, de l’industrie, de la distribution, de l’armée, de la retraite et j’en oublie (il faudrait que je consulte mon cv). J’ai été développeur, chef de projet, ingénieur système, DBA, concepteur, architecte, j’ai pratiqué l’audit, le prototypage des performances, la consolation, l’extinction d’incendies, la remise en ordre d’applications partant à vau-l’eau, optimisé des applications se traînant lamentablement, et j’ai aussi pas mal enseigné. A la demande d’un banquier qui trouvait que ça ne percutait pas assez vite, j’ai réécrit tout seul un SGBD (non relationnel hélas, mais c’était à une époque où seuls les prototypes comme System R, Ingres, PRTV étaient en phase de développement). Tout ceci m’a beaucoup fait voyager (j’en ai gardé le trauma de l’avion de 7 heures du lundi matin), rencontrer des gens de tous horizons et avoir des discussions passionnées tout aussi bien dans la soute, là où l’on doit mettre du charbon pour faire avancer la machine et produire des résultats concrets (faire rentrer les sous), que dans les hauteurs raréfiées, là où l’on échange avec les théoriciens, et où l’on n’a pas à se soucier de ce qui a trait au temps, à l’espace et autres considérations terriblement matérielles. Je n’ai pas pratiqué la vente et le marketing, je ne suis qu’un ingénieur, aussi mon univers est-il limité et, je vous l'accorde, je n’ai pas été confronté à un millier de problématiques, j’ai surtout à faire en sorte que la production informatique chez mes clients fournisse les résultats attendus, dans les délais prévus, dans la limite des budgets impartis. Ceci fait que j’ai passé des nuits et des nuits à prototyper les performances des applications afin de m’engager auprès des clients de mon entreprise sur des chiffres concrets, bien avant que ne commencent les développements (attention aux pénalités...)

Quoi qu’il en soit, ma modeste expérience m’a permis de retirer certains enseignements de tout cela. Notamment quant à la façon d’utiliser les SGBD. Ceci transpire dans ce que j’ai écrit au sujet de l’intégrité référentielle dans Défense et illustration de l'intégrité référentielle — et que manifestement vous n’avez pas lu ou pas compris—, concernant les contrats pour lesquels on a perdu les titulaires, ou encore les périodes de cotisation pour la retraite qui se sont évaporées, sans pour autant que le code applicatif eut à être mis en cause et devoir porter le chapeau.

Si je construit une application, je vais tacher de centraliser au maximum, et de donnée une cohérence maximum à ce que je construit. Et pour faire cela il n'existe pas 50000 solutions, il faut standardiser l'intelligence de l'application, et la centraliser dans un seul outil. Pour des raisons évidentes de maintenabilité d'une application, de passage de connaissance, de documentation etc, il est Absolument incohérent d'éparpiller les cibles potentielles de recherche en cas de BUG de l'application.

Le catalogue relationnel est tout indiqué pour centraliser tout ce qui concerne la base de données. Si un chef de projet part en vacances sans dire où sont les dossiers, à l’aide du catalogue on peut reconstruire le modèle des données, retrouver les requêtes qui les manipulent, les contraintes, les droits, juger de l’état de désorganisation de ces données, etc. (j’ai effectivement eu à effectuer en catastrophe ce genre de tâche). Et surtout, le catalogue est pertinent, par construction il est à jour, ce qui n’est pas toujours le cas des dossiers (j’en sais quelque chose) quand plusieurs personnes se sont succédées dans les travaux de maintenance. En cas d’incident, ou de bug, le catalogue relationnel est fort précieux. Mais peut-être n’utilisez-vous pas de tables, seulement des fichiers ? Auquel cas, il ne vous reste évidemment que votre propre dictionnaire de données.

Et puis quand votre application est urbanisée en référentiels (Personnes, Contrats, Catalogue produits, Cotisations, Prospection de masse, Habilitations, Organismes partenaires, Éditique, etc.), que le tout représente deux mille tables (persistantes), dont certaines d’entre elles pèsent des centaines de millions de lignes, que vous démultipliez tout cela en environnements divers (production, intégration, recette, développement, système, tests des utilisateurs, and so on), les DBA sont bien contents d’avoir sous la main le(s) catalogue(s) pour synchroniser, dupliquer, comparer, réorganiser, maintenir tout ce vaste monde (« Pour après-demain, je veux un environnement identique à celui de la production », dixit le chef). A défaut ils seraient impuissants ou à tout le moins mettraient beaucoup trop de temps pour faire ce qu’on leur demande.

Maintenant, si vous arrivez à mettre au point un ERP complet, sans autre code que des contraintes d'intégrités, ... pourquoi pas, mais je ne sait pas pourquoi, j'ai un leger doute ...

Vous ne m’avez pas compris. Je fais la part entre les données et les traitements qu’on leur applique. L’organisation des traitements n’est pas du ressort du SGBD, mais l’’intégrité des données, les contraintes qui les concernent, oui. Quand j’écris : « Le montant total des salaires des employés des départements de l’entreprise ne doit pas dépasser tel pourcentage par rapport au budget des départements », je ne produis rien, donc je ne décris pas un traitement, mais une règle de gestion des données formalisable dans le langage relationnel ou en SQL, sous forme de contrainte.

Pour information, la première fois que j’ai utilisé un SGBD, à savoir IMS/DL1, j’ai tout de suite mis en oeuvre l’intégrité référentielle. Certes, IMS/DL1 n’est pas relationnel, mais à l’époque (en 1973), IBM offrait déjà le mécanisme. Nous fûmes nombreux à lui en savoir gré.

[plemaire]

…. Par exemple, en 1965-1966, j’ai développé les programmes de gestion du personnel d’un grand établissement public et ceux-ci ont tourné comme une horloge pendant trente ans.

Juste une question qui n’a rien d’impertinente, mais qui est issue aussi de mon expérience.
Vous avez travaillé pendant ces trente années dans cet organisme public ?

…Quoi qu’il en soit, ma modeste expérience m’a permis de retirer certains enseignements de tout cela.

CV assez impressionnant c’est sur …

Ceci transpire dans ce que j’ai écrit au sujet de l’intégrité référentielle dans Défense et illustration de l'intégrité référentielle — et que manifestement vous n’avez pas lu ou pas compris—,

Non en effet je ne l’ai pas lut, puisque l’objet de ma réaction était l’article sur lequel nous commentons. Mais je vais tacher de prendre le temps de le lire.

… Si un chef de projet part en vacances sans dire où sont les dossiers, à l’aide du catalogue on peut reconstruire le modèle des données, par construction il est à jour, ce qui n’est pas toujours le cas des dossiers (j’en sais quelque chose) quand plusieurs personnes se sont succédées dans les travaux de maintenance.

Vous qui avez cette impressionnante expérience, vous devriez savoir que le code aussi permet se genre de chose. Je ne me fie jamais uniquement aux dossiers.
De plus vous parlez du catalogue de la BDD, je comprends bien que c’est un argument pour vous, mais je perçois mal le lien avec l’usage des contraintes, et son choix réfléchi. C’est juste que vous préférez regarder dans une BDD que dans du code ?

Mais peut-être n’utilisez-vous pas de tables, seulement des fichiers ? Auquel cas, il ne vous reste évidemment que votre propre dictionnaire de données.

En fait non, je n’utilise que du papier, recyclé bien sur. Et des crayons non polluants. Des Tables ? Bien sur que j’en utilise, sur quoi pensez-vous qu’est posé mon ordinateur ?

Et puis quand votre application est urbanisée en référentiels (Personnes, Contrats, Catalogue produits, Cotisations, Prospection de masse, Habilitations, Organismes partenaires, Éditique, etc.), que le tout représente deux mille tables (persistantes), dont certaines d’entre elles pèsent des centaines de millions de lignes, que vous démultipliez tout cela en environnements divers (production, intégration, recette, développement, système, tests des utilisateurs, and so on), les DBA sont bien contents d’avoir sous la main le(s) catalogue(s) pour synchroniser, dupliquer, comparer, réorganiser, maintenir tout ce vaste monde (« Pour après-demain, je veux un environnement identique à celui de la production », dixit le chef). A défaut ils seraient impuissants ou à tout le moins mettraient beaucoup trop de temps pour faire ce qu’on leur demande.

Qu’entendez vous par urbanisé ?
Pour ma part, il me semble que l’urbanisation des SI est le fait (entre autre) de faire communiquer des systèmes différents entre eux (Mais peut être n’est ce que partiel). Quoi qu’il en soit, vous parlez encore de votre Catalogue, que je n’ai jamais dénigré je crois … à moins que vous ne citiez mes propos.
Quand à dupliquer un environnement SGBD, même compliqué, je pensais vu votre expérience que cela ne vous prendrait pas plus de quelques heures … et encore … Je peux vous faire une procédure pour SQLSERVER si vous voulez, Oracle est Informix c’est trop vieux pour moi (pas pratiquer depuis trop longtemps)… désolé. Ceci dit, je reconnais que nos bases sont petites puisqu’elles ne font qu’environ 35Go. Pas de quoi fouetter un chat donc …

Vous ne m’avez pas compris.

Voilà au moins un sentiment que nous partageons.

« Le montant total des salaires des employés des départements de l’entreprise ne doit pas dépasser tel pourcentage par rapport au budget des départements », je ne produis rien, donc je ne décris pas un traitement, mais une règle de gestion des données formalisable dans le langage relationnel ou en SQL, sous forme de contrainte.

Je ne dis pas que ce n’est pas formalisable sous forme de contrainte BDD, et encore que j’aimerais avoir un avis éclairé sur la méthode précise (code SQL) et sa portabilité, je dis simplement que pour ma part, ce genre de contrôle Fonctionnel n’a absolument rien à faire dans une BDD. Dailleurs je trouve l’exemple drôlement exotique … En général les financiers préfèrent des contrôles que l’on peu outrepasser, que des bridages stricts, enfin en France en tout cas, et dans les entreprises où j’ai travaillé (Oui juste 4 en 20 ans, parce que je considère que la culture d’entreprise vaux mieux qu’un consultant … mais c’est un autre débat).

Pour information, la première fois que j’ai utilisé un SGBD, à savoir IMS/DL1, j’ai tout de suite mis en oeuvre l’intégrité référentielle. Certes, IMS/DL1 n’est pas relationnel, mais à l’époque (en 1973), IBM offrait déjà le mécanisme. Nous fûmes nombreux à lui en savoir gré.

Puis je vous demandé combien de temps exactement vous avez été développeur ?
N’y voyez rien de malicieux, c’est une question sincère.
Au final voilà au moins une phrase qui parle du problème d’origine.

PS: Les futurs posts qui n'apporteront rien au debat ne seront plus repris par moi, j'ai autre chose à faire en se moment.

[Jester]

En général les financiers préfèrent des contrôles que l’on peu outrepasser, que des bridages stricts,

C'est aussi un point important, toute contrainte pourra être transgressé un jour. De même on peut vouloir mettre des contraintes a posteriori, par exemple si l'on ajoute de nouvelles informations dans la BD, information non présente pour les données plus ancienne.

Du coup c'est un problème que je ne vois pas comment régler de façon élégante et générale.

[Pierre Fauconnier]

...En général les financiers préfèrent des contrôles que l’on peu outrepasser, que des bridages stricts, enfin en France en tout cas, ...

Là, je suis d'accord avec PLemaire et Jester...

Outre le fait que c'est contrainte n'est pas une contrainte d'intégrité, mais une contrainte fonctionnelle, et que ce propos est donc légèrement HS, elle n'a à mon avis pas grand chose à faire dans le SGBD et c'est le code qui verrouillera (ou déverouillera) l'enregistrement du dépassement suite à l'intervention humaine de qui de droit via l'appli...(C'est mon avis...).

Je reprendrai également l'exemple cité plus haut d'une commande sans ligne de commande... Je n'aimerais pas du tout que l'on me mette cette contrainte dans la base, et si on la mettait par code, je voudrais pouvoir la déverrouiller, car il existe des cas où il peut être pertinent de pouvoir encoder une commande sans ligne de commandes.

Ces deux exemples montrent que placer des contraintes fonctionnelles dans la table est à mon avis un choix périlleux.

Les contraintes dans la base (en ce compris celles liées à l'intégrité référentielle, sujet de cette discussion) ne doivent être placées que pour assurer l'intégrité des données (typage, relations entre les tables, incohérences manifestes (dates de naissance ultérieures à la date du jour (et encore, je suis déjà plus réservé de placer ce contrôle dans la base), ...).

A l'extrême (à peine, d'ailleurs), je préfère n'avoir dans la base que les contraintes d'intégrité référentielle, de façon à m'assurer que
- On pointe vers une donnée qui existe
- Une donnée vers laquelle on pointe ne puisse être effacée

En gros, je dirais que c'est le minimum ET le maximum que je souhaite voir géré par la base, tous autres contrôles (fonctionnels, donc) étant dévolus au code applicatif.

Et j'admets bien entendu la limite de cette intégrité référentielle au périmètre de chaque base, ce qui implique l'alternative suivante:
- Gérer les relations interbases par code
....- soit avec contrôles a posteriori ( )
....- soit avec verrouillage des données qui ne pourront être gérées que par une seule appli ( )
- Essayer (pas toujours possible) de regrouper les données au sein d'une seule base...

[plemaire]

D'accord avec Jester Et Pierre.

J'avais pensé aussi en contre exemple, aux contraintes à géométrie variable.
C'est à dire que la formulation de la contrainte elle même change en fonction d'une ou de plusieurs autres données, elles mêmes variables.

Je ne suit pas loin de penser comme Pierre, que les contraintes tout à fait acceptables sont principalement celles qu'il cite (Sauf la dernière sur la date de naissance :p). Etant entendu qu'il vas falloir un petit Brain storming avec le Dev pour que code et contraintes soient parfaitement complémentaires. Ceci dit, le résultat doit être une tuerie !!

Par contre, je ne suis pas au niveau d'un bon DBA. Et je me dis qu'il en existe peut etre d'autres que l'ont pourraient demander au moteur de gerer sans que cela ne diminue la "Lisibilité de l'application" dans son ensemble. C'est à dire sans "Eparpiller" l'intelligence de l'application.

Je me dis que peut etre un DBA à déjà réfléchi à cela, et je serait fort interressé d'avoir un avis là dessus avec quelques exemples.

[CinePhil]

La date de naissance qui ne doit pas être supérieure à la date du jour, voire même à une date plus ancienne selon la nature de l'individu dont on enregistre la date de naissance, est à mon avis un bon exemple de contrainte devant être placée dans le SGBD.

Soit une table Personne comprenant une colonne date_naissance.
Cette table est alimentée par plusieurs applications :
- La gestion du personnel ;
- La gestion des intérimaires ;
- La gestion des candidatures à un emploi ;
- La gestion des contacts professionnels.

4 applications. 4 fois le codage de la même contrainte ?
Une ligne de SQL suffit :

Code :

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

CHECK date_naissance IS NULL OR date_naissance <= CURRENT_DATE

[Pierre Fauconnier]

Cas vécu (c'est pour cela que je l'ai cité):

La date serveur était erronée pour une raison x, et on ne savait pas encoder les factures du jour parce que ultérieures à la date du système... (C'était une contrainte par code, mais on était quand même bloqué...)
On pourra digresser autant qu'on veut sur les cas particuliers... Cet exemple illustre clairement que, quelle que soit la façon dont on s'y prend, l'important est d'abord de réfléchir sur les contraintes que l'on va placer (par code ou dans la base). Après, ce sera une question de choix...

Cela étant, si une contrainte doit être placée et qu'elle ne peut souffrir aucune exception, alors, je préférerai la placer dans la base, notamment pour l'économie d'échelle que Cinephil soulève...

[CinePhil]

Et la fonction du langage de l'application qui va devoir vérifier la date du jour, elle va la chercher où la date ? Aussi d'une horloge interne de la machine où tourne le programme.
Pour peu que les 4 applis tournent sur 4 machines différentes qui ne sont pas à la bonne date, ça fait 4 fois plus de bugs à chercher la cause !

Le serveur n'est pas à la bonne date ?

Une liaison avec un serveur ntp et c'est corrigé. Ca doit prendre... 5 minutes ?
Et c'est corrigé une fois pour toutes !

Un autre exemple vécu :
Je ne sais plus si c'est dans cette discussion que j'en ai parlé mais j'ai travaillé à l'INRA sur des données récupérées de la base nationale d'identification des bovins.
J'y ai trouvé :
- des animaux dont l'identifiant de la mère faisait référence à un animal de sexe mâle !
- des vaches ayant vêlé le jour de leur naissance !
- des veaux nés avant leur mère !

Et pas quelques animaux mais des dizaines, voire des centaines ! Et sur seulement deux ans de données !

[plemaire]

La date de naissance qui ne doit pas être supérieure à la date du jour, voire même à une date plus ancienne selon la nature de l'individu dont on enregistre la date de naissance, est à mon avis un bon exemple de contrainte devant être placée dans le SGBD.

Soit une table Personne comprenant une colonne date_naissance.
Cette table est alimentée par plusieurs applications :
- La gestion du personnel ;
- La gestion des intérimaires ;
- La gestion des candidatures à un emploi ;
- La gestion des contacts professionnels.

4 applications. 4 fois le codage de la même contrainte ?
Une ligne de SQL suffit :

Code :

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

CHECK date_naissance IS NULL OR date_naissance <= CURRENT_DATE

Pour faire simple Non.

Je ne vois pas pourquoi encoder cette contrainte 4 fois.
Si ce sont 4 logiciels différents, ils n'utiliseront pas la même base.
Si ce sont 4 modules d'un même logiciel, ils utiliseront tous les 4 la même "Fonction codée" pour appliquer ce contrôle.
L'argument ne tiens pas à mon sens ...

Maintenant developpont un peu (L'exemple est un peu farfelu mais j'en trouverait un mieux):
- La gestion du personnel (N'a pas le droit de créer si la date de naissance est < date du jour).
- La gestion des intérimaires (Elle a le droit mais uniquement si c'est pour une fille);
- La gestion des candidatures à un emploi (N'a pas le droit de créer une date de naissance si elle est est > datejour);
- La gestion des contacts professionnels (Ne dois JAMAIS renseigner la date de naissance).

Tu me remet le code SQL de ta contrainte là ?

[Pierre Fauconnier]

Philippe,

J'ai bien précisé que le problème que j'avais rencontré été lié à du code et non à une contrainte de base. Ce que j'ai voulu dire, c'est que placer une contrainte (de base ou de code) n'est pas trivial et doit faire l'objet d'une réflexion approfondie...

Une liaison avec un serveur ntp et c'est corrigé. Ca doit prendre... 5 minutes ?
Et c'est corrigé une fois pour toutes !

Si les personnes qui ont ce droit sont là et disponibles pour le faire...

Donc, pour cette contrainte, je préférerai personnellement un code qui m'informe d'une possibilité d'erreur de saisie puis qui verrouille ou laisse passer en fonction des droits de l'utilisateur...

Comme je l'ai précisé également, on pourra digresser pendant des années sur chaque cas particulier. Ce qui me semble important à relever, c'est qu'il n'y a pas UNE véritéet que, avant de contraindre, d'obliger ou d'interdire, il convient d'en mesurer les conséquences. Et pour moi, sauf pour l'intégrité référentielle, les contraintes de base sont trop verrouillées. Je le répète, ce n'est que mon avis...

[CinePhil]

Philippe,

J'ai bien précisé que le problème que j'avais rencontré été lié à du code et non à une contrainte de base. Ce que j'ai voulu dire, c'est que placer une contrainte (de base ou de code) n'est pas trivial et doit faire l'objet d'une réflexion approfondie...

Je suis bien d'accord avec ça !

Si les personnes qui ont ce droit sont là et disponibles pour le faire...

C'est pareil pour n'importe quelle machine ! Si l'application qui contient la contrainte est sur un serveur, le problème est identique. Mon petit doigt me dit que dans pas mal de cas, c'est le même serveur qui héberge les données et l'application...

Donc, pour cette contrainte, je préférerai personnellement un code qui m'informe d'une possibilité d'erreur de saisie puis qui verrouille

Donc idem contrainte sur la donnée en SGBD.

ou laisse passer en fonction des droits de l'utilisateur...

On commence à entrer sur un terrain dangereux au niveau de la qualité des données. Là aussi :

doit faire l'objet d'une réflexion approfondie

avant de contraindre, d'obliger ou d'interdire, il convient d'en mesurer les conséquences.

Bien d'accord avec ça et c'est vrai pour les contraintes de code et de BDD.

Et pour moi, sauf pour l'intégrité référentielle, les contraintes de base sont trop verrouillées. Je le répète, ce n'est que mon avis...

Pour revenir à mon exemple des bovins, j'ai soupçonné que cette masse de données rigolotes (mais fausses) était dûe d'une part à l'absence de contraintes en BDD (cohérence de date ou NULL) et à l'existence de contraintes logicielles (saisie obligatoire d'une date entraînant le paysan qui acheté une vache et dont il ne connait pas la date de naissance à saisir n'importe quelle date).

Le diable n'est pas toujours où on le pense !

[plemaire]

Le diable n'est pas toujours où on le pense !

Et c'est au combien vrai !!. Mais là on parle plus d'ergonomie à mon sens. Sujet tout aussi important, mais pas celui en cours :p

Vous allez voir que finalement nos avis ne sont pas si divergeants.

Par contre j'aimerait une réponse à ma question aussi ... te plait.

[CinePhil]

Je n'avais pas vu ton message.

Si ce sont 4 logiciels différents, ils n'utiliseront pas la même base.

J'ai bien dit dans mon exemple UNE table personne (sous entendue dans une base de données centralisée) alimentée par les quatre applications.

Certains préféreront peut-être avoir des données différentes mais je trouve dommage qu'un candidat ou un intérimaire devenant salarié doive être enregistré deux fois. Ou un intérimaire qui postule à une création de poste. Ou un prospect qui devient client. Ou un contact qui devient salarié...
Ce sont toujours la même personne qui n'a pas le don d'ubiquité et n'a pas à l'avoir dans un même système d'informations.

L'argument ne tient pas à mon sens ...

Nous n'avons pas le même sens ! Remets toi à l'endroit !

Maintenant developpons un peu (L'exemple est un peu farfelu mais j'en trouverai un mieux):
- La gestion du personnel (N'a pas le droit de créer si la date de naissance est < date du jour).
- La gestion des intérimaires (Elle a le droit mais uniquement si c'est pour une fille);
- La gestion des candidatures à un emploi (N'a pas le droit de créer une date de naissance si elle est est > datejour);
- La gestion des contacts professionnels (Ne dois JAMAIS renseigner la date de naissance).

Il est tellement farfelu que j'hésite à répondre !

J'espère que tes 20 ans de développeur ne t''ont jamais fait coder des trucs aussi farfelus !

Admettons quand même que la gestion des contacts professionnels ne doit jamais renseigner la date de naissance tout simplement parce que ce n'est pas prévu dans l'appli. Ma contrainte sur la colonne date_naissance autorise le cas IS NULL.
Car même si ladite appli prévoit le champ Date de naissance, on peut très bien ne pas la connaitre. Ce sera même probablement la majorité des cas.
De même qu'on peut avoir des candidats ou des intérimaires dont on ne connait pas cette date.
Dire à la base de données qu'on ne connait pas la date de naissance et donc ne pas lui donner de valeur satisfait à la contrainte et le SGBD ne renverra pas d'erreur.

Tu me remets le code SQL de ta contrainte là ?

Pour les exemples raisonnables, ma contrainte tient le coup !
Pour les autres, je recommande au concepteur de prendre des vacances !

[Luc Orient]

... Je reprendrai également l'exemple cité plus haut d'une commande sans ligne de commande... Je n'aimerais pas du tout que l'on me mette cette contrainte dans la base, et si on la mettait par code, je voudrais pouvoir la déverrouiller, car il existe des cas où il peut être pertinent de pouvoir encoder une commande sans ligne de commandes.

C'est pas tellement la commande sans ligne de commande qui me gène moi ... Après tout pourquoi pas ... Mais c'est bien la ligne de commande sans commande ... Je pense que là on a un vrai problème ...

[fsmrel]

Bonsoir,

Juste une question qui n’a rien d’impertinente, mais qui est issue aussi de mon expérience.
Vous avez travaillé pendant ces trente années dans cet organisme public ?

Non. J’y suis resté quatre ans. Je l’ai quitté pour la SSII dont j’ai fait partie pendant plus de trente ans. De temps en temps j’avais des nouvelles de l’application, jusqu’à ce qu’un jour, il y a maintenant quinze ans, on m’annonce la mort du petit cheval.

Vous qui avez cette impressionnante expérience, vous devriez savoir que le code aussi permet se genre de chose. Je ne me fie jamais uniquement aux dossiers.
De plus vous parlez du catalogue de la BDD, je comprends bien que c’est un argument pour vous, mais je perçois mal le lien avec l’usage des contraintes, et son choix réfléchi. C’est juste que vous préférez regarder dans une BDD que dans du code ?

Prenons deux exemples.

Exemple 1

Du temps où les SGBD relationnels n’existaient pas sur le marché, une entreprise appelle ma SSII à l'aide, laquelle me dépêche sur place pour réaliser un audit. Tous les programmes — disons batch — se traînent lamentablement et une nuit ne suffit pas pour tout traiter. Je choisis de commencer par expertiser le premier programme de la chaîne, car il lui faut au moins deux heures pour contrôler les mouvements portant sur quelques dossiers de clients. J’explore le code source (en espérant que celui-ci corresponde au code compilé en production). Le développeur n’a sans doute jamais entendu parler de Dijkstra, mais peu importe, je reconstitue son algorithme d’« avancement des fichiers » :

Pour le premier mouvement, ouvrir le fichier Clients, le lire séquentiellement jusqu’à trouver le client dont le numéro est égal à celui qui figure dans le mouvement, contrôler le mouvement, puis continuer à lire séquentiellement le fichier Clients jusqu’à la détection de la fin de celui-ci et le fermer.

Pour tous les autres mouvements, même punition, ouvrir le fichier Clients et le balayer de A à Z. On est en présence d’un magnifique produit cartésien et vous conviendrez que comme algorithme, il y a plus efficace.

Dans tout cela, il a fallu que je joue les fouille-m..., m’imprègne de la logique, voire de la psychologie du développeur (qui bien sûr n’était plus là), il a fallu qu’un autre développeur réécrive le programme en suivant mes recommandations algorithmiques, qu’il le teste, et que j’en mesure la vitesse d’exécution.

J’ai dû faire appel à mon ami Nanard (qui préfère lire le code directement en hexadécimal) pour m’aider à expertiser tous les programmes que j’avais identifiés comme suspects. J’ai passé des nuits en salle-machine pour tester les améliorations, accompagné du Secrétaire général qui était vivement intéressé.

Comme pour Paris, vous imaginez que tout cela ne s’est pas fait en un jour...

Exemple 2

Vingt ans plu tard, une autre société, un très gros projet (environ 300 personnes lui sont affectées). Il est dix-huit heures et je croise des utilisateurs qui s’apprêtent à rentrer chez eux. Ils ont les yeux battus et sont résignés. Que se passe-t-il ? On discute cinq minutes. Ils ont pour mission de tester la partie transactionnelle d’une partie importante du projet et les temps de réponse sont effroyables : il est évident que certains finiront par craquer. Comme je ne connais pas la partie fonctionnelle, je demande à un ingénieur bien au courant de rester pour m’aider à essayer de faire quelque chose. Il jouera le rôle de l’utilisateur.

Et c’est parti pour la nuit. Cette fois-ci, on a un SGBD musclé, c’est DB2. Je prends donc ma casquette de DBA, et consulte les journaux enregistrés par Detector, outil dédié à DB2 et qui en consigne toute l’activité, d’un point de vue système (merci Platinum). C’est parti pour afficher toutes les transactions qui patinent. Pour chacune d’elles, affichage des requêtes coupables (consommation CPU, temps « elapse », nombres d’accès par table, etc.). Aménagement des requêtes SQL affichées en clair (Detector les récupère directement dans le catalogue de DB2), création des index nécessaires pour la performance, test à nouveau des requêtes par EXPLAIN, rebind des programmes puis exécution des transactions par le collègue. Au petit matin, tout fonctionne, avec des temps de réponse excellents. Quand les utilisateurs testeurs arrivent, avec mon comparse nous observons discrètement leurs réactions : ils n’en croient pas leurs yeux, « ça marche ! »... Il leur reste à nous offrir le café et les croissants. Sans le catalogue relationnel, c’eut été mission impossible, et grâce à Detector une nuit a suffi (au lieu de trois, au moins).

Conclusion

Quand il faut regarder dans le code, je le fais sans hésiter, mais je préfère m’intéresser au quoi plutôt qu’au comment, c'est-à-dire à l’essentiel. Dans le cas de l’exemple 1, il a fallu que je retrouve l’algorithme élucubré par le développeur, alors que s’il avait eu un SGBDR à disposition, il se serait contenté de coder une jointure pour rapprocher mouvements et dossiers et l’on n’aurait vraisemblablement pas eu besoin de mes services.
Dans le cas de l’exemple 2, tout est dans le catalogue, sous forme de tables, donc accessible à l’aide de requêtes SQL et si Detector gère ses propres données, il a aussi besoin du catalogue, tout comme moi.
Que les contraintes, soient centralisées elles aussi dans le catalogue n’est pas pour me déplaire, aussi modestes soient-elles (la date de facture doit être du type DATE), ou un peu plus étoffées (une facture doit comporter au moins une ligne). Il va sans dire que les contraintes d’intégrité référentielle doivent y figurer, elles sont la traduction des relations établies entre les entités-types des modèles conceptuels (ou des diagrammes de classes), c'est-à-dire qu’elles sont au cœur du système et que l’on ne peut se permettre le moindre raté.

Qu’entendez vous par urbanisé ?
Pour ma part, il me semble que l’urbanisation des SI est le fait (entre autre) de faire communiquer des systèmes différents entre eux (Mais peut être n’est ce que partiel).

En l’occurrence, j’ai parlé d’urbanisation au sens référentiels (référentiel Personnes, référentiel Contrats, etc.) il s’agit donc d’un découpage en sous-projets (voire sous-sous-projets), communiquant entre eux pour s’échanger des données), mais indépendants, dans la mesure où le référentiel A n’a pas le droit de toucher aux données du référentiel B. Corollaire : tension permanente entre les chefs de projets : « Tu veux telles données ? ça te coutera tant (il faut développer le service qui va bien)... ».

Quand à dupliquer un environnement SGBD, même compliqué, je pensais vu votre expérience que cela ne vous prendrait pas plus de quelques heures … et encore …

J’ai parlé de deux mille tables dont certaines comportent des centaines de millions de lignes... La production a son mot à dire, car elle doit trouver l’espace disque, trouver du temps pour recopier les tables et index, les programmes, effectuer les BIND, etc. Tout cela se planifie et ne se fait pas en claquant des doigts, les opérations se font plutôt le week-end. En réalité, le chef formule sa demande longtemps à l’avance, il est conscient qu’il ne s’agit pas de « monter » une base de données jouet. Lui aussi a une certaine expérience.

Je ne dis pas que ce n’est pas formalisable sous forme de contrainte BDD, et encore que j’aimerais avoir un avis éclairé sur la méthode précise (code SQL) et sa portabilité, je dis simplement que pour ma part, ce genre de contrôle Fonctionnel n’a absolument rien à faire dans une BDD.

Reprenons l’exemple :

Le montant total des salaires des employés des départements de l’entreprise ne doit pas dépasser tel pourcentage par rapport au budget des départements.

Supposons que le pourcentage soit de 50%. En respectant la norme SQL, le code de la contrainte est le suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE ASSERTION Assert1 CHECK
  (NOT EXISTS (
   SELECT ''
   FROM   Departement x JOIN 
               (SELECT DeptId, SUM(EmpSalaire) AS TotalSal
                FROM   Employe
                GROUP BY DeptId) AS y
            ON x.DeptId = y.DeptId
   WHERE  x.DeptBudget * .5 < y.TotalSal
  )) ;

DeptId identifie le département, DeptId identifie l’employé.
Je vous laisse le soin de sous-traiter à votre DBA de traduire la chose sous forme de trigger au cas où votre SGBD ne propose pas l’instruction CREATE ASSERTION.
Quant à dire que la contrainte n’a pas à être sous-traitée au SGBD, c’est le point de vue du développeur, pas celui du spécialiste du Modèle Relationnel de Données. En effet, ce modèle embrasse non seulement les aspects structure et manipulation des données, mais aussi leur intégrité. Cela dit, je ne vous en voudrai pas si vous préférez tout contrôler par vous-même, puisqu’après après tout vous avez la maîtrise complète de vos applications. Je vous en voudrai d’autant moins que, si vous avez à en passer par des triggers (SQL), ceux-ci ne font pas partie du Modèle Relationnel de Données...

Dailleurs je trouve l’exemple drôlement exotique …

Cet exemple n’a pas pour objet de représenter la réalité d’une entreprise, mais simplement de signaler qu’un trigger peut comporter des failles quand les contraintes ne sont pas basiques.

Par ailleurs, on sait que les contraintes sont sujettes à évoluer dans le temps, ce qui suppose que les données impliquées qui ne sont pas invariantes soient datées et correctement historisées. Par exemple, l’attribut DeptBudget de la table Departement (budget du département) change de valeur dans le temps et doit être accompagné d’un attribut de type Date, permettant de savoir depuis quand (SINCE) le budget a sa valeur actuelle. Par voie de conséquence, le budget doit faire à lui seul l’objet d’une table pour en tenir l’historique, table comportant trois attributs : l’identifiant du département, la valeur du budget et la période (DURING) (date début, date fin) pendant laquelle cette valeur a été active pour le département.

Ce qui vaut pour le budget des départements vaut évidemment aussi pour les salaires des employés : La table Employe comporte un attribut de type date, permettant de savoir depuis quand un employé a son salaire actuel et on doit disposer d’une table historiques des salaires, avec trois attributs : identifiant de l’employé, valeur du salaire et la période (début, fin) pendant laquelle cette valeur a été active pour l’employé. Mais là, je dérive vers le niveau théorique et je vous renvoie une fois encore à l’ouvrage Temporal Data and the Relational Model.

Puis je vous demandé combien de temps exactement vous avez été développeur ?
N’y voyez rien de malicieux, c’est une question sincère.

Je n’ai rien à cacher, mais vu l’ensemble des fonctions que l’ai assurées, il m’est difficile de répondre de façon précise. Disons que cela doit peut-être représenter un tiers de mon activité, soit une quinzaine d’années (développement proprement dit, programmation système, conception d’applications et encadrement des développements, audit d’applications, etc.) Mais il est clair, que depuis un peu plus de vingt ans, j’ai surtout pratiqué la modélisation des bases de données, travaillé et creusé la théorie relationnelle, sans oublier de faire le DBA, histoire de ne pas m’éloigner de la réalité du terrain et m’assurer que les développeurs n’avaient pas de problèmes avec les bases de données que je leur avais concoctées.

[Pierre Fauconnier]

C'est pas tellement la commande sans ligne de commande qui me gène moi ... Après tout pourquoi pas ... Mais c'est bien la ligne de commande sans commande ... Je pense que là on a un vrai problème ...

D'accord avec toi. Et on évitera cela grâce à deux contraintes: une FK et un NOT NULL... dans la base bien sûr, et non par code.

Cela dit, fsmrel reprend à nouveau l'exemple d'une facture qui doit comporter au moins une ligne, et je suis vivement intéressé par l'explication de cette obligation, que je ne comprends pas...

[CinePhil]

Cela dit, fsmrel reprend à nouveau l'exemple d'une facture qui doit comporter au moins une ligne, et je suis vivement intéressé par l'explication de cette obligation, que je ne comprends pas...

Je ne suis pas dans la tête de fsmrel (des fois j'aimerais bien, histoire de mieux maîtriser le modèle relationnel, et j'aime bien son humour ) mais moi ce qui m'étonne un peu c'est que tu ne comprennes pas cette obligation.

Le schéma le plus classique, c'est une commande avec des lignes de commandes et une facture avec des lignes de facture correspondant à la commande (au moins partiellement parce qu'il peut y avoir plusieurs factures pour une commande).

Même si la commande ne fait qu'une ligne et la facture de même, il y en a au moins une qui indique ce qui a été commandé et donc ce qui est facturé.

Fouille dans tes factures (téléphone, achat de mobilier, informatique...), je serais curieux de connaître l'exemple de facture sans ligne de facture.

Imaginons que je te facture quelque chose de la façon suivante :

Ma Société
Son Adresse
Son Téléphone
FACTURE
Client : Pierre Fouconnier
Ton adresse
N° de client : 123
N° de facture : 12345
Date d'émission : 09/01/2010
Montant HT : 10 000 €
TVA : 1 960 €
Montant TTC : 11 960 €

Tu l'accepterais cette facture ?