Reprise du message précédent :
tape « mount », tu verras la liste des partitions, tu choisis celle où se trouvent les DB et tu lis le type (ext3/reiserfs/jfs/...)

c'est ext3 alors.

Bah c'est pas ton FS qui limite alors..

A plus qu'à modifier ta configuration MySQL comme indiqué dans le quote de Rosco

ok, merci
 
Mais vous savez pas pourquoi il y a ces limites? au dela ca nique les perf mysql? ou c'est juste par "sécurité" en cas de probleme avec le fichier?
 

La raison est écrite dans le post de rosco !

je vais voir
 

C'est expliqué dans le quote. La taille des pointeurs pour accéder à une partie du fichier est réduite par défaut pour des perfs maximum (tout le monde n'a pas d'énormes tables), ce qui limitent la plage d'accès à ton fichier. C'est plus rapide, car y a moins à lire (c'est pareil que de choisir le type de donnée le + petit possible, ça évite de bouffer de la place à rien et d'augmenter la taille des données à lire lors d'une requête). Si tu veux aller + loin avec des pointeurs codés sur + de bits, il faut le préciser à MySQL en configuration générale ou plutôt lors de la création de la table s'il n'y en a qu'une qui est énorme (ou faire un ALTER dessus).

Sinon y a aussi la possibilité de scinder ta grosse table en 2 par exemple et de créer une 3ème table utilisant le moteur MERGE pour rassembler les 2 grosses tables précédentes de manière symbolique, tu fais tes requêtes en t'adressant à cette nouvelle table, le moteur fera le boulot lui-même de manière transparente, mais c'est pas forcément pratique si faut recoder derrière et ce moteur a quelques inconvénients...

ok merci, je vais voir ca!

Tiens je drapalise ce topic pour d'éventuels conseils en SQL, car j'ai fais une copie de MD.net mais j'aimerai un peu mieux l'optimiser pour tout ce qui est requêtes DB
 

Y'en a qu'ont peur de rien

j'espere que c'est une blague  

A part le logo, risque pas grand chose, si

ben si, concurence deloyal avec le skin identique (contrefaçon) a celui de MD et parasitage pour le nom du forum.  
 
Mais bon, ca ressemble a une blague, sinon, il aurait donner l'url de son forum au lieu d'un simple skin
 

Il avait déjà posté sur le forum MD : http://www.mesdiscussions.net/foru [...] et_1_1.htm

C'est sûr que pour le logo, c'est un peu foutage de gueule, mais à part ça... Il n'en fait pas commerce/distribution, la concurrence ne s'y applique pas.

ben son but est de le distribuer, c lui qui le dit, d'ailleur, il s'apelle "open", donc faut le distribuer pour qu'il soit "open"    
 
Et il risque d'y avoir confusion dans la tête des utilisateurs, ils vont croire que c'est un MD gratuit.
 

Ah oui j'ai relu, il parlait de code MD, pas de son forum effectivement.

 
effectivement c'est uniquement par défit personnel et nullement dans le but de nuire à MD.net
 
donc non le forum ne sera jamais "distribué" en l'état ... Quoiqu'il me suffirait de modifier uniquement le logo pour ne plus rien avoir à me reprocher légalement car tout le reste a été recodé entièrement
 

c'est juste qu'il est hébergé en local seulement, usage privé et bétatest only

pré alpha 1 au bout de 5 ans. Qui dit mieux?
 
Bon, vu ma vitesse digne de superman, la prochaine étape sera l'alpha2 dans 2 ans avec une réécriture du système de template pour mieux utiliser le framework que j'ai choisit.

ha oué, quand même... dire que j'enrageais de ne pas avoir dépassé le stade alpha au bout d'un an 1/2 de dev

Salut, quels sont les avantages et inconvénients InnoDB vs MyISAM? Je lis de tout et de n'importe quoi, bien évidemment c'est des avis purement théoriques qu'on trouve sur le web, alors je souhaitais avoir des feedbacks d'une utilisation dans la vraie vie, ex: je sais que MyISAM fait du table-lock, mais en pratique est-ce si gênant?
 
Je voulais connaître en vrac:
- différence de perf en pratique en INSERT, SELECT, UPDATE, DELETE
- comportement de la DB en cas de crash du serveur (coupure élec, saturation de la mémoire, etc)
- facilité (ou pas) de backup des données
- est-ce que la gestion manuelle de l'intégrité des données avec MyISAM est-elle pénible à coder? (j'ai pas l'impresion amha)
- votre avis sur la question et tout autre point qui m'aurait échappé
- des liens qui parle de innodb vs myisam si ça a déjà été débattu et rebattu plusieurs par le passé
- subsidiaire: et innodb vs myisam vs postgresql?

ben innoDB gere les relation entre les tables, comme dans access par exemple, ce qui fait que c'est plus lent. En utilisant cela, tu perd aussi l'interet de mysql qui est fait pour être leger et rapide.
 
Aprés ya peut etre d'autre difference, mais c'est la plus importante si je ne me trompe pas.
 

Tu vas vite en besogne dit donc !! Y'a tellement de paramètres à prendre en compte (Nb threads concurrents / Nb d'enregistrements / Taille des différents buffer spécifiques au moteurs / Niveaux de locking / ...) que ce que tu racontes c'est n'importe quoi..
Perso je n'utilise qu'InnoDB, j'me vois mal gérer à la main les relations !

Les diff de perfs ça dépend trop de ton utilisation pour en parler comme ça. Disons que les gros sites Web 2.0 qui utilisent MySQL c'est InnoDb only.
En cas de crash Innodb est bien meilleur que MyISAM car c'est journalisé. Avec MyISAM sur un gros crash tu peux perdre des données et la réparation n'est pas garantie.
Pour le backup t'as pas mal de possibilité et c'est (un peu) indépendant du moteur : mysqldump du maitre avec arret des applications (pour avoir un backup consistant), réplication vers un esclave que tu peux arreter le temps du dump, snapshot LVM pour faire de la sauvegarde à chaud. Après t'as des solutions propriétaires comme Zmanda et Innodb hot backup.
Pas forcément pénible à coder AMHA
Perso si l'appli est critique en terme de données, Innodb sans hésiter. Si tu peux te permettre de perdre des heures de données par exemple et de remonter une base à partir d'un backup en cas de gros crash dans ce cas tu peux faire du MyISAM. A noter que le prochain moteur MySQL Maria (remplaçant de MyISAM dans la v6) sera crash-safe.

Tu crois ?  

Ou postgres, qui a tendance à être plus rapide (quand il est correctement configuré, la config par défaut de postgres même 8.x n'est pas optimisée perfs), plus flexible, avec plus de fonctionalités et plus de datatypes (PostGIS bitch ), et qui scale mieux sur les gros serveurs

Ouais mais c'est tout, toujours pas d'ACID ou quoi que ce soit du genre

edit: puis c'est comme Falcon, faudrait déjà qu'ils sorte, histoire qu'il puisse être débuggé. D'ailleurs faudrait déjà que 5.1 sorte, aussi

 
Avec MySQL t'as la gestion des données spatiales aussi : http://dev.mysql.com/doc/refman/5. [...] sions.html
Maria sera ACID : http://monty-says.blogspot.com/200 [...] eased.html
 
Par contre j'aimerais bien que la 5.1 sorte aussi en GA sinon je vais devoir mettre une beta sur la nouvelle plateforme technique qu'on est en train de définir au taff (je veux le partitionnement) et ça m'arrange pas particulièrement.

PostGIS est certifié OpenGIS - Types and Functions quand même

Et Duke Nukem Forever sera released. Pour le moment, Maria n'est pas ACID, il le serait peut-être potentiellement quelque part dans le futur, mais la réalité du moment c'est pas le cas. Et même sur Maria 2.0, le monsieur indique que...

Z'avez qu'à passer sous postgres

Je suis en train de tester une appli sous PostgreSQL (avant sous MySQL) suite à vos commentaires, et ça se passe bien pour le moment. Je vais lui rentrer un peu dans le ventre maintenant.

Oui le moteur Maria est à visée de remplacer MyISAM donc il pourra (et je pense que ce sera le mode par défaut) tourner en non transactionnel.
Sur mon appli principale dont je m'occupe au taff je suis passé sous Innodb et je m'en plains pas pour l'instant (par contre faut mettre le innodb_file_per_table sinon on peut pas réclamer l'espace disque inutilisé dans le tablespace)

Trop de compétences MySQL en interne
Et on n'a pas payé les licences pour rien

Lis bien le manuel postgres par contre (pour ce que j'ai pu en voir, il est pas mal, détaillé et bien organisé) Et si un jour tu passes en prod', cherches bien les ressources sur le tuning aussi bien dans le manuel que sur l'interweb mondial

Pour MyISAM VS InnoDB, InnoDB *récupère* mieux les crash que MyISAM, ou il peut carrément en éviter ?

Avec InnoDB, il n'y a pas de risque que ta table soit corrompue après un crash (enfin plus précisément InnoDB va lancer une recovery au démarrage et s'il y avait des transactions en cours pendant le crash elles devraient simplement être rollbackées, mais toute la db devrait rester dans un état consistant, sauf bug rencontré dans innodb naturellement). Avec MyISAM tu n'as pas cette garantie, donc si tu as eu un crash pendant un write ta db peut être corrompue partiellement ou intégralement, avec pertes de données.

Après, naturellement le choix de prendre ce risque ou pas dépend de la criticité des données et la fréquence des backups par rapport à la fréquence des écritures.

Ca commence bien, l'installation de PostgreSQL 8.3 à partir du repo backports sur ma Debian Etch foire totalement. Sur mon Mac y'a eu aucun souci.
 
Je vais ouvrir un thread là-dessus.
 
EDIT: autant (au temps?) pour moi, mon fichier /etc/hosts était vide. Il faut au minimum "127.0.0.1 localhost", voilà pour ceux qui voudraient tester PostgreSQL.

Vu que c'est l'annif du Baron aujourd'hui, je tiens à lui rappeler un petit souvenir

ouais d'abord, il est où le forum codé en ASM ?