Table MySQL transactionnelle ou non?

[sabearts]

Hello,
imaginons une table MySQL à 100.000 entrées et 60 champs (INT ou VARCHAR principalement). Sachant que cette table peut être consultée par un grand nombre d'internautes en même temps (sous le même nom d'utilisateur MySQL, avec les mêmes autorisations) mais qu'il faut que la recherche soit très rapide, quel type de table me conseilleriez-vous?

:heu:
J'avoue que j'hésite, un éclairage serait utile...

Merci d'avance

 

[p4bl0]

Hello,
imaginons une table MySQL à 100.000 entrées et 60 champs (INT ou VARCHAR principalement). Sachant que cette table peut être consultée par un grand nombre d'internautes en même temps (sous le même nom d'utilisateur MySQL, avec les mêmes autorisations) mais qu'il faut que la recherche soit très rapide, quel type de table me conseilleriez-vous?

:heu:
J'avoue que j'hésite, un éclairage serait utile...

Merci d'avance

de la lecture : http://dev.mysql.com/doc/refman/5.0/fr/ansi-diff-transactions.html

 

[sabearts]

de la lecture : http://dev.mysql.com/doc/refman/5.0/fr/ansi-diff-transactions.html

donc si j'ai tout bien compris j'ai besoin de MyISAM... je n'avais pas vu cette partie de la doc MySQL, merci!

 

[p4bl0]

donc si j'ai tout bien compris j'ai besoin de MyISAM... je n'avais pas vu cette partie de la doc MySQL, merci!

de rien, j'ai juste cherché "mysql table transactionnelle avantage" dans Google, j'avais jamais entendu parlé de table transactionnelle avant

Je sais qu'en général par défaut dans PHPMyAdmin quand on créer une table après la création des champs de la table il y a "engine=MyISAM; DEFAULT CHARSET..." ou un truc du genre

 

[da capo]

du peu que j'en sais :
- la rapidité d'accès à une base de données passe par l'optimisation des requêtes et aussi par l'indexation des champs censés être les éléments déterminants pour les requêtes les plus nombreux.
Au delà de la réactivité du serveur, l'écriture de la requête doit être faite pour profiter au mieux du moteur. L'indexation permet d'accéder plus rapide aux données. Elle induit une étape supplémentaire lors de l'écriture de nouvelles données mais permet ensuite un accès plus direct.

Les transactions, à priori, n'apportent aucun gain de vitesse, au contraire, elles sont là pour sécuriser les opérations en écriture (ajout, modification, effacement)

 

[Anonyme]

Pour info, Dotclear 1 (oui je sais mais comme je l'utilise régulièrement ) travaille en MyISAM et c'est dans le code php que se gère les interactions entre les tables (si on efface le billet 52 dans la table des billets alors effacer tous les commentaires associés dans la table des commentaires).

Dans Dotclear2, les tables sont au format InnoDB et l'effacement d'un billet effacera «automatiquement» les commentaires dans la table correspondante : c'est mysql qui fait tout le travail.

 

[p4bl0]

Pour info, Dotclear 1 (oui je sais mais comme je l'utilise régulièrement ) travaille en MyISAM et c'est dans le code php que se gère les interactions entre les tables (si on efface le billet 52 dans la table des billets alors effacer tous les commentaires associés dans la table des commentaires).

Dans Dotclear2, les tables sont au format InnoDB et l'effacement d'un billet effacera «automatiquement» les commentaires dans la table correspondante : c'est mysql qui fait tout le travail.

tiens c'est intéressant ce truc là InnoDB !

c'est en standard dans MySQL ? par exemple chez Free c'est dispo ?

 

[da capo]

chez free, on a ça :

 

[Anonyme]

tiens c'est intéressant ce truc là InnoDB !

c'est en standard dans MySQL ? par exemple chez Free c'est dispo ?

Je crois que les tables chez free sont formatée par défaut en MyISAM. Pour avoir des tables transactionelles, tu dois passer à php5 et Postgresql (gérées aussi par Dotclear 2 ).

Tu dois mettre un .htaccess avec ceci comme première instruction :

SetEnv PHP_VER 5

…et demander le passage à postgresql. Attention le passage à postgresql efface la base mysql.

 

[tatouille]

du peu que j'en sais :
- la rapidité d'accès à une base de données passe par l'optimisation des requêtes et aussi par l'indexation des champs censés être les éléments déterminants pour les requêtes les plus nombreux.
Au delà de la réactivité du serveur, l'écriture de la requête doit être faite pour profiter au mieux du moteur. L'indexation permet d'accéder plus rapide aux données. Elle induit une étape supplémentaire lors de l'écriture de nouvelles données mais permet ensuite un accès plus direct.

Les transactions, à priori, n'apportent aucun gain de vitesse, au contraire, elles sont là pour sécuriser les opérations en écriture (ajout, modification, effacement)

// table MySQL .... et 60 champs

tu peux ajouter savoir faire une DB ....

 

[da capo]

// table MySQL .... et 60 champs

tu peux ajouter savoir faire une DB ....

Tiens, je n'avais même pas fait attention.

Mais s'il y a 60 champs, c'est que c'est utile, non ?

 

[Anonyme]

blablabla Pour avoir des tables transactionelles, tu dois passer à php5 et Postgresql (gérées aussi par Dotclear 2 ). blablabla...

J'ai confondu transactionnelles et relationnelles... Ça m'apprendra à ne pas lire la doc donnée par p4bl0. :rolleyes: :mad: La honte...

Quand on ne sait pas, on se tait...

 

[sabearts]

// table MySQL .... et 60 champs

tu peux ajouter savoir faire une DB ....

Que veux-tu dire par là? je pense que les tables que j'utilise jusqu'ici (MyISAM, par défaut donc) vont déjà pas mal avec 60 champs. Je cherche juste à optimiser les performances, si elles sont lues et modifiées par un grand nombre d'internautes en même temps. Il s'agit donc d'une table dynamique bien entendu, et non statique (cfr varchar...)
MySQL dit que les tables non transactionnelles sont plus rapides. Et je pense que le fait de commencer à lire une ligne est plus lent que de lire la ligne en elle-même, donc pourquoi fragmenter en plusieurs tables si ce n'est pas nécessaire?

Maintenant, es-ce que MyISAM pose vraiment des problèmes de sécurité en matière de modifications de données? Je n'ai pas l'expérience à une si grande échelle...

 

[da capo]

J'imagine que tatouille fait remarquer que 60 attributs pour décrire un élément, cela fait beaucoup et qu'il est souvent possible de profiter de la structure relationnelle pour alléger certaines tables.

 

[p4bl0]

Je crois que les tables chez free sont formatée par défaut en MyISAM. Pour avoir des tables transactionelles, tu dois passer à php5 et Postgresql (gérées aussi par Dotclear 2 ).

Tu dois mettre un .htaccess avec ceci comme première instruction :

SetEnv PHP_VER 5

…et demander le passage à postgresql. Attention le passage à postgresql efface la base mysql.

Chez Free il suffit de mettre "php 1" dans le .htaccess pour avoir PHP 5, ça c'est fait depuis longtemps.

Par contre passer à PortegreSQL ça je vais pas le faire, déjà parce que j'ai la flemme, même si en gros ça consiste à en rechercher remplacer dans les fichiers de mon site, et puis en plus je veux pouvoir changer d'hébergeur à tout moment, on sait jamais, alors je préfère rester avec le truc "de base" qu'on retrouve partout



@starmac Sur la capture que tu as posté, on a accès seulement au moteur non grisés c'est ça ?

 

[tatouille]

Que veux-tu dire par là? je pense que les tables que j'utilise jusqu'ici (MyISAM, par défaut donc) vont déjà pas mal avec 60 champs. Je cherche juste à optimiser les performances, si elles sont lues et modifiées par un grand nombre d'internautes en même temps. Il s'agit donc d'une table dynamique bien entendu, et non statique (cfr varchar...)
MySQL dit que les tables non transactionnelles sont plus rapides. Et je pense que le fait de commencer à lire une ligne est plus lent que de lire la ligne en elle-même, donc pourquoi fragmenter en plusieurs tables si ce n'est pas nécessaire?

Maintenant, es-ce que MyISAM pose vraiment des problèmes de sécurité en matière de modifications de données? Je n'ai pas l'expérience à une si grande échelle...

cela fait dix ans que je modélise des db pour gros systemes ...
je n'ai jamais vu une table avec 60 champs c'est pour te dire ... et si j'en avais vu une ...

table properties - table object -> table Object2properties

en gros : tu fais parti des personnes donc je dis :"il faut leurs couper les doigts pour plus qu'elles ne touchent un clavier" , les dangereux pour simplifier , c'est le cerveau qui est foiré donc plus qu'un espoir limiter l'action/mobilité

 

[gwena]

oui bon en même temps si on était né avec la science infuse ça se saurait!
plutôt que de crier sur le pauvre sabearts qui pose une question, explique lui pourquoi 60 champs c'est pas bien!
d'ailleurs tu peux me l'expliquer aussi, je me doute que trop de champs c'est pas terrible, mais pourquoi précisément? ça va ralentir la bdd? ça va bugger?? quoi quoi donc!?

 

[fredmac75]

salut,
Je ne peux qu'aller dans le sens de tatouille : une table, si c'est bien de cela dont nous parlons, avec 60 champs, c'est 45 - 50 champs en trop. Tu vas mettre ton serveur à genoux.

Je doute que tu ais besoin de la totalité des informations (en même temps) contenu dans un enregistrement (ou ligne). Ce faisant, essaie de redécouper en fonction des besoins : de quoi ais-je besoin avec cette requête.

Dans cette optique, fait des requêtes avec jointures.

Enfin, concernant les types de table (ISAM, MyISAM, Heap, INNODB), c'est d'abord une question de la volumétrie et d'application critique. Néanmoins, il est possible de mixer les genres au niveau des tables en profitant des avantages de chacuns.

 

[da capo]

La question de départ peut être aussi celle de la modélisation comme le suggérait Tatouille : les attributs multivalués n'ont pas droit de cité dans le modèle relationnel.

par exemple si une table reprend les coordonnées des clients, on peut imaginer que ces clients peuvent avoir fait l'objet de plusieurs factures.
comment gérer cela ?

en créant un champ unique contenant toutes ces valeurs ? non, parce qu'à l'évidence toute recherche sera rendue difficile voir infructueuse.
en créant autant de champs que de factures ? non plus, parce que le nombre de factures est potentiellement sans limite.

Le principe est de reporter ces information dans une nouvelle relation (table) présentant comme attributs l'identifiant de la facture, l'identifiant du client (clé externe), et des attributs propres à la facture (date etc.)

Partant de là, les tables se trouvent allégées, les accès sont clarifiés, l'indexation est rendue plus efficace et la rapidité de traitement l'est aussi.

Google regorge de tutoriels sur le modèle relationnel, les MCD, MPD, le passage de l'un à l'autre…

 

[tatouille]

oui bon en même temps si on était né avec la science infuse ça se saurait!
plutôt que de crier sur le pauvre sabearts qui pose une question, explique lui pourquoi 60 champs c'est pas bien!
d'ailleurs tu peux me l'expliquer aussi, je me doute que trop de champs c'est pas terrible, mais pourquoi précisément? ça va ralentir la bdd? ça va bugger?? quoi quoi donc!?

:rateau: nioub f(n)