Innodb : utile pour moi ?

Bonjour à tous,

J'ai deux serveurs avec du mysql.

Soit serv1 et serv2.

serv1 a une table à id unique "papa" contenant 15 colonnes.
serv2 envoie une table "fiston" qui a les mêmes id uniques que "papa", mais très simplifiée à 3 colonnes.

Sachant que je dois faire un update de fiston vers papa sur les champs (indexés) correspondants et sans autre forme de contrôle, dois-je passer mon moteur en innodb ou le laisser myisam pour plus de performances ?

Le moindre centième compte.

Merci à vous,

A bientôt,

LeHibou2

salut,

innodb est utile pour 2 choses:

• la vérification des contraintes d'intégrité référentielle
• la possibilité de d'annuler les actions
• choisir un niveau d'isolation des transactions
• faire des transactions de plusieurs opérations
• avoir un blocage au niveau ligne plutôt que de la table

mais ça se paye par moins de rapidité que myisam qui ne fait pas ça...

donc à toi devoir ton besoin réel...:ccool:

Salut Eric !

Merci pour ta réponse.
En effet, je n'ai pas besoin de tout ça.

Je vais garder myisam dans ce cas.
Il y a une chose qui me fait un peu peur : c'est le blocage intégral de la table.
Mais à la réflexion, vu qu'il n'y a qu'un champ à réécrire, cela ne pose pas de problème d'accès concurrentiel.

Par contre, on peut continuer à lire les champs de colonne sans problème pendant l'update ?
Ca c'est suuuuuper important par contre ;) Sinon, c'est l'arrêt du site à chaque update :cry:

Eric ou quelqu'un peut me rassurer ?

Merci beaucoup,

A bientôt,

LeHibou

le lock est sur toute la table en myisam
après ça l'opération est plus rapide en myisam donc faut essayer :ccool:

y a pas de réponse absolue vu que ça dépend de la plateforme aussi niveau performance

Ma crainte à moi c'est que c'est une appli métier (pour mon père, donc une toute petite appli qui n'est pas critique en soi mais qui aide bien son organisation) et la valeur ne peut pas être laissée à vierge lors d'un update de page.

Admettons qu'il y ait 3 pages intranet pour 100 personnes qui se connectent, il va forcément y en avoir une qui va avoir une page sans information parce que ça update, non ??
Et on ne peut pas leur demander de n'utiliser le service qu'à certaines heures.


Il faut toujours avoir accès au moins à l'ancienne info pendant l'update.
C'est jouable ça ?

Merci beaucoup,

LeHibou

Bonjour.

Quel est ta requête pour faire un UPDATE (surtout pour voir sur combien de tuples elle opère) ? La volumétrie de tes tables ?

Si c'est une petite base, ça ne devrait pas poser problème ... (pour une petite application avec deux tables, je pense que c'est le cas ;) ).

Tu peut aussi faire des tests de perf sur tes requêtes et évaluer le temps que ça prend ;)

Cordialement,
Idriss

au passage tu as le moteur federate pour gérer une table distante avec quelques limitations mais en évitant de passer par un langage serveur genre php

Merci à vous deux,

En fait, il y a peu de tables, mais énormément de données... :cry:

C'est pour une gestion de stat mais mon père les veut précises. La volumétrie est de l'ordre de 100 millions de données.

Je sais ça peut paraître beaucoup pour une "petite application annexe" mais en fait, je n'ai vraiment pas d'autres solutions. Ces données lui permettent un pré-traitement de ses matières premières.

Perso, pour quelqu'un qui est au smic, je trouve que c'est beaucoup de manip', mais c'est un autre débat (famille, tout ça..).

Ma requête est de type :

Code:

---

1 2 3 4 5

UPDATE papa INNER JOIN fiston ON papa.id=fiston.id SET papa.res=fiston.calc

---

Mais encore une fois, il faut au moins que l'ancienne valeur s'affiche lors de l'update si un accès à cette donnée est demandée.. Il n'y a pas d'autres contraintes :)

Merci à vous !

LeHibou2