Table énorme, comment gérer ?

Bonjour,

Je vais ajouté une table candidature sur mon site internet mais je n'arrive pas à la modéliser.
Si j'ai plus de 5 millions d'utilisateurs sur le site et qu'ils déposent plus d'une dizaine de candidatures, je vais vite me retrouver avec une table énorme (plus de 50 millions de lignes).

Il est vrai que je pars dans les extrêmes avec mes chiffres mais je préfère demander avant de concevoir cette table ... Je pense que c'est le nombre de lignes qui m'inquiète par rapport à la performance. 8O
Comment concevoir cette table de façon optimale ? Faut-il historiser dans une autre table les candidatures dont le recrutement est terminer ? Ou est-ce que 50 millions de lignes c'est rien en terme de performance ?

Pouvez-vous me faire partager vos expériences pour des situations similaires ?

Merci pour vos réponses.

50 millions de lignes dans une table MySQL sur un serveur bien dimensionné, ça ne devrait pas poser de problème... à condition que la table (et les autres) soit correctement modélisée, indexée et que son utilisation par l'application soit optimisée.

Si vous nous montrez la structure de votre table et celle des tables associées, on pourra déjà vous donner un premier avis.

Ensuite, si votre application interroge la table 3 fois au lieu d'une à chaque demande de l'internaute, ça risque fort de réduire la performance de l'application.


À titre d'exemple, j'ai développé une base de données il y a 10 ans à partir de données issues du répertoire national des bovins. Il y avait une table de 65 millions de lignes et plusieurs autres de plusieurs millions à plusieurs dizaines de millions de lignes. Temps de réponse de toutes les requêtes, parfois un tantinet complexe puisque nous faisions des statistiques avec, sur un serveur de l'époque, pas particulièrement puissant : inférieur à la seconde.

Par contre, avec une base données mal faite et une application qui n'optimise pas non plus son utilisation, on peut avoir des problèmes à partir de quelques centaines de milliers de lignes.

Merci CinePhil,

Au sujet des autres tables de ma base, il n'y a pas problème, choix des types de colonnes optimisées, choix des index dans les tables, pas de duplication des données dans plusieurs tables, limitation des grosses tables (préférence pour le découpage en petites tables et les jointures), etc...

Votre réponse me conforte déjà mais j'ai une idée qui me trotte dans la tête pour soulager la table ... Mais je ne suis pas sûr que cela soit très catholique ! 8O

Lorsqu'une candidature est considérée terminée :
1 je la stock dans la table historique plutôt que de la laisser dans la table candidature.
2 je vide ensuite la ligne de la candidature terminé dans la table candidature sauf la colonne id (auto incrément). Du coup je me retrouve avec une ligne vide est dispo pour faire une nouvelle insértion.
3 Du coup dès qu'une nouvelle candidature est déposé, elle prend l'emplacement vide dans la table candidature et évite ainsi la création d'une ligne supplémentaire.

C'est tiré par les cheveux, mais cela évite d'avoir une table avec du volume.
Avez-vous un avis sur la question ?

Merci.

Citation:

---

Envoyé par nniikkoo

2 je vide ensuite la ligne de la candidature terminé dans la table candidature sauf la colonne id (auto incrément). Du coup je me retrouve avec une ligne vide est dispo pour faire une nouvelle insértion.
3 Du coup dès qu'une nouvelle candidature est déposé, elle prend l'emplacement vide dans la table candidature et évite ainsi la création d'une ligne supplémentaire.

---

C'est une très mauvaise idée, c'est le SGBD qui s'occupe de gérer l'écriture sur disque.
Si de la place a été libérée par un DELETE, le SGBD peut réutiliser cet espace de lui même, pas besoin d'usine à gaz à base de je conserve l'ID et je vais tenter de le réutiliser plus tard.

Pour de l'archivage, il y a aussi le partitionnement :
Partitioning Types
RANGE Partitioning

Merci skuatamad pour les précisions.
Finalité de l'histoire, il n'est pas nécessaire de vouloir réinventer la poudre à canon. Il est préférable de faire simple.

On ne doit jamais réutiliser un identifiant auto-incrémenté ! On s'en fout s'il y a des trous dans la numérotation parce que ce numéro n'a aucune signification.

Citation:

---

Envoyé par nniikkoo

1 je la stock dans la table historique plutôt que de la laisser dans la table candidature.

---

Ca dépend de l'utilisation que vous faites des candidatures, échues ou non, dans vos différents traitements.
Un statut de la candidature peut suffire, avec l'avantage de permettre plus de combinaisons que simplement terminé O/N et même un retour arrière le cas échéant

Citation:

---

Envoyé par nniikkoo

2 je vide ensuite la ligne de la candidature terminé dans la table candidature sauf la colonne id (auto incrément). Du coup je me retrouve avec une ligne vide est dispo pour faire une nouvelle insértion.

---

Sauf que "vider une ligne" n'existe pas
En SQL les ordres valides sont soit DELETE qui supprime toute la ligne, donc "sauf la colonne ID" ne veut rien dire, soit UPDATE qui modifie tout ou partie des colonnes.

Citation:

---

Envoyé par nniikkoo

3 Du coup dès qu'une nouvelle candidature est déposé, elle prend l'emplacement vide dans la table candidature et évite ainsi la création d'une ligne supplémentaire.

---

Non : l'affectation de l'emplacement physique des lignes lors d'un ajout est géré par le SGBD en fonction de nombreux paramètres dont l'utilisateur ne doit pas se préoccuper.
Rien ne garantit que la nouvelle ligne prendra le même emplacement physique que la ligne précédemment supprimée, mais de toutes façon peu importe l'emplacement physique, le principe d'un SGBD relationnel est justement de garantir l'indépendance entre la couche physique (emplacement des lignes notamment) et la couche logique
cf. les 12 règles de Codd ici

Citation:

---

Envoyé par escartefigue

cf. les 12 règles de Codd ici

---

Capitaine,

En ce qui concerne Wikipedia en anglais, en attendant qu’un farfelu vienne ficher la patouille, ce qu’on y trouve à ce jour est la copie conforme de ce qu’a écrit Codd. Par contre, évite de renvoyer à Wikipédia en français, pour tout ce qui touche au modèle relationnel de données de Codd, c’est trop souvent du charabia, donc inintelligible, c’est truffé d’âneries, d’erreurs. Pour ma part, j’ai renoncé à y rétablir la clarté et la vérité... En ce qui concerne les 12 règles de Codd, en français, fais référence à ce qu’en dit SQLpro dans son blog ou encore moi-même, dans le mien.

Exemple, dès la règle 1, on trouve ceci dan Wiki :

« Toute l'information dans la base de données est représentée d'une et une seule manière, à savoir par des valeurs dans des champs de colonnes de tables ».

Le rédacteur a oublié de qualifier la base de données, à savoir relationnelle. Les base de données navigationnelles ou orientées objet, voire XML, ne sont pas astreintes à respecter la règle.

Pour toi, que sont des champs de colonnes de tables ? Sont-ce des champs où l’on fait pousser des colonnes de tables ? (à l'instar de celles de Buren, qui ont poussé dans la cour d’honneur du Palais-Royal et la dénaturent _8O). J’aimerais avoir l’avis de CinePhil qui ne rate pas ceux qui parlent de champs de tables ! _:P

Toutes choses égales quant aux autres règles.

Citation:

---

Envoyé par fsmrel

Capitaine,

Pour toi, que sont des champs de colonnes de tables ?

---

Effectivement, je fais moi même souvent la remarque concernant les champs et autres termes inadéquats concernant les SGBD-R, bien vu ;)

Pour le fun, je vous redonne ma phrase : ;)
Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes. :)

Citation:

---

Envoyé par fsmrel

Pour toi, que sont des champs de colonnes de tables ? Sont-ce des champs où l’on fait pousser des colonnes de tables ? (à l'instar de celles de Buren, qui ont poussé dans la cour d’honneur du Palais-Royal et la dénaturent _8O). J’aimerais avoir l’avis de CinePhil qui ne rate pas ceux qui parlent de champs de tables ! _:P

Toutes choses égales quant aux autres règles.

---

Rudi Bruchez et moi même en avions mare de devoir recadrer la terminologie avec des foutaises de "champs" et d'"enregistrement".... Alors je ms suis coller à la littérature et j'ai trouvé dans Chris Date mon bonheur….
"
SQL and Relational Theory: How to Write Accurate SQL Code, 3rd Edition
"

Il y parle clairement de l'imbécilité d'une terminologie vaseuse !

A +

Pour info :

"
SOME REMARKS ON TERMINOLOGY

You probably noticed right away, in that list of relational issues in the previous section, that I used the formal terms relation, tuple (usually pronounced to rhyme with couple), and attribute. SQL doesn’t use these terms, of course—it uses the more “user friendly” terms table, row, and column instead. And I’m generally sympathetic to the idea of using more user friendly terms, if they can help make the ideas more palatable. In the case at hand, however, it seems to me that, regrettably, they don’t make the ideas more palatable; instead, they distort them, and in fact do the cause of genuine understanding a grave disservice. The truth is, a relation is not a table, a tuple is not a row, and an attribute is not a column. And while it might be acceptable to pretend otherwise in informal contexts—indeed, I often do so myself—I would argue that it’s acceptable only if all parties involved understand that those more user friendly terms are just an approximation to the truth and fail overall to capture the essence of what’s really going on. To put it another way: If you do understand the true state of affairs, then judicious use of the user friendly terms can be a good idea; but in order to learn and appreciate that true state of affairs in the first place, you really do need to come to grips with the formal terms.
"

Chris Date in SQL and the Relational Theory, 3rd Edition

A +