Bonjour, 

J'aurai aimé savoir quelle technique est la plus efficace pour éviter les erreurs de type duplicate primary key : 

- SQL : INSERT IGNOR

- SQL : DUPLICATE KEY UPDATE id = id

- VB : Simple Try Catch

Je vous remercie pour vos réponses

-
Edité par DeveloSt 5 août 2020 à 13:46:26

Bonjour,

Tout d'abord, bien structurer sa table pour que les contraintes d'intégrité soient pertinentes, utiles.

Avec MySQL, le INSERT IGNORE va complètement ignorer l'insertion si une erreur survient, ce n'est peut-être pas ce que tu souhaites ...

Le INSERT INTO ... ON DUPLICATE KEY UPDATE ... te permet de mettre à jour les données en cas de conflit sur une contrainte d'unicité.

C'est à toi de déterminer de quel comportement tu as besoin ...

Dans tous les cas, la gestion des erreurs doit être faites côté applicatif (en VB avec du Try/Catch par exemple), et plus elle sera fine, plus ton code sera facile à débugger et à maintenir.

Dans l'absolu tu dois pouvoir changer de SGBD sans casser ton code applicatif, et changer de code applicatif sans casser ta BDD

Bonjour, 

Je te remercie pour l'explication entre INSERT IGNORE et ON DUPLICATE KEY UPDATE. 

Pour l'instant ses erreurs je les gère uniquement en plaçant la requête dans un TRY CATCH  (sans utiliser de IGNORE)

Dans l'absolu tu dois pouvoir changer de SGBD sans casser ton code applicatif, et changer de code applicatif sans casser ta BDD 

OK, c'est à dire passer de MYSQL à SQLlite ou ajouter des fonctionnalités supplémentaires ?   

DeveloSt a écrit:

c'est à dire passer de MYSQL à SQLlite  

Oui, c'est bien ça, ou de MySQL à PostGreSQL, etc.

Ici, INSERT IGNORE et ON DUPLICATE KEY sont des syntaxes propres à MySQL, donc non portables ...

Benzouye a écrit:

tu dois pouvoir changer de SGBD sans casser ton code applicatif, et changer de code applicatif sans casser ta BDD

On est d'accord que c'est un peu du rêve, mais c'est un aspect à garder en tête lorsque tu développes pour éviter de trop lier son appli à un langage ou un logiciel ...

Benzouye a écrit:

Ici, INSERT IGNORE et ON DUPLICATE KEY sont des syntaxes propres à MySQL, donc non portables ...

Benzouye a écrit:

On est d'accord que c'est un peu du rêve, mais c'est un aspect à garder en tête lorsque tu développes pour éviter de trop lier son appli à un langage ou un logiciel ...

Après il ne faut pas que cela complexifie trop ton programme non plus ... surtout si tu n'envisages pas particulièrement la portabilité de ton appli ou l'évolution de ton SGBD.

Je pense que le plus important dans l'histoire c'est :

Ta base de données seule doit gérer l'intégrité des données. L'application ne doit jamais s'en occuper. Cela se fait par le jeu des contraintes d'intégrité (clés et index) et des triggers. De ce fait, elle doit toujours lever des erreurs lorsque l'utilisateur (une application ou un humain) essaye de faire des choses "non autorisées" (clé primaire déjà existante, index unique non respecté, clé étrangère inconnue, etc.).

Ton application doit quant à elle toujours gérer toutes les erreurs retournées par la base de données et répondre en fonction.

Quand tu dis la Base de données (cela signifie les requêtes SQL) et l'application le code (VB) ? 

C'est à dire les erreurs liées à la BDD (clés primaire déjà existante) doivent être géré par les requêtes (IGNORE) et les erreurs liées à l'application (DIV par 0, Chaine de caractère vide...) par le code (TRY CATCH, IsNULLOrEMPTY...)

DONC un TRY CATCH ne doit pas gérer une clés primaire déja existante. 

Quand je dis base de données j'entends base de données ... Dans ton cas MySQL et les tables, colonnes, contraintes que tu as créées. En soit la base de données est autonome, et peut travailler sans autre logiciel, tu peux exécuter des requêtes SQL directement dans la console sans passer par autre chose.

Quand je dis application, j'entends le logiciel que tu programmes (ici en VB) et qui va communiquer avec la base de données.

Donc je répète :

Benzouye a écrit:

Ta base de données seule doit gérer l'intégrité des données. L'application ne doit jamais s'en occuper. Cela se fait par le jeu des contraintes d'intégrité (clés et index) et des triggers. De ce fait, elle doit toujours lever des erreurs lorsque l'utilisateur (une application ou un humain) essaye de faire des choses "non autorisées" (clé primaire déjà existante, index unique non respecté, clé étrangère inconnue, etc.).

Ton application doit quant à elle toujours gérer toutes les erreurs retournées par la base de données et répondre en fonction.

Donc si ton application veut insérer dans la base, elle envoie la requête SQL, que la base de données exécute, et si problème d'intégrité elle retourne une erreur, erreur que ton application devra traitée correctement.

-
Edité par Benzouye 31 août 2020 à 12:04:51

Benzouye a écrit:

Quand je dis base de données j'entends base de données ... Dans ton cas MySQL et les tables, colonnes, contraintes que tu as créées. En soit la base de données est autonome, et peut travailler sans autre logiciel, tu peux exécuter des requêtes SQL directement dans la console sans passer par autre chose.

Par exemple : 

Quand un nouvel utilisateur se connecte (depuis l'interface) j'ai 3 requêtes qui s’exécute un UPDATE et 2 INSERT INTO en VB

Depuis la console en SQL je doit créer les 3 requêtes manuellement et vérifier si elle sont cohérentes.  

Si j'ai bien compris je doit faire un TRIGGER qui me permet d’exécuter automatiquement mes 2 INSERT INTO à l'UPDATE

EDIT : je connais pas trop les TRIGGER, mais j'ai lu rapidement que l'UPDATE devait appartenir à la même Table que les INSERT INTO ?

-
Edité par DeveloSt 31 août 2020 à 17:40:21

Peux-tu préciser ce que tu fais à l'arrivée d'une nouvel utilisateur ? Je ne comprends pas l'UPDATE et les INSERT ...

Je met un exemple du fonctionnement principal de l'application.

Après j'ai encore d'autres table comme Opérateur qui gère la connexion par exemple... 

Un nouvel utilisateur arrive alors j'update sont etat et le passe en connecté, il choisi une catégorie et sous catégorie d'exercice. 

Si c'est la première fois que cette sous catégorie d'exercice est choisi alors il y a 3 INSERT INTO qui est exécutés : 

- 2 dans la table horaire (calcul effectué toutes les minutes ou à chaque saisie de l'utilisateur)

- 1 dans la table événement

-
Edité par DeveloSt 1 septembre 2020 à 8:27:58

Le premier UPDATE est "seul", il peut le rester ...

Concernant les INSERT, pour moi ils s'inscrivent dans une logique applicative : tu testes si l'utilisateur a déjà cette catégorie, puis tu as une réaction différente selon le test.

Si la cohérence de ces données est nécessaire côté application, alors il faut regrouper ces actions dans une transaction : si une erreur survient pendant la transaction, toute celle-ci est annulé (ROLLBACK) remettant la base comme si rien n'avait été fait, si la transaction réussie, tu continues normalement en étant sûr d'avoir les 3 enregistrements requis en base.

Si dans les 3 INSERT INTO, 1 n'a pas réussit,

la cohérence est nécessaire (calcul des indicateurs) mais ne fait pas planter l'application (gestion de division par 0 ou pas de données... depuis l'application), il suffit à l'utilisateur de se déconnecter et reconnecter pour reexécuter les INSERT INTO et donc gérer les duplicate primary key. 

Peut-être avec un peu de recule et plus d’expérience en SQL je serais passé par des Transactions.

Je vais étudier la possibilité car cela me permettrai d'avoir un code moins lourd.