MyISAM -> InnoDB (Problème Stored Proc)

Version imprimable

22/11/2005, 20h29
Erakis

MyISAM -> InnoDB (Problème Stored Proc)

Bonjour

J'ai développé un projet qui inscrit des centainnes voir des milliers d'enregistrements par jours. Au début je voulais créer des procédures stockées et des vues qui aurait permis à mon système d'être multi-SGBD. Mais je me suis vite rendu compte que MySQL ne supporterait pas les procédure STOCKÉS (de manière complète) avant la version 5.1. Comme mon premier client avait choisi MySQL (pour sa gratuité) alors j'y choisi de développé et de publier avec MySQL :koi: Donc j'ai décidé d'envoyer les requêtes via programmation pour le moment.

Au début (il y a près de deux ans) j'utilisais le GUI MySQL Control Center, celui-ci créait des tables de type MyISAM et je ne savais pas trop ce qu'il en était et surtout qu'il y avait d'autres types de tables.

Maintenant j'aimerais améliorer ce projets et améliorer là où j'avais des questions. Voici les points principaux dont j'ai BESION :

:arrow: Supporter beaucoup, beaucoup, beaucoup de données
:arrow: Supporter les transactions
:arrow: La possibilité de faire des backups quotidiens COMPLET (schémas, données, procédures stockées, vues, etc.)
:arrow: Supporter les clé étrangère serait un atout dans certainne tables
:arrow: Beaucoup de clés sont basées sur des champs DATETIME, alors il
serait agréable que les performances ne soit pas trop coupé.

Après avoir jeté un petit coup d'oeil à la FAQ, j'en ai déduit que le meilleur format de table serait InnoDB :wink:

Cette semaine j'ai convertis mes tables MyISAM en InnoDB et j'ai tenté d'ajouter des vues et procédure stockées. J'ai tant bien que mal essayé avec MySQL Control Center, MySQL Administrator et enfin avec MySQL Front et il me disent tous que la procédure stockés à été créer mais une fois que je ré-ouvre les propriétés de la table, nada, plus rien...

Si je créer une nouvelle base de données InnoDB et que j'y ajoute une procédure stockées, pourtant là elle réside et cela fonctionne.

Merci d'avance pour vos commentaires c'est grandement apprécié.
27/11/2005, 14h24
Adjanakis

Bonjour,

y a t-il eu des messages particulers dans le log d'erreur ?
29/11/2005, 15h21
Erakis

Bizzarement non.
12/12/2005, 16h43
Erakis

Bonjour,

Je n'ai toujours pas eu de réponse à savoir lequel des moteurs étaient le plus adaptés pour mes besoins ? InnoDB ou MyISAM ?
12/12/2005, 17h01
pcaboche

Citation:

Envoyé par Erakis

Bonjour,

Je n'ai toujours pas eu de réponse à savoir lequel des moteurs étaient le plus adaptés pour mes besoins ? InnoDB ou MyISAM ?

Ca, c'est une question très vaste et la réponse n'est pas évidente (il n'y a qu'à voir le nombre de résultats dans Google quand on tappe les mots "MyIsam" et "InnoDB" pour s'en rendre compte)

Le mieux, c'est quand même de chercher sur Internet et sur développez.net pour des articles sur le sujet.

En voilà un, par exemple:
http://www.phpdiary.org/articles/myisam-vs-innodb/
avec un tableau récapitulatif en 3ème partie.

Si vous trouvez d'autres articles sur le sujet, n'hésitez pas à y faire référence ici.
12/12/2005, 17h37
Erakis

Bonjour,

Tout d'abord, merci pcaboche pour le coup de main c'est apprécié ;)

J'aime bien ce passage For instance InnoDB for key account and transactional data, MyISAM for logs.

Parlons de ma fameuse table qui est déjà rendu à ~500Mo Mo. J'ai un seul service windows qui insert des données mais plusieurs clients web qui peuvent consulter ces données. Donc si j'ai un SEUL writer je n'ai pas vraiment besion de transaction ?

Autre chose, mon LOG est extrêmement important, mais possède à peine 2% de la taille de ma grosse table. Comme il est primodiale et doit être facile à récupérer en cas de corruption, je le verrais plus en version InnoDB ?

Si j'ai bien compris les tableaux les Merge (union views) sont impossible avec les table InnoDB ? Pas très très pratique 8O ...

Ici on dit : Relative disk use haute pour le InnoDB, déjà sous MyISAM j'ai plus de 500Mo pour 10098424 entrées alors si InnoDB prend plus d'espace de disque (plus lents en occurance sûrement) alors on parlera de quoi comme différence de taille une fois convertis ?

Merci à tous.
12/12/2005, 19h36
pcaboche

Citation:

Envoyé par Erakis

Tout d'abord, merci pcaboche pour le coup de main c'est apprécié ;)

De rien, j'essaye d'aider !

Citation:

Envoyé par Erakis

Parlons de ma fameuse table qui est déjà rendu à ~500Mo Mo. J'ai un seul service windows qui insert des données mais plusieurs clients web qui peuvent consulter ces données. Donc si j'ai un SEUL writer je n'ai pas vraiment besion de transaction ?

Rien à voir: les transactions servent surtout à assurer une certaine cohérences des données.

En effet, dans un script, tu as souvent des requêtes qui sont dépendantes les unes des autres, et ce n'est qu'à la fin du script que tu te retrouves dans état cohérent. Si une panne survient avant la fin du script, alors tes données ne sont plus cohérentes (ce serait embêtant de débiter le compte courant de quelqu'un sans créditer son compte d'épargne), c'est pour cela qu'on utilise des transactions : pour pouvoir annuler la transaction en cas de problème.

Dans le cas d'insertion massive de données (ex: fichier de log), c'est moins crucial (quoique ça dépend de ton problème)

Citation:

Envoyé par Erakis

Si j'ai bien compris les tableaux les Merge (union views) sont impossible avec les table InnoDB ? Pas très très pratique 8O ...

C'est vrai que ça peut-être pratique. Reste à voir si tu comptes l'utiliser.

Citation:

Envoyé par Erakis

Comme il est primodiale et doit être facile à récupérer en cas de corruption, je le verrais plus en version InnoDB ?

Est-ce que ça va changer grand chose? Je ne suis pas sûr.

Citation:

Envoyé par Erakis

si InnoDB prend plus d'espace de disque (plus lents en occurance sûrement) alors on parlera de quoi comme différence de taille une fois convertis ?

J'en sais rien !

Citation:

Envoyé par Erakis

J'aime bien ce passage For instance InnoDB for key account and transactional data, MyISAM for logs.

Ca résume assez bien tout ce qu'on a vu précédemment:
- pas forcément besoin de transaction
- nécessite moins d'espace
- possibilité de faire des Union Views
- un seul writer donc pas besoin d'un verrou de ligne (un verrou de table suffit)

Sinon, est-ce que tu pourrais nous exposer un peu plus en détails ce que fait ton appli? (type de log)
12/12/2005, 19h47
Maximil ian

Citation:

Envoyé par Erakis

Ici on dit : Relative disk use haute pour le InnoDB, déjà sous MyISAM j'ai plus de 500Mo pour 10098424 entrées alors si InnoDB prend plus d'espace de disque (plus lents en occurance sûrement) alors on parlera de quoi comme différence de taille une fois convertis ?

Citation:

Envoyé par Dans la FAQ MySQL il y

Probablement à cause du multi-versioning, les bases InnoDB sont nettement plus grosses que leur équivalent MyIsam. A nombre d'enregistrements égal, comptez au moins 25% de volume en plus.

http://mysql.developpez.com/faq/?pag..._inconv_innodb
12/12/2005, 20h02
Erakis

Bonjour,

Bonne nouvelle !
Comme j'ai effectivement besion des UNIONS, j'ai essayer ce type de requête sur un table InnoDB avec MySQL 5.0 et cela fonctionne TRÈS bien ;)

Pour répondre à ta question pcaboche, lorsque j'inscris des données à ma grosse table, il se peut que j'aie 1 à plusieurs entrées à inscrire aussi à mon journal en fonction de ces entrées, mais elle doivent être TOUTES inscrites, si un plantage surviendrait ce serait non-linéraire !
Donc, OUI j'ai utilimement besion de transactions pour mon journal.

Citation:

Envoyé par Erakis

Parlons de ma fameuse table qui est déjà rendu à ~500Mo Mo. J'ai un seul service windows qui insert des données mais plusieurs clients web qui peuvent consulter ces données. Donc si j'ai un SEUL writer je n'ai pas vraiment besion de transaction ?

PS : Désolé, pour ce que j'ai dit à propos de mon "writer", j'étais dans le champs et je viens de m'en rendre compte, effectivement ça n'a rien à voir :oops: .

J'ai lu attentivement vos replies et j'en ferai bonne usage.
Merci à tous.