Performance pour beaucoup de select sur un champs varchar

Bonjour, je construit une base de donnée pour un nouveau projet.
Ayant déjà été sujet à une base de donnée mal optimisée sur un gros projet qui amène à beaucoup de problèmes, je souhaite partir ici d'un bon pied. Je m'adresse ainsi à votre expertise aussi bien pour la structure que pour le moteur (innodb ou mysisam).

- 1ER POINT : Je met en place une base de donnée qui sera très peu mise à jour (UPDATE, INSERT, DELETE), mais très souvent lue (SELECT).

- 2EM POINT : j'ai besoin de stocker tout un ensemble de données à une url/exression(par exemple "mondomaine.com"/"monexpression") pour faire des satistiques dans le temps.

- 3EM POINT pour faire ces statistiques je dois figer pour une date, un lien, et une expression les données en question.
par exemple
- Le 11 décembre "mondomaine.com" pour "monexpression" à la colonne A qui vaut 5
- Le 12 décembre "mondomaine.com" pour "monexpression" à la colonne A qui vaut 6
- Le 13 décembre "mondomaine.com" pour "monexpression" à la colonne A qui vaut 10

- 4EM POINT : Les champs URL et expressions ne changent jamais.

Ainsi deux schémas me viennent à l'esprit :

SCHEMA 1
https://dl.dropbox.com/u/17283230/Ca...2017.16.33.png

SCHEMA 2
https://dl.dropbox.com/u/17283230/Ca...2017.19.19.png


Dans le schéma 1 j'aurai besoin d'une double jointure :

SELECT ... FROM statistics_web
JOIN site_web ON statistics_web.site_web_id_site=site_web.id_site
JOIN expression ON statistics_web.expression_id_expression=expression.id_expression
WHERE
expression.expression="monexpression"
AND site_web.url="monurl"
AND statistics_web.date>"...."
AND statistics_web.date<"...."

Vous savez sûrement aussi bien que moi, que ce schéma me permet de modifier facilement une url et une expression sur l'ensemble de la base.

Cependant je n'ai pas besoin de modifier cette url et expression, elles restent figées pour toujours. Ma question sur ce schéma est : est-ce que le fait de faire des jointures est performant et suffisament performant pour se justifier ? Peut être segmenter le tout en 3 requetes ? (une pour récuperer l'id de l'url, une pour récupérer l'id de l'expression, et la derniere pour récupérer mes données ?)




Dans le schéma 2 j'aurai seulement besoin d'effectuer un where, mais sur une grosse base textuelle, et là la grosse question : est ce que quand ma base comptera 100 000, 500 000, 1 000 000 d'entrée, la recherche texte sera toujours aussi performante ?

SELECT ... FROM statistics_web
WHERE
expression="monexpression"
AND url="monurl"
AND date>"...."
AND date<"...."


Mes connaissances en sql étant limitées à celles d'un développeur en soif d'en savoir plus, je n'arrive pas à peser le pour et le contre de chacun des schémas, ni du moteur adéquate.

Toute remarque étant la bievenue.

1- Pour le choix entre myisam et innodb il faut choisir "INNODB"
"dans tous les cas j'ai envie de dire" myisam est dépassé et INNODB va quasiment aussi vite maintenant...

2- Il est beaucoup mieux de faire une double jointure que 3 requêtes séparées. Ta base sera beaucoup plus performante car moins sollicité. Et ton schéma est beaucoup plus clair. Comme tu l'as dis c'est aussi beaucoup plus simple de modifié tes valeurs dans le 1er schéma même si t'en a pas besoin maintenant on ne sais jamais (merci de le prévoir pour le futur développeur :roll: qui te maudira si il a besoin de le faire).

Ce qu'il faut retenir c'est INNODB et faire le moins de requête possible.

salut,

je suis d'accord avec boboash pour les jointures, la solution 1 sera plus compacte et donc performante...

après pour le moteur de table ça dépend je te conseille de lire des choses sur les partitions avec mysql pour la table statistiques_web et si tu ne les utilises pas innodb avec des index bien placés pour toutes les tables...

1) InnoDB.
Tu auras les clés étrangères et donc l'assurance d'avoir des données cohérentes.

2) Schéma 1.
Notamment, ta table des expressions, si elle n'est pas trop grosse, sera toujours en mémoire et les données seront donc lues très rapidement. Alors que la répétition des données textuelles alourdit inutilement la BDD et empêche justement cette présence des données en mémoire lorsque la BDD grossit.

3) Jointures.
Il ne faut pas avoir peur des jointures, c'est l'opération la plus optimisée dans un SGBD.

Bonjour, à priori vos avis semblent converger. Merci bien :)