table composé de clefs étrangères

07 juin 2009, 12:49

Bonjour, je dois mettre en place une base de donnée relationnel, et j'aimerais savoir si je n'ai pas fais d'erreur de logique, voici le mcd :
en---(1,n)---(lien)----(1,n)----fr

Et voici le code sql :

Code : Tout sélectionner

CREATE TABLE `en` (
  `id_en` int(11) NOT NULL AUTO_INCREMENT,
  `nom` varchar(255) NOT NULL,
  `description` varchar(255) NOT NULL,
  PRIMARY KEY (`id_en`)
) TYPE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `fr` (
  `id_fr` int(11) NOT NULL AUTO_INCREMENT,
  `nom` varchar(255) NOT NULL,
  `description` varchar(255) NOT NULL,
  PRIMARY KEY (`id_fr`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `lien` (
  `id_fr` int(11) NOT NULL,
  `id_en` int(11) NOT NULL,
  PRIMARY KEY (`id_fr`,`id_en`),
  CONSTRAINT `FK_id_en` FOREIGN KEY (`id_en`) REFERENCES `en` (`id_en`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `FK_id_fr` FOREIGN KEY (`id_fr`) REFERENCES `fr` (`id_fr`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

J'aimerais éviter de commencer à travailler avec une base qui serait fausse. Ma principale interrogation concerne la table lien qui contient uniquement les clefs étrangères. J'avais pour habitude de travailler avec le moteur de stockage MylSAM, et je créais mes liens avec php, je souhaite donc envisager d'autre possibilités, car ce que je faisais n'étais pas focément une solution viable à long terme. Dans l'attente d'une réponse de votre part, je vous souhaite à tous une bonne journée malgré ce mauvais temps

07 juin 2009, 16:29

Bonjour

Pourquoi pas ceci :

Code : Tout sélectionner

CREATE TABLE `trucmuche` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `nom` varchar(255) NOT NULL,
  `description` varchar(255) NOT NULL,
  `codelang` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) TYPE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `langues` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `nom` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) TYPE=InnoDB DEFAULT CHARSET=latin1;

07 juin 2009, 16:50

Bonjour, merci d'avoir tenter de me répondre.
Je ne comprends ce que tu propose, quel est l'intérêt d'utiliser innoDB dans ces cas là? Si je souhaite utiliser innoDB, c'est parce que ce moteur permet de gérer les clef étrangères, et comme tu les as enlevés, et vue qu'il n'y a pas de contrôle d'intégrité, je ne vois pas pourquoi faire comme cela.

08 juin 2009, 07:12

innodb ou pas je n'ai pas compris pourquoi la table lien serait indispensable. Je ne fait pas mes conceptuels en fonction du moteur de la base ( ça m'arrive de choisir mes moteur en fonction du conceptuel par contre )

08 juin 2009, 09:33

rebonjour

,
j'ai besoin de créer une table par entité, car en réalité le mcd est un peu plus compliqué que cela et implique d'autre langues. Et j'ai appris qu'il fallait (peut être a tort) créer une table pour la relation, en y mettant les clefs primaires des tables concernés par la relation.

08 juin 2009, 11:13

Bonjour,

Parlons d'abord conceptuel et explique bien les liens de tes données globalement. Après on peut voir SQL et les relations.

08 juin 2009, 15:08

car en réalité le mcd est un peu plus compliqué que cela

On est prêt a en discuter mais effectivement faut nous en dire un peu plus

08 juin 2009, 16:16

Je vais réaliser le mcd sur l'ordinateur, pour le moment je l'avais fais uniquement sur papier. Je fais ça au plus vite...

08 juin 2009, 21:29

bonsoir, désolé pour le retard, donc j'ai commencer par faire le mcd, et j'ai finalement décidé de mettre que la partie qui nous intéresse. Je n'ai mis que trois entités afin d'éviter qu'il est trop de table liens, cependant le nombre d'entité est d'en réalité 5(japon, et espagnol en plus).

Peut être que de nombreuses personnes vont critiquer la manière dont j'ai conçu le mcd, je suis donc ouvert à toutes suggestions afin d'améliorer cette partie. Il y a environs 8500 données par tables.
Je vous souhaite à tous une bonne soirée, et bon courage pour ceux qui travaille encore.

09 juin 2009, 00:47

j'ai besoin de créer une table par entité, car en réalité le mcd est un peu plus compliqué que cela et implique d'autre langues

Le problème avec ton conceptuel c'est justement que ça t'oblige a créer une table de data ET autant de tables de relation qu'il y a de langues déjà existante

3 langues => 3 relations
4 langues => 6 relations
5 langues => 10 relations
6 langues => 15 relations etc ...

Peut être as tu d'autre contraintes qui t'obligent a avoir une table par entité ?

et vue qu'il n'y a pas de contrôle d'intégrité,

Les contrôles d'intégrité je ne les ai pas mis, j'y réfléchit toujours après, peut être a tord. Dans mon cas, tout est gérable en deux tables, ensuite, la seule contrainte d'intégrité concerne le codelang, qui est un lien sur la table langues ( en même temps, moins de relations, moins de contraintes, forcément )

Code : Tout sélectionner

CONSTRAINT `FK_codelang` FOREIGN KEY (`codelang`) REFERENCES `langues` (`id`) ON DELETE CASCADE ON UPDATE CASCADE

Personnellement pour faire du multilangue j'avais une table texte qui contenait les textes dans toutes les langues, avec un codelang dans l'enregistrement, ainsi n'importe quelle table contenant un texte traductible pouvait y faire référence. Et du coup j'avais une seule classe PHP qui gérait la table dans n'importe quelle partie de mon programme. Ajouter une langue n'etait pas un soucis, dans la mesure évidement ou je me tape pas la traduction

Après y a peut être un truc que j'ai pas saisit dans ta problématique

10 juin 2009, 10:43

Hello

déjà un petit remerciement pour te pencher sur mon problème.
En ce qui concerne le regroupement de plusieurs tables dans une seule, cette solution n'est pas envisageable, car on m'a bien fais comprendre que la base doit comporter une table pour représenter un pays en particulier. En plus je pense que ce serait un peu lourd de mettre 8000 * (nombre de pays ) dans une seule table, le sens de l'existence d'une base de donnée est à remettre en cause, (cela ne serait il pas équivalent à l'utilisation d'un fichier externe en tant que base de données comme on faisait auparavant??)Il y a point où je te rejoins, c'est que le nombre de table pour établir les relations entre les pays est exponentiel au nombre de pays. Mais ceci n'est pas tant un problème en soit, du moins je le pense. Et pour répondre à ta question, c'est le client qui va remplir lui même la base de donnée se tapant la traduction lui même.

Il y a une question qui m'est venu, le fait de le mettre tout les pays dans une seule table, comment est ce possible sachant que la relation est de type (1,n), en effet la correspondance entre la langue chinoise peut avoir 4 à 5 mots français, et vice versa du français avec l'anglais.
Quoi qu'il en soit ma problématique n'est pas là. En règle générale, j'utilisais tous le temps moteur MylSAM, en réalisant dans ce cas précis, une table contenant deux clefs primaires correspondant les id des relations. On m'as parlé du moteur innodb, qui notamment permettais de gérer les clefs étrangères, et ma question était de savoir si le code que j'ai mis lors de mon premiers post était pas faux d'un point de vue logique avec le mcd. Bonne journée à tous.

10 juin 2009, 14:33

Effectivement, le code SQL que t'as mis dans ton premier post n'est pas faux, il répond exactement à ce que tu veux faire en innodb. Bonne journée.

10 juin 2009, 22:02

Merci.

table composé de clefs étrangères

Qui est en ligne