Reprise du message précédent :

http://ubuntuforums.org/showthread.php?t=29420

on appelle ça le "knowledge curse" ceux qui savent n'ont plus la capacité à ce mettre à la place de ceux qui ne savent même pas que ça existe.

c'est vrai que j'ai parfois du mal quand des utilisateurs lambda n'arrivent pas à utiliser des fonctionnalités qui me paraissent évidentes (genre notre nouvelle secrétaire qui savait pas utiliser internet).
Mais j'arrive à conceptualiser qu'ils puissent avoir du mal (même si j'arrive pas forcément à me mettre à leur place). Je reste pas borné "mais non, c'est pas parce que le logiciel est compliqué, c'est parce que t'es nul(le)".

Au fait si vous partez sur du InnoDb sur toutes vos tables vous pourrez plus utiliser les fonctionnalités d'index Fulltext de MySQL (mais c'est pas une grand perte, vaut mieux utiliser Sphinx ou Lucene)

ouais, je me démerderai à l'extérieur.

C'est surtout qu'ils avaient leur moteur tout moisi dont l'unique avantage est d'être rapide sur les requêtes simplissimes, qu'ils ont intégré un vrai moteur de SGBD mais qu'ils ne peuvent pas virer l'ancien parce que la majorité de leur utilisateurs sont des phpeteurs ignorants qui ne comprendraient pas que leur select prenne 10% de temps en plus en échange de fonctionnalité qu'ils jugent inutiles vu qu'ils ne les comprennent pas

Les tables sensibles sont générallement les tables où tu as besoins de perfs: les messages sur un forum, les articles pour un site marchand, les transactions pour une appli financière, etc.

J'ai pas testé Lucène mais Sphinx ça pootre c'est garanti

d'avoir des perfs optimales pour les newbs qui en ont rien à tapper des transactions soit 98% des cas.
Et ceux qui connaissent les transactions et en ont besoin lisent la doc pour utiliser l'engine qui leur convient. (une petite recherche sur "transaction" sur la doc dispo sur le site de MySQL n'est pas trop difficile a priori )

MySQL devrait fournir un fichier de conf my-transactionnal-taliban.cnf dans sa distrib

Et ça tombe bien que ce soit davantage sur les requêtes simples, car devine quoi, sur les appli web les requêtes c'est jamais des trucs de tarés
Donc je préfère de loin garder mes perfs si tu n'y vois pas d'inconvénient

Un forum pour moi c'est pas sensible => MyISAM
Articles d'un site marchand c'est quasi du statique (par rapport à l'activité des autres tables du site marchand, enfin j'espère pour le site marchand ) => MyISAM
Transactions financières c'est critique => InnoDb

 
+1

j'ai testé tous les storage engine du monde sur HFR (bon j'exagère un bon ), et je peux te dire que c'est MyISAM qui gagne. Rien que le fait qu'un COUNT(*) prenne du temps sur innodb, ca me fait chier

Si c'est des newb, ils sont de toutes façons incapables d'optimiser le reste, parce que un desc c'est imbitable.
 

non, parce que personne n'irait imaginer que le dernier truc dont ils se vantent n'est pas activé par défaut.

pourquoi ne pas utiliser un engine custom si tu cherches des perfs ? les algos sont connus, ils sont tous dans la nature.

nraynaud > Pour quelle(s) raison(s) as-tu fait le choix de MySQL actuellement ?

je profite d'un soir ou personne ne poste de trucs intéressant pour m'interroger sur l'afro coureur de 20km démissionnaire  
 
tu deviens quoi ?  
tu vis de quoi (pas de chomage comme la crapule de chouxfleur j'imagine)
ton projet en 2 mots c'est quoi ? habiter pres de la mer ? poster depuis une cybercrêperie ?  
tu te donnes combien de temps pour faire une depression/aller bosser chez g@tsu ?

Pas que ca a foutre
Mais je peux te garantir que si tu fous innodb par defaut et que la plupart des applis de forum/communautaire ne spécifient pas l'engine dans le create table, ca va être une cata sur le net
Donc autant ne pas emmerder 99% de la base installée.
Après si tu veux des perfs et du transactionnel, tu peux aller regarder du coté de l'engine Falcon, mais faudrait que je le reteste pour voir si le comportement en autocommit est pas 'foireux' pour l'utilisateur lambda (j'ai peur que si).

enfin surtout le fait qu'une population d'extrem mysql hackers adorent ça (parce que pour l'instant, les seuls qui défendent cette merde, c'est pas exactement des débutants), n'en fait pas un truc à activer par défaut ! surtout vu les risques que ça pose.  

j'ai pas de fric, ça m'en laissait pas beaucoup, et postgres, j'aurai pas assez d'outils et de pages google dessus. Et je suis pas forcément fan de certains trucs.

mais pourquoi ? ça rame innoDB ? je croyais que MySQL torchait tout "out of the box" dans les benchmarks. et TPC c'est avec des transactions pourtant.

non honnetement je pense que c'est lié à la base installée, le comportement de innodb n'est pas toujours le même, le système d'index n'est pas le même (clustered pour innodb), donc pour les applis existantes mal foutues (la grande majorité, phpbb est un bon exemple), ca fouterait un bordel sans nom.

j'ai un phpBB qui est corrompu justement (et j'ai jamais compris où est le pb)

non innodb n'est pas forcement plus lent, ca depend de son utilisation. Mais sur les COUNT(*) si il est plus long, du fait de sa gestion des fantoms rows etc, il ne peut pas avoir un compteur qui maintient le nombre d'enregistrement dans la table en interne, ce que MyISAM fait. Du coup tu te tappes du table scan sur un COUNT(*), qui est plutôt couteux. Faut redesigner ton appli pour gérer un compteur à part si tu veux des perfs correctes avec innodb dans ce cas.

je deviens aigris, y'a rien qui marche, plein le cul.
je vis sur mon assurance vie.
c'est top secret, y'a joce qui traîne.
je me donne le temps qu'il faudra.

Ok
 
C'est quoi les trucs en question dont t'es pas fan ?

c'est la première fois que j'entend parler de ça  
 
et le versionning ? enfin l'algo est pas surper trivial, mais ça se fait en O(1) ce truc.

S'il n'y avait eu qu'innoDB de dispo vous auriez optimisé votre bousin pour qu'il tienne la charge

Les newbs n'ont pas besoins de perfs optimales vu qu'ils font des requêtes pourries qu'ils peuvent facilement optimiser une fois qu'ils prennent un peu de bouteille

C'est bon tu peux y aller, j'habite déjà près de la mer

putain mais double
 
comme t'a rien a faire, passe a lille (en train, depuis l'ouest ça se fait bien ©) on ira s'en jeter plusieurs
et on pourra parler librement
 
 
sinon Joce, comme tu sert aryen, tu peux m'enlever mon _ sur mon pseudo ?

le vacuum, les réglages manuels, et les bouts de code dans tous les sens pour avoir des fonctions un peu évoluées.

c'est ce qu'utilise falcon

tiens puisqu'on a des hackers de la morts en serveurs web, vous savez utiliser mod_pam ?

c'est bizarre, j'ai trainé dans des docs de mysql récemment et j'ai pas vu passer ce truc.

avec un fichier swf codé en actionscript [/tabouret en flash]

T'as vu mon lien que je t'ai posté à propos de apache à ptet mettre dans le groupe shadow ?

C'est le futur moteur (je sais plus si par défaut ou pas) de MySQL 6 : http://www.mysql.com/mysql60/

 
merci j'avais pas vu la réponse.

c'est encore en alpha et c'est sensé avoir des vues qui marchent ? et des vues matérialisée ?

Moi j'aimerais bien supprimer le 's' de mon pseudo
 
(et je m'en tape si ça reste sur mes anciens posts)

Bon apparement ils ont corrigé le 'problème' du repeatable read, bien que ca ne soit pas par defaut :