Merci cyrano pour toutes ces infos.

Ça se tient. Mais quoi qu'il en soit, considère les performances au niveau du résultat davantage qu'au niveau du travail que ça représente en amont. S'il y a plus de manipulations mais qu'au bout du compte le résultat est plus rapide, alors c'est le bon choix.

Le choix du moteur MyISAM ou InnoDB dépend de la nécessité de pouvoir ou non faire des requêtes transactionnelles et de la possibilité d'utiliser les possibilités de maintien de l'intégrité référentielle quoique cette dernière peut être faite par programmation. Il faut aussi voir le rapport nombre d'écritures/nombre de lecture. Les requêtes en écriture seront plus lentes sur les colonnes indexées puisque l'index doit être reconstitué à chaque fois. Mais si l'essentiel des lectures sont des lectures de données, c'est un moindre mal.

Je ne m'aventurerai pas beaucoup plus loin, il faut à mon avis vraiment consulter un DBA confirmé MySQL pour avoir des avis très pertinents en la matière. Il existe des entreprises spécialisées dans les audits sur ce type de problème en demandant expressément un spécialiste certifié DBA MySQL 5 (en vérifiant l'authenticité de sa certification auprès de MySQL. Il y a aussi maintenant l'alternative SkySQL qui reprend le support de MySQL/MariaDB qui sont tout aussi qualifiés puisque tous viennent de chez MySQL AB.

Merci cyrano pour tes indications.

Pour info je viens de faire un test avec la table pièces, 1 colonne id (key primary), 1 colonne code_pieces(Index unique).
Je l'ai rempli avec 100 000 000 de lignes.
Pour un SELECT * FROM pieces WHERE code_pieces IN (une centaine de code), j'obtient le résultats en moins de 0.1 seconde
Pour un SELECT * FROM pieces WHERE id IN (une centaine d'id), j'obtient le résultats en moins de 0.02 seconde

C'est beaucoup mieux que ce que je pouvais penser, et en plus avec une table innodb.

Sinon pour la table lien, au lieu de faire une table avec 3 colonnes from (Index simple),to (Index simple),validé et ensuite relier les id entre eux, ce qui me ferait une multitude de lignes.
Je pensais faire une table lien avec 4 colonnes id(primary key),relier,en demande,en attente. Ce qui me permettrais d'avoir beaucoup moins de lignes (une seule par pièces) et une meilleure indexation grâce à la primary key.
Ensuite dans les colonnes relier,en demande, en attente (champ text) je mettrais les id de cette façon '101','504','65214',...
Et ensuite pour faire passer un id d'une colonne à l'autre j'utiliserai REPLACE et CONCAT_WS.

J'aurais plus de manip à faire, 2 au lieu d'une. Mais la recherche sera beaucoup plus rapide.

Qu'en pensez vous? Merci

[quote="popy"]Ben déjà : "1 colonne code_pieces(Index unique)" chez moi un index unique on appelle ça une primary key[/quote]
Mauvaise idée : considère la clé primaire comme une donnée système, le code de pièce est une donnée métier. Si le fabricant pour une raison quelconque décide de revoir son système de nomenclature, il l'aura dans l'os si on se sert de cette donnée en clé primaire. Donc la structure de base est bonne.

Pour ce qui est du choix de MySQL, ce n'est pas un mauvais choix, mais les quantités de données vont impliquer une indexation soigneusement choisie. MySQL reste le SGBD le plus rapide pour des requête SELECT avec le moteur MyISAM, un peu moins avec InnoDB, mais InnoDB offre le support de l'intégrité référentielle indisponible avec le premier. Donc là aussi le choix est bon. Il faut donc se poser la question sur les quantités de données manipulées à chaque transaction. Si tu ne manipules que quelques centaines de ligne à chaque fois, pas de problèmes, mais si c'est à coup de cent-mille ligne, ça risque d'être un poil moins efficace. Est-ce que tout ça est sur un unique serveur ou bien sur un cluster ou encore plusieurs serveurs avec un système de réplication avec un répartiteur ou quelque chose dans ce style ? À ce niveau de quantités de données, tu auras aussi grand intérêt à te documenter aussi sur le partitionnement des données. Il y a aussi des systèmes de cache qui peuvent être couplés à un SGBD.

Et soit dit en passant, manipuler une base de cette importance, c'est à mon sens du niveau DBA confirmé :-k

Oui, m'enfin si ton index est unique, tu peux l'utiliser comme primary key au lieu de rajouter une colonne qui ne représente rien juste pour dire "j'ai une primary auto increment unsigned int"

Merci poppy pour ton avis.
As tu déjà utilisée des tables avec autant de lignes? J'aurais quelques petits conseils à te demander


[quote="popy"]Ben déjà : "1 colonne code_pieces(Index unique)" chez moi un index unique on appelle ça une primary key[/quote]

Il y a 4 type d'index (primary,unique,index,text)

Ben déjà : "1 colonne code_pieces(Index unique)" chez moi un index unique on appelle ça une primary key :)

Sinon, j'ai envie de dire garde mysql. Ca reste le plus rapide. Il y a peu de temps je t'aurais bien conseillé postgres, mais finalement à maintenir c'est lourd.

Bonjour,

Je suis à la recherche de conseils. Je suis entrain de travailler sur un projet de site qui va nécessiter des tables avec de nombreuses lignes, des quantités que je n'ai pas l'habitude de traiter.

La première table "pieces": 1 colonne id (key primary), 1 colonne code_pieces(Index unique), et 4 autres colonnes date création,descriptif,code,code2

La deuxième table "lien": 1 colonne from (Index simple), 1 colonne to(Index simple), 1 colonne actif

La première table pourrait à terme compter 500 millions de lignes. Je vise large, mais vu le nombre de données que l'on a en stock c'est envisageable.
La deuxième table permetra de faire des liens entre les différentes pièces. Chaque pièce pourra compter jusqu'à 200 liens voir plus.

Les requêtes sur ses tables seront basique: delete, update, insert.
Et autrement SELECT id FROM pieces WHERE code_pieces = X
SELECT (from + to - id) as lien FROM pieces WHERE (from = id OR to = id) AND actif = 1

J'ai l'habitude de travailler avec Mysql, et pour ce projet avec Innodb. Mais là je n'ai aucune idée du temps que prendront les requêtes.
Est ce que ça vous paraît possible ou dois je m'orienter vers un autres sgbd?

Merci