Discussion :

[_developpeur_]

bonjour a la demande de mes supérieurs je crée actuellement une base de données sans faire de relation entre les tables.

Je suis pas un pro en base de données, j'ai quelques bases en matière de modélisation mais c'est tout.

Je sais qu'en procédant ainsi on crée des redondances d'information, mais est-ce grave puisque le nombre d'enregistrement contenu dans cette base ne sera pas important?

Y a t-il d'autre conséquences plus grave que de créer une base sans relation, sans clé primaire... ?

J'ai lu ce topic :
http://www.developpez.net/forums/d74...ions-avantage/

Que veut dire SQLPro quand il parle d'anomalies transactionnelles ?

J'attends vos avis..
Merci beaucoup.

[f-leb]

bonjour,

toujours ce bon vieux débat relancé de temps à autre

a la demande de mes supérieurs je crée actuellement une base de données sans faire de relation entre les tables.

je ne sais pas dans quel secteur tu travailles mais cela ressemble au classique a-priori moyenâgeux: avec les relations c'est lent, c'est contraignant et gnagnagna...

beaucoup de choses ont été dites déjà, voir:
Réflexions sur la fenêtre des relations et l'utilité de l'intégrité référentielle [Débat]
Contraintes FOREIGN KEY SQL vs code client

que dire de plus...

[_developpeur_]

bonjour,

toujours ce bon vieux débat relancé de temps à autre


je ne sais pas dans quel secteur tu travailles mais cela ressemble au classique a-priori moyenâgeux: avec les relations c'est lent, c'est contraignant et gnagnagna...

beaucoup de choses ont été dites déjà, voir:
Réflexions sur la fenêtre des relations et l'utilité de l'intégrité référentielle [Débat]
Contraintes FOREIGN KEY SQL vs code client

que dire de plus...

Bonjour F-Leb, merci de répondre.
Bon, j'ai parcouru les liens que tu m'a donnée et je n'arrive toujours pas a me faire d'idée sur le "est-ce grave de ne pas faire de relations", quels sont les risques ?

quelques extrait pour lesquelles j'ai besoin d'un peu plus d'explication :

Quand on parle d'intégrité des données, je pense qu'on parle de l'intégrité référentielle.

>> Mais qu'est ce que ça veut dire concrètement ? Je ne trouve aucun commentaire clair.

Wikipédia :
En informatique, et plus particulièrement dans les bases de données relationnelles, l´intégrité référentielle est une situation dans laquelle pour chaque information d'une table A qui fait référence à une information d'une table B, l'information référencée existe dans la table B. L'intégrité référentielle est un vecteur de cohérence du contenu de la base de données.

Pour moi c'est pas clair cette explication , si tu peux m'éclairer, ça serait cool.

autre citation :

Je te prédits les pires ennuis avec tes bases. Les régles d'intégrité sont l'essence même des bases de données (et pas seulement d'Access). Ne pas en tenir compte entraînera des incohérences entre les données mais aussi obligera à des saisies multiples ou à recopier n fois les mêmes données dans différentes tables.

dans cet extrait, je comprends juste 'recopier n fois les memes données dans différentes tables' >> redondance >> est-ce grave pour une base pas volumineuse ??

"incohérence des données", concretement, qu'est ce que ca veut dire ? un exemple ?

Autre extrait :

Je ne conçois pas de base de données ACCESS sans intégrité référentielle, à tous les coups. C'est inévitablement courir droit dans le mur que de ne pas placer d'intégrité référentielle lors de la création des tables (sauf manipulations très spéciales, et en levant l'intégrité de manière temporaire).

Pourquoi courir droit dans le mur ??

Je sais j'en demande beaucoup, mais j'ai besoin de savoir les risques que j'encours que de créer une base sans relation...

Merci beaucoup.

[78chris]

Bonjour

Pour moi s'il n'y a pas de relations ce n'est plus une base de données mais une gestion de fichiers.

Le volume n'est pas point le plus important : à quoi va servir ta "base" et que va t-elle contenir ?

L'intégrité référentielle : exemple
j'ai une table de clients et une table de factures
je me plante dans le code client sur la facture et met un code inexistant, ou je supprime le client (ou je change son code) alors que j'ai des factures pour lui. C'est incohérent !
S'il y a des relations avec intégrité référentielle, le moteur de la BD m'interdit de faire ça et donc préserve la cohérence.

Mais les relations c'est ce qui fait la puissance de fonctionnement.
Sans relation non seulement tu es redondant mais tu as le risque que l'info ne soit plus identique si tu modifies d'un côté et oublies de l'autre.

Plus de saisie contrôlée par des listes déroulantes basées sur des tables...
Si tu veux contrôler quoi que soit, il faut tout coder. Bonjour le boulot.

Par curiosité, tes supérieurs sont informaticiens ?

[f-leb]

bonsoirn

Plus compliqué dans d’autres domaines :

Comment s’assurer qu’une commande d’un article chez un fournisseur concerne bien un article proposé dans le catalogue de ce fournisseur ?

Comment être sûr que ma base de données n’autorise pas la fabrication de pièces métalliques par un procédé d’injection des thermoplastiques ?

Comment n’autoriser la saisie du score d’un golfeur sur un trou qu’à partir du moment où ce trou fait partie d’un parcours auquel le golfeur a vraiment participé au cours d’une partie ?

C’est ça assurer la cohérence des données et la mise en place de l’I.R peut y contribuer à moindre frais.

S’en priver revient à faire entièrement confiance en la qualité de ta programmation

Récemment j’ai mis en place un système d’affectation d’élèves (près de 300) à des cours optionnels en satisfaisant au mieux leurs vœux. Ne souhaitant pas avoir de parents d’élève sur le dos suite à une malheureuse affectation à un cours qui n’est plus assuré ou mieux encore à un cours que l’élève n’a jamais demandé, j’ai préféré ne pas faire confiance en ma programmation et à m’en remettre aveuglément à l’I.R.

Je n’étais pas obligé de faire ce projet et je ne l’aurais donc jamais réalisé si l’I.R n’existait pas, bien assez de problèmes comme ça…

Ce qui serait intéressant de savoir c’est pourquoi tes supérieurs préfèrent des tables sans relation.