Discussion :

[esc39]

Bonjour à tous,

Je vous explique le problème actuel :
J'ai une table de forçage et une table de calcul. Lorsque l'utilisateur ne souhaite aucun forçage de variables, la table de calcul se charge d'actualiser la BD. Si un forçage est demandé sur une variable spécifique alors la table de forçage prend la main sur l'actualisation de la variable dans la BD et la table de calcul n'a plus d'action sur cette variable mais sur toutes les autres oui jusqu'à ce que la table de forçage prenne la main dessus.
Je souhaitais mettre en place une gestion telle que celle-ci à l'aide de mutex étant donné que chaque variable devienne une section critique. Cependant, si j'ai 1 000 variables j'aurai donc 1 000 mutex ce qui, selon moi, n'est pas viable. Je pense donc que mon raisonnement est erroné.
Je m'en remets à vous afin de m'éclaircir sur les solutions qui s'offrent à moi, vos recommandations ou alors votre approbation de cette gestion par mutex.

En vous remerciant par avance,

Cordialement,
esc39

PS : J'utilise l'API MySQL C et je suis sur Windows.

[SQLpro]

Un SGBD gère a concurrence au mieux en analysant les requêtes les index des tables et la concurrence à un instant t (pour les meilleurs dont évidemment MySQL ne fait pas partit).
Essayer de gérer la concurrence à la maion est juste une ineptie qui ne vous conduire qu'à des contre performances lamentables.

La seule chose à faire est donc de se reposer sur les transactions...

A +

[Artemus24]

Salut esc39.

Je souhaitais mettre en place une gestion telle que celle-ci à l'aide de mutex étant donné que chaque variable devienne une section critique.

Vous êtes en train de réinventer ce qui existe déjà naturellement dans les SGBDR.
Cela se nomme les accès concurrents (comme le souligne SQLPRO) et MySql sait très bien gérer cela.

Quand plusieurs accès se font à une même ligne, il y a sérialisation des demandes.
C'est à vous de paramétrer en conséquence votre MySql pour obtenir le bon comportement.
Entre autre, mettre "transaction-isolation = SERIALIZABLE".

Je pense donc que mon raisonnement est erroné.

Il n'est pas erroné. Vous avez une méconnaissance du fonctionnement des SGBDR.

@+

[esc39]

Merci beaucoup à vous deux de m'avoir éclairé
Concernant les transactions (je ne savais pas que ca existait), est-ce vraiment bon de soliciter la BD en "continu" avec des transactions ? Ne vaut-il pas mieux gérer une comm de telle manière à alléger les requêtes vers la BD ?
Autre question, existe t'il des triggers sur un type de donnée de tel manière à envoyer un signal de la BD vers l'application pour lui dire comme quoi une valeur a été changé ? (une gestion d'interruption de la BD).
Vaut-il mieux envoyer 5 requêtes d'écritures ou 1 requête avec toutes les données ? (= la BD gère t'elle les requêtes en parallèle ?)
Merci d'avance,

Cordialement,
esc39

[Artemus24]

Salut esc39.

est-ce vraiment bon de soliciter la BD en "continu" avec des transactions ?

Je trouve votre question étrange.
Le mode transactionnel est une fonctionnalité des SGBDR.
En quoi cela ne serait pas correcte de l'utiliser ?

En ce qui concerne le "continue" comme vous dites, c'est plutôt à l'application de se poser ce genre de question.
Si vous prenez comme exemple le relevé des températures, votre BD sera sollicté tout le temps.

Ne vaut-il pas mieux gérer une comm de telle manière à alléger les requêtes vers la BD ?

Partez de l'hypothèse que nous ne savons pas de quoi vous parlez.
Qu'est-ce que vous entendez par "comm" ? Un exemple serait le bienvenue.

Autre question, existe t'il des triggers sur un type de donnée de tel manière à envoyer un signal de la BD vers l'application pour lui dire comme quoi une valeur a été changé ?

Un trigger, c'est un déclencheur qui va faire un certain traitement lorsqu'une intervention va se faire sur une table.
Par exemple, vous désirez garder une trace (une historisation) de toutes les modifications de votre table.
Chaque fois que la table est "mise à jour" (update), vous créez dans une autre table, une ligne contenant l'ancienne valeur contenant en plus la date et l'heure d'intervention, avec l'identifiant de celui qui a fait la modification.

Non, le déclencheur n'envoie rien à l'application. C'est à vous de gérer vos insertions, modifications, suppressions et interrogations dans votre BD.

Vaut-il mieux envoyer 5 requêtes d'écritures ou 1 requête avec toutes les données ? (= la BD gère t'elle les requêtes en parallèle ?)

Comment voulez-vous répondre à cette question, vu que l'on ne sait rien de ce que vous faites.

Qu'est-ce que vous entendez par "parallèle" ?
Plusieurs utilisateurs qui accèdent en même temps à la même ligne de votre table ? La réponse est oui.
Et dans le message précédent, c'est le rôle du transactionnel de sérialiser les demandes d'accès.

Si c'est autre chose, définissez le.

@+

[SQLpro]

Merci beaucoup à vous deux de m'avoir éclairé
Concernant les transactions (je ne savais pas que ca existait), est-ce vraiment bon de soliciter la BD en "continu" avec des transactions ?

Vous n'avez pas le choix. Un SGBDR gère des transaction pour toute commande SQL. Si vous ne voulez pas de transaction, alors abandonnez le concepts de SGBDR et faites vos développement avec un fichier !

Autre question, existe t'il des triggers sur un type de donnée de tel manière à envoyer un signal de la BD vers l'application pour lui dire comme quoi une valeur a été changé ? (une gestion d'interruption de la BD).

Cela existe dans certains SGBDR comme SQL Server et s’appelle "notification services". je ne sait pas pour MySQL.

Vaut-il mieux envoyer 5 requêtes d'écritures ou 1 requête avec toutes les données ? (= la BD gère t'elle les requêtes en parallèle ?)

Un SGBDR travaille de manière ensembliste (plusieurs lignes); le faire travailler ligne à ligne est le meilleur moyen de :
pourrir les performance du fait d'un usage contre nature
arriver à des situation de blocage, voir d'interblocage (verrous mortels).

Merci d'avance,

Cordialement,
esc39

Commencez par vous former aux concepts de SGBD relationnel, parce que là vous partez de très très loin !!!!

Mon site comme mes livres peuvent vous y aider.

A +