[MYSQL] Clefs étrangères qui marchent pas ??

Recherche :

Dernière réponse
Sujet : [MYSQL] Clefs étrangères qui marchent pas ??
Mara's dad	Tout à fait D'accord !

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Mara's dad

Tout à fait D'accord !

gizmo

L'intégrité référentielle, ca sert beaucoup dans les gros projets ou beaucoup de monde travaille, car c'est une garantie supplémentaire face aux mélanges de bouts de code qui réunis au final. C'est très pratique pour palier aux bugs qui n'ont pas été trouvé. Et dans ces gros travaux, la rapidité, tu l'obtient en mettant des machines conséquentes.

Le but de mysql est de tourner sur des petits serveurs pour des petites applic. Donc ca ne leur est d'aucun intérêt.

Mara's dad

A quoi elle te sert l'IR ?

A part :
Vérifier que ton code est pas RIPOUX ?
Faire ramer ton SGBD ?
T'emerder quand tu fait une restauration, ou une copie de table...

Parce-que sinon, quand la base te renvoie une erreur d'IR, t'es bien obligé de la traiter dans ton code, non ?

Moi, je dis, autant faire les choses bien du premier coup !

Bruce

shinji a écrit a écrit :

Je suis pas sûr qu'ils l'utilisent pas comme tu dit!
J'ai des profs qui sont intervenant extérieurs (qui bossent dans des boîtes du coin) et je te garanti qu'ils l'utilisent!

Vi, vi je sais bien ! Comme je te dit, je ne suis pas contre l'intégrité référentielle, mais dire que MySQL c nul à cause de ça c'est franchement mal le juger ! Trouve moi un SGBD avec autant de possibilitées et aussi performant à ce prix là... :hello:
L'IR bien utilisée est très bien et très pratique mais c'est souvent un gros bordel pour les gens qui ne s'y connaissent pas trop en BDD...

shinji

Je suis pas sûr qu'ils l'utilisent pas comme tu dit!
J'ai des profs qui sont intervenant extérieurs (qui bossent dans des boîtes du coin) et je te garanti qu'ils l'utilisent!

Bruce

shinji a écrit a écrit :

Parce que tu crois que Oracle, ils ont laissé de côté comme ça l'intégrité référentiel du genre :

"Oh de toute façon, ça sert pas à grand chose, c'est chiant"

ça éviterai un bon paquet de programmation! Puisque de toute façon, il faudra le faire par un moyen ou un autre!

Oracle c pas le même but, jusqu'à preuve du contraire c une boite et ils vendent le soft... Un SGBD commercial sans intégrité référentielle (même si on l'utilise pas), ça fait tâche...

shinji

Parce que tu crois que Oracle, ils ont laissé de côté comme ça l'intégrité référentiel du genre :

"Oh de toute façon, ça sert pas à grand chose, c'est chiant"

ça éviterai un bon paquet de programmation! Puisque de toute façon, il faudra le faire par un moyen ou un autre!

Mara's dad

Ben moi, j'aime bien MySql parceque :

C'est rapide, fiable, et que çà fait CE QUE JE LUI DEMANDE, RIEN QUE CE QUE JE LUI DEMANDE !

J'aime pas les boîtes noires qui font des trucs pas clair, genre :
Triggers
CASCADE ON DELETE
...

Pas clair dans le sens ou, en lisant le code, il est pas évident d'être sûr de ce qui se passe VRAIEMENT !

J'aime pas les applis qui proposent de supprimer un trucs pour te demander ensuite confirmation et finalement te dire, "A ben on est désolé, mais la SACRO-SAINTE intégrité référentielle, elle dit que c'est pas possible !"

Mais bon, je sais y'a plein de gens très bien qui pensent exactement le contraire !

Moi, j'aime que la logique de fonctionnement soit INTEGRALEMENT visible dans le code.

Bruce

Ok, je crois que c toi qui as pas bien pigé le fonctionnement des BDD. Toutes les raisons qu'il explique sont vraies. Une bonne intégrité référentielle c sympa sur le papier, mais en pratique, c'est l'enfert plus qu'autre chose ! Surtout à gérer pour un SGBD... Bref ils ont préféré aller à l'essentiel (faire un SGBD efficace, léger, gratuit et portable) que faire une intégrité référentielle de merde qu'une personne sur 1000 as envie d'utiliser...

shinji

Et en plus le CASCADE ON DELETE marche pas même avec InnoDb

:-(

shinji

Bruce a écrit a écrit :

Mouais... Mais ce format de table change quoi ? C pas chiant à gérer ça ?

Sinon, dans la doc tj :
1.4.4.6 Reasons NOT to Use Foreign Keys constraints

There are so many problems with foreign key constraints that we don't know where to start:

Foreign key constraints make life very complicated, because the foreign key definitions must be stored in a database and implementing them would destroy the whole ``nice approach'' of using files that can be moved, copied, and removed.
The speed impact is terrible for INSERT and UPDATE statements, and in this case almost all FOREIGN KEY constraint checks are useless because you usually insert records in the right tables in the right order, anyway.
There is also a need to hold locks on many more tables when updating one table, because the side effects can cascade through the entire database. It's MUCH faster to delete records from one table first and subsequently delete them from the other tables.
You can no longer restore a table by doing a full delete from the table and then restoring all records (from a new source or from a backup).
If you use foreign key constraints you can't dump and restore tables unless you do so in a very specific order.
It's very easy to do ``allowed'' circular definitions that make the tables impossible to re-create each table with a single create statement, even if the definition works and is usable.
It's very easy to overlook FOREIGN KEY ... ON DELETE rules when one codes an application. It's not unusual that one loses a lot of important information just because a wrong or misused ON DELETE rule.
The only nice aspect of FOREIGN KEY is that it gives ODBC and some other client programs the ability to see how a table is connected and to use this to show connection diagrams and to help in building applications.

MySQL will soon store FOREIGN KEY definitions so that a client can ask for and receive an answer about how the original connection was made. The current `.frm' file format does not have any place for it. At a later stage we will implement the foreign key constraints for application that can't easily be coded to avoid them.

Putain j'y crois pas!
C'est nul MySql ( à quoi sa sert une BDD sans intégrité référentielle???). Il y rien compris le mec qu'a écrit ça!! Il a jamais suivit une cours de BDD de sa vie!

Il faut mettre Type=InnoDD (ça veut dire quoi?).
A quoi ça sert de même FOREIGN KEY si c'est pas pour avoir l'intégrité référentielle! C'est idio le Type=InnoDD!

Je suis déçu de MySql!

Bruce

Mara's dad a écrit a écrit :

"Both tables have to be InnoDB type "

http://www.mysql.com/doc/S/E/SEC442.html

Mouais... Mais ce format de table change quoi ? C pas chiant à gérer ça ?

Sinon, dans la doc tj :
1.4.4.6 Reasons NOT to Use Foreign Keys constraints

There are so many problems with foreign key constraints that we don't know where to start:

Foreign key constraints make life very complicated, because the foreign key definitions must be stored in a database and implementing them would destroy the whole ``nice approach'' of using files that can be moved, copied, and removed.
The speed impact is terrible for INSERT and UPDATE statements, and in this case almost all FOREIGN KEY constraint checks are useless because you usually insert records in the right tables in the right order, anyway.
There is also a need to hold locks on many more tables when updating one table, because the side effects can cascade through the entire database. It's MUCH faster to delete records from one table first and subsequently delete them from the other tables.
You can no longer restore a table by doing a full delete from the table and then restoring all records (from a new source or from a backup).
If you use foreign key constraints you can't dump and restore tables unless you do so in a very specific order.
It's very easy to do ``allowed'' circular definitions that make the tables impossible to re-create each table with a single create statement, even if the definition works and is usable.
It's very easy to overlook FOREIGN KEY ... ON DELETE rules when one codes an application. It's not unusual that one loses a lot of important information just because a wrong or misused ON DELETE rule.
The only nice aspect of FOREIGN KEY is that it gives ODBC and some other client programs the ability to see how a table is connected and to use this to show connection diagrams and to help in building applications.

MySQL will soon store FOREIGN KEY definitions so that a client can ask for and receive an answer about how the original connection was made. The current `.frm' file format does not have any place for it. At a later stage we will implement the foreign key constraints for application that can't easily be coded to avoid them.

Bruce

Dans la doc de MySQL :
1.4.4 Functionality Missing from MySQL
1.4.4.1 Sub-selects
1.4.4.2 SELECT INTO TABLE
1.4.4.3 Transactions
1.4.4.4 Stored Procedures and Triggers
1.4.4.5 Foreign Keys
1.4.4.6 Reasons NOT to Use Foreign Keys constraints
1.4.4.7 Views
1.4.4.8 `--' as the Start of a Comment

Mara's dad

"Both tables have to be InnoDB type "

http://www.mysql.com/doc/S/E/SEC442.html

Bruce

MySQL as tout pour gérer ce genre de trucs mais ne le fait pas... En fait c à toi de gérér l'intégrité référentielle de tes données...

shinji

Voilà, j'ai créé deux tables toutes cons liéés par une clé étrangère:

create table table1(

id1 number(2) PRIMARY KEY,
nom1 varchar(5)
);

create table table2(

id2 number(2) PRIMARY KEY,
nom2 varchar(5),
id1 number(2),
FOREIGN KEY(id1) REFERENCES table1(id1)
);

Normalement, si j'ai dans table1:
"1 toto"
et que j'essaye la requète suivante:
"insert into table2 values('1','toto','2');"
Il devrait me faire un erreur comme quoi il n'y a pas de valeur id1=2 dans table1.
Or, il fait qd même l'insertion dans la table2.
Pourquoi ne tient-il pas compte de ma clef étrangère??