Bonjour, quelques petites questions de fond . Je suis assez ignorant sur les verouillages de table.
 
1) Une application peut-elle se passer d'utiliser des verrous dans la plupart des cas, ou est-ce à votre avis indispensable ? Quels sont les risques si on n'utilise pas de verrous sur les tables dans son application ? Quels sont les avantages ?
 
2) Si on décide d'utiliser des verrous sur des tables MyISAM, on doit lock une table dès qu'on veut la modifier ? Aussi quand on veut la lire ?
 
3) Si on utilise des tables InnoDB, quasiment tout est geré automatiquement non ? On gère la transaction, pas les lock non ?

InnoDB gère les transactions, oui.

euh oui, merci, mais c'est pas du tout la question

 
je répondais à la 3) où il m'avait semblé déceler une demande de confirmation. Désolé.

et pour la 3), pas besoin de gérer les verrous avec les transactions donc ?

 
Il ne me semble pas puisqu'avec les transactions, tout ce fait en ram avant le commit. Donc, on travaille sur une copie de la table que l'on est en train de modifier (ou du moins, lune copie de l'enregistrement), je pense.

Mais corrige moi si je me trompe, les tables transactionnelles, ça demande quand même un peu plus de maintenance non ? pour gérer les fichiers de log, et tout ça et tout ça.
Si tu dois développer pour des mecs qui veulent avoir le minimum à gérer derrière, vaut mieux rester en MyISAM ?
 
Enfin d'une manière générale, dans quels cas vaut il mieux choisir des tables transactionnelles ou non ?

non, je pense pas que ça change grand chose côté maintenance. En MyIsam, le commit() est fait automatiquement te y'a pas de rollback possible (ou alors, faut que tu te le gères toi même avec tes fonctions à toi). En InnoDB, tu fais le commit au moment qui te parraît opportun te tu peux faire du rollback (dans le cas où une erreur survient à un moment donné dans le processus de MAJ d'une ou plusieurs tables).

S'il n'y a pas de différence au niveau de la maintenance et / ou de la place necessaire, a quoi sert le type MyIsam ? Parce que dans ce cas, il n'a aucun interet.

Ben c'est le format par défaut de mysql, et il était là le premier... Donc, dans un souci de compatibilité, ils l'ont gardé. Et puis, pas la peine de sortir de rouleau compresseur quand la tapette à mouche suffit

ok merci bcp pour tes réponses.
 
En fait, quand j'avais regardé, la configuration de la taille et l'emplacement du fichier de log m'avait paru plus compliqué (changer l'emplacement du fichier de log quand il est trop gros, etc). En même temps j'ai jamais regardé comment faire la config pour une table MyIsam
 
Et donc avec les tables transactionnelles, tu peux sans souci restaurer ta base telle qu'elle était à un instant t ? donc pas besoin de stocker les actions effectuées dans la base elle-même ?

Attention, tu peux restaurer les tables sur lesquelles tu n'as pas fait de commit() dans l'état où elles se trouvaient avant que tu fasses les modifs. mais ça ne garde pas tous les états successifs des tables au cours du temps (t'imagines, sinon, la taille qu'il faudrait quand on travaille sur une grosse BD???)...

bah moi c'est bien ce que j'avais compris en fait. Qu'en cas de corruption de la base, tu pouvais refaire toutes les opérations qui avaient eu lieu depuis la dernière sauvegarde de la base :x

là, ça ne concerne plus les transactions mais la politique de sauvegarde. Pour la corruption de la BD, à part un pb de HDD, je vois pas (à moins qu'un code source foireux corrompt les données)...

oui je parlais d'un vilain vilain crash serveur
 J'avais cru lire qu'avec les tables transactionnelles tu pouvais refaire toutes les opérations qui avaient eu lieu depuis la dernière sauvegarde de la base (ouais je radote).
 
Et donc tu me dis que c'est faux ?

ben oui, c'est faux. En +, si ton disque il crash, où vas-tu récupérer les infos pour "rejouer" les opérations qui ont eu lieu depuis la dernière sauvegarde. Les transactions se font en RAM. Si ton disque crash, faut le changer. Tu dois donc arrêter ton PC pour effectuer le changement de disque : tu perds donc ce qui est en RAM. CQFD

ouais c'est sur :x
mais alors, là (par exemple) : http://www.manuelphp.com/mysql/innodb-overview.php
 
ils veulent dire quoi par

 
et par rapport aux verrous :

donc les lignes utilisées restent verouillées tant que tu n'as pas fini ta transaction ?

"Capacité de restauration après crash"... de la base de données, pas du HDD. En lisant ce paragraphe, on comprend mieux de quoi il en retourne : http://www.manuelphp.com/mysql/implementation.php
La restauration est possible grâce aux fichiers de logs qui tracent les insert/update/delete. Donc, en repartant d'une base de données VALIDE (et précédemment sauvegardée), on peut restaurer jusqu'à un certain point. Comme précisé, si on fait pas de purge de temps en temps de ces ficheirs de logs, ils vont grossir énormément...
 
"InnoDB utilise un verrouillage de lignes" -> je pense que oui, les lignes restent verrouillées tant que les transactions sont pas finies, mais comme j'ai compris, il est possible d'effectuer plusieurs verrouillages sur les mêmes lignes, c'est ce qu'ils appellent le multi-versionning.

oui alors au temps pour moi, depuis le début je parlais de restauration après crash de la base. Donc finalement j'en reviens à mes premières questions :

 
et

Puisque donc il faut s'occuper de purger les fichiers de log, ça demande bien un peu plus de maintenance non ? Si tu ne fais pas cette maintenance, ça risque de poser probleme j'imagine ?

les fichiers de logs son normalement purgés automatiquement puisque les transactions complètement terminées sont supprimées (c'est ce que j'ai compris de la doc).
Au fait, c'est pour gérer quoi ta BD?

bah là j'ai 2 projets :
- une pour stocker des données biologiques, les informations d'obtention, et les informations relatives (gène, sonde, etc) (un énorme gros bordel)
- une autre relativement simple pour stocker les informations d'un jeu (créatures rencontrées, objets qu'ils laissent etc)
 
Et en fait, je me disais que plutôt que devoir se faire chier à utiliser des verrous, utiliser des transactions qui gêrent les verrous toutes seules ça pouvait le faire ^^