Discussion :

[Erakis]

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 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 :

Supporter beaucoup, beaucoup, beaucoup de données
Supporter les transactions
La possibilité de faire des backups quotidiens COMPLET (schémas, données, procédures stockées, vues, etc.)
Supporter les clé étrangère serait un atout dans certainne tables
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

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é.

[Adjanakis]

Bonjour,

y a t-il eu des messages particulers dans le log d'erreur ?

[Erakis]

Bizzarement non.

[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 ?

[pcaboche]

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.

[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 ...

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.

[pcaboche]

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

De rien, j'essaye d'aider !

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)

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

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

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.

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 !

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)

[Maximil ian]

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 ?

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

[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.

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 .

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