Version imprimable
salam!
pour utiliser auto_increment il nous faut une table de type MyISAM et pour la clef etrangere le type InnoDB! on peut pas les utiliser au meme temps(dans la meme table)?! je comprends pas bien à quoi sert chaque type de table!
Merci pour votre aide! ;)
salut;
Le auto_incrément marche sur les deux type de moteur de bases de données
pour Foreign Key je sais pas;
Mais je que je sais sur le moteur MYISAM c'est qu'il n'est pas transactionnel
il est trés utile pour le stockage des données;
InnoDB en ravanche est transactionnel
Une table ne peut etre que d'un seul type InnoDB, MYISAM ou BerkeleyDB (BDB); car les moteur de base de données sont different
Pour les clé etrangères tu peux t'en passer si t'a un probleme en rajoutant l'identifiant de la table parente
AUTO_INCREMENT fonctionne sur les deux types de tables MyIsam et InnoDB.
Par contre la gestion des clés étrangères ne fonctionne qu'avec des tables InnoDB.
Rien n'interdit de faire une architecture basée sur des clés étrangères avec des tables MyIsam mais les contraintes associées ne seront pas gérées par le moteur MyIsam donc c'est le programme qui utilise et alimente la base de données qui devra se taper le boulot de vérification du respect des contraintes.
Comme c'est automatique avec des tables InnoDB, pourquoi s'en priver ?
@buggen25 :
Ajouter l'identifiant de la table parente dans une table, c'est faire une clé étrangère !Citation:
Pour les clé etrangères tu peux t'en passer si t'a un probleme en rajoutant l'identifiant de la table parente
Mais comme dit juste au-dessus, MyIsam ne vérifiera pas les contraintes associées aux clés étrangères puisqu'il ne les connait pas. Autrement dit, en MyIsam, rien n'interdira la saisie, dans la colonne de clé étrangère, d'un identifiant n'existant pas dans la table parente.
Bonjour,
A noter aussi qu'un SGBD est apprécié pour son contrôle de l'intégrité, il est donc très déconseillé de volontairement s'en passer.
Ce type de contrôle apporte une simplicité de gestion d'erreur incroyable.
Cet article traite de comment limiter la complexité applicative grâce au contrôle d'intégrité référentielle
merci pour votre aide!
j'avais avant un probleme avc auto_increment et la solution c t la precision: ENGINE = MyISAM
http://www.developpez.net/forums/d59...sil-ya-2-cles/
j'ai trouvé qu'il fallait utilisé FOREIGN KEY et ça demande le type innoDB;
mais la creaation de cette table meme sans le (foreign key) est impossible avc innoDB
Avec un type innoDB on peut utiliser le contrôle d'intégrité référentiel ET l'auto increment.
Donne-nous la requête de création de table et le message d'erreur que te renvoie MySQL.
Salut tout le monde;
En utilisant auto_increment on facilite la création d'autres enregitrement, par contre lors du passage aux transactions (Ce qui est un mechanisme de controle d'integrité de grande importance dans un appli reseaux)On ne peut plus utiliser l'auto_increment car si on fait un rollback l'autoincrément s'incrémente et en se retrouve avec des trous dans les enregistrements
Quel est le problème ?Citation:
Envoyé par buggen25
Un identifiant identifie un seul et unique tuple au cours de TOUTE sa vie, aussi, si le tuple viens a être supprimé, l'identifiant pointe vers rien et n'as plus de raison d'être. Les "trous" dans l'identification n'as aucune espèce d'importance.
Il se passe le même phénomène quand on fait un insert initialisant une valeur auto-incrémenté, puis que l'on DELETE le nouveau tuple, l'insertion suivante aura une identifiant supérieur.
salut;Citation:
Un identifiant identifie un seul et unique tuple au cours de TOUTE sa vie, aussi, si le tuple viens a être supprimé, l'identifiant pointe vers rien et n'as plus de raison d'être. Les "trous" dans l'identification n'as aucune espèce d'importance.
si je voulais créer un identifiant unique et sequentiel 1, 2, 3 jusqu'a N, et que je ne veut pas avoir de trous, l'identifiant de ce cas précis ne doit pas s'incrémenter si je fais un rollback ?
Pourquoi ?Citation:
Envoyé par buggen25
salut;
exemple :
je voudrais créer les commandes avec des numero sequentiels et la date,
du format 2008/1 pour la première commande, la deuxieme commande va logiquement prendre l'identifiant 2008/2(l'identifiant est auto_increment), Je voudrais mettre la création de cette commande dans un transaction pour le besoin d'un applicatif reseaux, malheuresemnt ma transaction n'est pas arrivée au COMMIT,mais quand je vais réessayer d'inserer la nouvelle commande avec 2008/2, je me retrouve avec une commande portant l'identifiant 2008/3 et non 2008/2
En quoi est-ce gênant de ne pas avoir de commande 2 ?
La solution existe mais je tiens vraiment à maintenir que ce n'est pas une bonne pratique. On peut changer la valeur de l'auto_increment comme ceci :
Code:ALTER TABLE laTable AUTO_INCREMENT = 2;
salut;
c'est pas très génant d'avoir des trous :oops:, en plus il est trés rare qu'une transaction échoue, mais si j'ai pas crée une commande qui porte le numero deux pouquoi sauter au numero 3. ça peut se comprendre dans le cas d'une suppression mais lors de l'insertion c'est limite. mais le probleme reste le meme
l'auto_increment saute
Je t'ai donné un moyen de redéfinir la valeur courant de l'auto_increment.
Comme tu dit ce n'est pas gênant d'avoir des trous, alors pourquoi se compliquer la vie :aie:
salut
Il me semble que ALTER TABLE est une requete DDL, niveau transactionnel c'est limite.Code:ALTER TABLE laTable AUTO_INCREMENT = 2;
je pense qu'il faudrait recuperer le max du dernier element
ensuite je vais inserer le nouvel element avec cet identifiant + 1 .. :aie:Code:SELECT MAX(id) FROM laTable
Merci quand meme pour ces informations
non !Citation:
Envoyé par buggen25
Que se passerait-il si jamsais on archive une partie des tuples en base de données ?
On réattriburait des identifiants déjà utilisés provoquant ainsi des violations d'intégrité a une restitution des archives.
je pense qu'une lecture d'un cours de SQLpro serait bénéfique :)
C'est vrai pour l'archivage si on fait un sauvegarde partielleCode:Que se passerait-il si jamsais on archive une partie des tuples en base de données ?
J'ai lut le document mais pour l'acces concurentiel j'en doute, car on ne peut pas créer un tuple qui existe déja ,
Merci pour le lien